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

From: Chris Newman <[email-masked]>
Date: Mon, 23 Jul 2007 13:59:24 -0500

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.

* 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.

* 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.

* 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.

Nits:

"image/wbmp" is not a registered media type.  "image/vnd.wap.wbmp" is 
registered.

Section 4.2, last paragraph, last sentence "standardized" -> "registered" (the 
media features registry has procedures for registration without going through 
the IETF process and I don't want to preclude that path).

                - Chris

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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 26 Jul 2007 21:00:36 +0100

Chris Newman wrote:

> * 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.

I found a weak reason for using type/subtype: type/subtype matches the 
syntax used in annotations.
However I don't have a strong preference (apart from editor's laziness 
to change the document), so if other people have a strong opinion, I can 
change the document.

> "image/wbmp" is not a registered media type.  "image/vnd.wap.wbmp" is 

I've fixed that by removing the reference.

> Section 4.2, last paragraph, last sentence "standardized" -> 
> "registered" (the media features registry has procedures for 
> registration without going through the IETF process and I don't want 
> to preclude that path).

Done.

---

From: Lyndon Nerenberg <[email-masked]>
Date: Thu, 26 Jul 2007 12:02:33 -0700 (PDT)

> I found a weak reason for using type/subtype: type/subtype matches the syntax 
> used in annotations.
> However I don't have a strong preference (apart from editor's laziness to 
> change the document), so if other people have a strong opinion, I can change 
> the document.

The CONVERT syntax should be consistent with the existing BODYSTRUCTURE 
syntax.

--lyndon

   NT as a file server is faster than a dead bat carrying Post-It notes
   underwater. But not by much.

---

From: Eric Burger <[email-masked]>
Date: Tue, 31 Jul 2007 09:20:59 -0700

One could offer BODYSTRUCTURE is the one that is wrong, but I do not care.
Whatever the work group wants.

>    underwater. But not by much.

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 31 Jul 2007 09:45:02 -0700 (PDT)

> Whatever the work group wants.

BODYSTRUCTURE has been out there for ever.  Right or wrong, it's what 
people and parsers are familiar with.

--lyndon

   Good judgement comes from experience. Unfortunately, experience
   comes from bad judgement.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 31 Jul 2007 10:56:21 -0600

> people and parsers are familiar with.

Your response made me wonder if you've actually read the spec.
The BODYPARTSTRUCTURE syntax is identical to that of BODYSTRUCTURE. The 
only place where MIME type/subtype are a single token is after the 
BODYPARTSTRUCTURE itself, i.e.

 BODYPARTSTRUCTURE[3 ("APPLICATION/PDF")] ("APPLICATION" "PDF" () NIL NIL "Base64" 2135 NIL NIL NIL)

I think Chris was commenting on "[3 ("APPLICATION/PDF")]".

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 31 Jul 2007 10:24:15 -0700 (PDT)

> The BODYPARTSTRUCTURE syntax is identical to that of BODYSTRUCTURE. The only 
> place where MIME type/subtype are a single token is after the 

Yes, and I'm saying that the syntax should be the same throughout.  The 
clients and servers already have code that knows how to deal with the 
("FOO" BAR") representation of MIME types.  What purpose is served by 
requiring a new code path in the parser to deal with ("FOO/BAR")?  You're 
adding complexity to the code (and protocol) for no good reason.

Using the current convention for representing MIME types lets you 
eliminate large swaths of the grammar extensions, which simplifies the 
parsers and reduces the potential for the introduction of bugs that will 
break interoperability.

As with software, the art of protocol design is in knowing what to leave 
out.

--lyndon

   Never hit a man with glasses.  Hit him with a baseball bat.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 31 Jul 2007 12:09:48 -0600

Lyndon Nerenberg wrote:

>> The BODYPARTSTRUCTURE syntax is identical to that of BODYSTRUCTURE. 
>> The only place where MIME type/subtype are a single token is after 
>> the BODYPARTSTRUCTURE itself, i.e.
>>
> Yes, and I'm saying that the syntax should be the same throughout.  
> The clients and servers already have code that knows how to deal with 
> the ("FOO" BAR") representation of MIME types.  What purpose is served 
> by requiring a new code path in the parser to deal with ("FOO/BAR")?  
> You're adding complexity to the code (and protocol) for no good reason.

I actually remembered the true reason why I've used a single token - 
because of the default conversion (which is NIL). Handling silly states 
is worse (e.g. "text" NIL), etc.

> parsers and reduces the potential for the introduction of bugs that 
> will break interoperability.

Oh please, one string versa 2.

> As with software, the art of protocol design is in knowing what to 
> leave out.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 31 Jul 2007 12:10:51 -0600

Alexey Melnikov wrote:

>> the ("FOO" BAR") representation of MIME types.  What purpose is 
>> served by requiring a new code path in the parser to deal with 
>> ("FOO/BAR")?  You're adding complexity to the code (and protocol) for 
>> no good reason.
>
> because of the default conversion (which is NIL). Handling silly 
> states is worse (e.g. "text" NIL), etc.
>
>> eliminate large swaths of the grammar extensions, which simplifies 
>> the parsers and reduces the potential for the introduction of bugs 
>> that will break interoperability.
>

However I do agree with this principal in general. I just don't think it 
applies in this case.

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 31 Jul 2007 11:16:23 -0700 (PDT)

> Oh please, one string versa 2.

Okay, you just don't get it, and I give up.

--lyndon

   >What about all the people who hoarded tonnes of spam in their bunkers?

   I hoard spam on my hard drive.  When I heard about the coming
   Y2K worries, I downloaded a lifetime supply from the net.
   			-- Charlie Gibbs in alt.folklore.computers

---

From: Mark Crispin <[email-masked]>
Date: Tue, 31 Jul 2007 11:41:12 -0700 (PDT)

On Tue, 31 Jul 2007, Alexey Melnikov wrote:
> I actually remembered the true reason why I've used a single token - because 
> of the default conversion (which is NIL). Handling silly states is worse 
> (e.g. "text" NIL), etc.

TEXT is not a valid MIME type/subtype specifier.  Neither is TEXT/NIL.

The underlying bug is that you have NIL as a default, rather than 
specified defaults.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.