Subject: Re: [lemonade] WGCL Convert-05

From: Alexey Melnikov <[email-masked]>
Date: Thu, 29 Mar 2007 16:40:45 +0100

Arnt Gulbrandsen wrote:

> Three serious problems and some irritants.
>
> Serious: The document could do a better job of explaining why it's 
> useful. It never has persuaded me to do much more than skim and ignore 
> it. Mark would say «neat to have, not need to have». Maybe it _is_ a 
> need-to-have, but reading the abstract/introduction hasn't shown me 
> any need.

I would like to solicit some help with this text.

> In section 3, the second paragraph could mention an additional reason 
> to keep the original format: S/MIME. If you change the format, you 
> break all signatures.

The second paragraph of section 3 now reads:
   Note: The requirement that original data be unaltered allows such 
data to
   remain accessible by other clients, permits replies or forwards of
   the original documents, permits signature verification (the converted
   bodyparts are not likely to contain any signatures), and preserves
   BODYSTRUCTURE and related information.

> The examples on page 6 urgently need better formatting.

Fixed (I hope).

> In 6.1, this sentence makes no sense to me: «A client requesting the 
> server annotation "/convert/text/plain" MUST return "text/plain" as an 
> allowed destination conversion.»

This is referring to charset conversion. I've changed the text to read:
   The server MUST list "text/plain" as an allowed destination
   conversion in the "/convert/text/plain" annotation.

Is this any better?

> I suggest removing the word «and» at the head of the following sentence.

I removed the "And".

 [...]

> The formal syntax has lots of formatting problems. Because of that I 
> didn't look closely for other problems.

Fixed.

> Serious: The security considerations section omits a new attack: A 
> client can APPEND a carefully crafted bad message followed by FETCH to 
> attack the server. If the server's conversion function or library has 
> a security problem, this could result in provilege escalation or 
> denial of service.

Added.

Alexey

P.S. I will try to address the remaining comments later.

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