Subject: Re: [lemonade] ops-dir review of draft-ietf-lemonade-convert-17.txt

From: Alexey Melnikov <[email-masked]>
Date: Tue, 08 Apr 2008 16:40:39 +0100

David Harrington wrote:

>Hi,
Hi David,
Thank you for your review.
I will just quickly reply to things I can immediate comment on and would 
allow my co-editor to comment on remaining comments.

>I have reviewed draft-ietf-lemonade-convert-17.txt as part of the
>Operations and Management directorate effort.  These comments were
>primarily written for the benefit of the O&M area directors.  Document
>editors and WG chairs should treat these comments just like any other last call comments.
>
>   "CONVERT defines extensions to IMAP allowing clients to request
>   adaptation and/or transcoding of attachments.  Clients can specify
>   the conversion details or allow servers to decide based on knowledge
>   of client capabilities, on user or administrator preferences or its
>   settings."
>
>I have no experience with IMAP commands. I will review this as best I
>can, and I request that another ops-dir reviewer with IMAP experience
>also review this document.
>
>1. Is the specification complete?  Can multiple interoperable
>   implementations be built based on the specification?
>
>The basics appear to be complete and interoperable. It may be a common
>IMAP convention to allow optional parameters to commands.
>
Yes.

>Response formats seem to be quite variable. It makes me a little concerned
>about interoperability to have optional elements.
>
Can you be a bit more specific?

>2. Is the proposed specification deployable?  If not, how could it be
>   improved?
>
>I have no experience deploying MIME extensions, so cannot make a
>judgement on this. Deployment considerations are not discussed much in
>the document.  
>
I believe Peter Coates has implemented the spec, so it should be deployable.

There are also some implementation considerations in the document.

>3. Does the proposed approach have any scaling issues that could
>affect usability for large scale operation?
>
>Each request asks the server to perform a conversion, which could be
>resource intensive. Could lots of requests from one client create a
>denial of service attack? 
>
>4. Are there any backward compatibility issues?
>
>The SIZE command has some backwards compatibility issues, described in
>section 8.
>
There is no backward compatibility issues with the SIZE. The text in 
section 8.3 is describing some background on why BINARY.SIZE must return 
exact sizes.

>5. Do you anticipate any manageability issues with the specification?
>
>Manageability is not discussed in this document. I do not know if
>there would be anything new required as a result of this extension,
>but it might be useful for an operator to be able to tell how often
>this extension is being used and by whom and the number of errors, to
>help detect abuse and performace-impacting situations.
>
This make sense.
Can you recommend some specific text to be added?

>6. Does the specification introduce new potential security risks or
>   avenues for fraud?
>
>The security considerations section covers these fairly well.
>
>  
>Detailed review:
>
>section 6
>
>"   Specifying any non leaf section part requires that the server know
>   how to convert a multipart message, for instance into a PDF
>document." is ambiguous. Can the client request force a REQUIREMENT on
>the server (so 'requires' should be 'REQUIRES', or does this mean that
>making such a request to a server that doesn't know how to do the
>conversion will fail? (and presumably return an error code).
>
The latter.

>In either case, thi stext should be modified to be clear and unambiguous. esp
>with regard to the RFC2119 keyword.
>
Ok, I will try to reword this.

>s/convertions/conversions/
>should the examples of header conversions be modified to use
>example.com rather than siroe.com?
>
Ok.

>"Such request REQUIREs that the server decode any encoded words "
>seems to conflict with 
>"These parameters are non-trivial, and converting them without
>reformatting
>   the header is not always going to be possible."
>So shouldn't this be a SHOULD? And I would expect some langugae that
>says something about what an implementer is required to support. The
>specification should define the requirement at implementation-time,
>not the act of a client making a request at runtime.
>  
>
I will let Peter answer this.

>"The server ought to endeavour to" - should we add "ought to
>endeavour" to RFC2119 as keywords? ;-) seriously, can we change this
>to RFC2119 terms?
>I have concerns abotu interoperability in the preservation of headers;
>there seems to be lots of MAY options in the preservation
>recommendations.
>
>There are a number of uses of "may" and "requires" and other keywords;
>Can those be capitalized (or changed), so it is clear these are all
>meant to convey the RFC2119 semantics. Some of the "may" usage would
>be better stated as "might".
>  
>
Ok, Peter and I will review.

>"It is important the encoded words be left as encoded words as to do
>otherwise may alter the semantics of structured headers." Can this be 
>phrased in RFC2119 terms?
>
It should.

>There are a number of non-RFC2119
>expressions of requirements or recomendations in this document, and
>this document should be gone through thoroughly to make sure they are
>converted to appropriate RFC2119 keywords. Watch for "encourage",
>"discourage", 
>
>section 7
>
>s/Note, that according/According/
>
>I am not sure I understand why the example is needed here. Is this an
>example of additional optional parameters?
>
Yes.

>Does this one sentence rule really require an example?
>
No, but I thought it would be nice to have an example with anything 
other than charset.

>The example apparently is not about the
>required "charset" parameter.
>
>Most of the text in section 7 is about mandatory-to-implement charset
>support, so should that go into section 7.1?
>  
>
Good point. I will try to move some text there.

>section 8.3 discusses performance problems and suggests that clients
>should be considerate of performace implications of the SIZE command,
>and the text "discourages" a large number of client requests. I think
>this should be couched in RFC2119 language, and I think it should be
>stated that a server MAY enforce limits.
>
>section 8.5 does have some text about servers limiting requests and
>caches, but this is under implementation considerations, which feels
>non-normative. I think acceptable server behavior should be documented
>in RFC2119 language, to enhance interoperability.
>
>section 9 seems to allow the server to respond a variety of ways,
>which I expect could impact interoperability. It might be better to
>define the expected behavior more deterministically.
>
I need to think more about these suggestions.

>I am not a big fan of "standards" that say "anybody can send whatever
>they want, but that's OK, because we'll write the standard so that no
>matter what you do, you can claim compliance to the standard."
>
>"   The word ERROR is always followed by an informal human readable
>   descriptive text, which is followed by the convert-error-code.  The
>   convert-error-code, MUST be one of the following:" Will we
>standardize the human-readable text as well as the codes?
>  
>
No, there is no intention to standardize human-readable text.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 09 Apr 2008 19:01:13 +0100

> Ok, I will try to reword this.

The new text reads:

    It is legal for a client to request conversion of a non leaf body part,
    for example to request conversion of a multipart/* into a PDF document.
    However servers implementing this extension are not required to support
    such conversions. Servers that support such conversions MUST return
    at one or more CONVERSION responses, in response to a
    'CONVERSIONS "multipart/*" "*"' command. See Section 5.1
    for more details.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 09 Apr 2008 19:06:06 +0100

Hi David,

> David Harrington wrote: 

 [...]

> There are also some implementation considerations in the document.

...which have some implications on deployments.

 [...]

>> stated that a server MAY enforce limits.
Ok, will do.

Ok.

>> define the expected behavior more deterministically.
After rereading section 9 I think it is sufficiently deterministic about 
when different responses should be used. I think the current list of 
various response codes is sufficiently detailed so that a compliant 
server can signal a client why a particular response failed. Document 
response codes would allow clients to deal with different error 
conditions differently, in some cases clients can try other operations 
that would succeed.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 09 Apr 2008 20:47:42 +0100

Hi David,

>denial of service attack?
Sections 8.5 (Implementation considerations) and 12 (Security 
Considerations) talk about denial of service attacks, in particular 
about server refusing to execute CPU expensive conversions, and about 
server denying conversion requests on multiple messages and/or multiple 
body parts of the same message using MAXCONVERTMESSAGES and 
MAXCONVERTPARTS response codes. In general, an IMAP server can always 
refuse to execute any command by returning a tagged NO response. 
MAXCONVERTMESSAGES/MAXCONVERTPARTS response codes allow the server to 
signal the client why it decided to refuse to execute a command.

I will review the document to make sure that what I wrote above is 
clearly explained in the document.

Regards,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 18 Apr 2008 11:24:18 +0100

David Harrington wrote:

>So shouldn't this be a SHOULD?
>
No, I think REQUIRE is correct here. I.e. the server must decode any 
encoded words. Reformatting is part of reencoding and might be unavoidable.
However I agree the text was not entirely clear. Here is the updated text:

    Any such request REQUIREs the CHARSET parameter. 
    The request REQUIREs that the server decode any encoded words
    (as described in [RFC2047] in headers and return them re-encoded
    in the specified charset. (Note that encoded-words might not be
    needed if the result can be represented entirely in US-ASCII.)
    If the server can't decode any particular encoded word,
    for example if the charset or encoding is not recognized,
    it MUST leave them as is. Servers SHOULD also support decoding
    of any parameters as described in [RFC2231].
    Support for RFC 2231 parameters might require reformatting
    of header fields during conversion. Consider the following

>And I would expect some langugae that
I think the above text is quite clear on this now.

>endeavour" to RFC2119 as keywords? ;-) seriously, can we change this
I've changed this to SHOULD.
 [...]

>phrased in RFC2119 terms?
Rephrased.
 [...]

>in RFC2119 language, to enhance interoperability.
I've updated and restructured section 8.5 to read more normative.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 18 Apr 2008 14:47:13 +0100

David Harrington wrote:

>>-----Original Message-----
>>From: Alexey Melnikov [mailto:[email-masked]] 
>>Sent: Friday, April 18, 2008 3:24 AM
>>To: David Harrington
>>Cc: [email-masked]; 'Romascanu, Dan (Dan)'; 'Ron Bonica'; 
>>[email-masked]; Chris Newman; Lemonade WG
>>Subject: Re: ops-dir review of draft-ietf-lemonade-convert-17.txt
>>
>>
>Does the parenthetical text mean
>1) if the original author had used US-ASCII, they could have avoided
>using encoded words,
>  
>
Yes. Many broken clients try to encode something as encoded words, when 
they shouldn't.

>or 2) the server may re-enode using US-ASCII, and therefore not need
>any encoded words, so the result might contain no encoded words, and
>the requester should not consider a result with no encoded words to be
>an invalid result.
>  
>
That too. See below.

>I'm not sure which way to read this text. I think the language is too
>loose, and, assuming #2 is the answer, then it would be better to
>restate this to make it clearer what is required for interoperability,
>i.e., what the server implementation MAY return for a result, and what
>the requesting implementation MUST be prepared to accept as a result
>in this circumstance.
>  
>
I will try to clarify.
However in this particular case there is no interoperability problem: 
the client must implement decoding of RFC 2045 encoded words to display 
messages properly. So the client can display the converted result 
whether the result contains encoded words or not.

---

From: "David Harrington" <[email-masked]>
Date: Fri, 18 Apr 2008 05:50:06 -0700

dbh