On 22/03/2015 21:14, Stephan Bosch wrote:
Hi,
Hi Stephan,
On 3/22/2015 4:48 PM, Alexey Melnikov wrote:
Constructive feedback would be very much appreciated!
I think this document can benefit from a more extensive introduction.
I mainly like to know why a `clean separation of transaction-related
state from the message itself' is necessary. What can go wrong if it
isn't passed separately? What are the main benefits? What are the
applications where this is relevant? I can take a few guesses for
things like keying material, but the rationale for passing trace
information like that is much less obvious. I see some hints
throughout the text, but I think making this clear in the induction is
important.
Fair comment. There might be some benefits related to providing privacy,
especially if this data is encrypted, but the main message itself is in
clear text.
I admit I haven't thought about this a lot and this might be a silly
idea, but I thought putting this in a draft is much better than arguing
about this in abstract as lots of people do :-).
Also, what is the application of being able to pass IMAP flags in SMTP?
Message transfer between IMAP servers over SMTP. For example if I want
to send you a message and let you know that it was forwarded and/or
replied to.
Normally, I wouldn't want to give the sender the ability to assign
flags directly. And how would these flags interact with Sieve imap4flags?
The idea is that the flags passed through this extension would replace
the default empty set used when a Sieve script starts.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp