Subject: Re: [lemonade] draft-ietf-lemonade-convert-10.txt

From: Alexey Melnikov <[email-masked]>
Date: Mon, 20 Aug 2007 10:54:43 +0100

Chris Newman wrote:

> As a technical contributor (not AD), some suggestions for this document:
>
> * I suggest removing the non-BINARY fetch items.  Forcing a server to 
> base64-decode, convert, then base64-encode when the chance a client 
> needs it base64-encoded is probably nil seems like unnecessary 
> protocol/server complexity.

Done.

> * The syntax for specifying a conversion is pretty verbose 
> (necessarily).  If it's necessary to fetch or reply with more than one 
> convert item for the same part (e.g. BODYPARTSTRUCTURE and BINARY), 
> then the client has to repeat the same conversion specifier multiple 
> times in the same response.  A syntax that made the part specifier 
> only appear once would be more concise, e.g.:
>
> * 2 CONVERTED [3 ("text/plain" ("charset" "us-ascii" 
> "unknown-character-replacement" "?"))] BODYPARTSTRUCTURE (...) BODY ...
> instead of
> * 2 CONVERTED (BODYPARTSTRUCTURE[3 ("text/plain" ("charset" "us-ascii" 
> "unknown-character-replacement" "?"))] ... BODY[3 ("text/plain" 
> ("charset" "us-ascii" "unknown-character-replacement" "?"))] ...
>
> * Saying that "servers MAY disallow a request to perform multiple 
> different conversions of the same bodypart at once" is an interop 
> problem as clients that request that will get unpredictable behavior 
> if they issue such a command.  It would be simpler to just disallow 
> this altogether.

Both done. The target MIME type and conversion parameters are now a 
separate [complex] parameter to CONVERT/UID CONVERT.
The second change is a side effect of the new syntax.

> * This is missing a security consideration -- When the client requests 
> a server-side conversion of a signed body part (e.g. a part inside 
> multipart/signed), there is no way for the client to verify that the 
> converted content is authentic.  The client is fully trusting the 
> server in this case. The alterative is for the client to download the 
> signed object, verify the signature and perform the conversion on the 
> client.  This is a direct security vs. efficiency/convenience tradeoff 
> with both options important to a subset of the user base.

I've already addressed this change earlier.

> * An observation -- IMAP BODYSTRUCTURE splits MIME "type" and 
> "subtype" into two separate fields.  The CONVERT part specifier uses 
> the "type/subtype" syntax.  This isn't consistent.  I want to verify 
> the inconsistency is intentional and has WG rough consensus.

The new syntax of the CONVERTED untagged response includes "convert 
correlator" instead, so this issue is resolved.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade