[Top] [All Lists]

Re: [ietf-smtp] Fwd: I-D Action: draft-melnikov-smtp-metadata-00.txt

2015-03-22 16:49:05
On 22/03/2015 21:14, Stephan Bosch wrote:
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