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

From: "David B Harrington" <[email-masked]>
Date: Tue, 8 Apr 2008 13:53:22 -0400

Hi,

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. Response
formats seem to be quite variable. It makes me a little concerned
about interoperability to have optional elements. 

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. 

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.

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.

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). In either
case, thi stext should be modified to be clear and unambiguous. esp
with regard to the RFC2119 keyword.

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

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

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

"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? 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? Does this one sentence rule
really require an example? 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?

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 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?

--
I hope this helps,

David Harrington
[email-masked]
[email-masked]
[email-masked]

_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 24 Apr 2008 18:22:05 +0100

>should treat these comments just like any other last call comments.
David, I believe I adequately responded to majority of your comments.

For everybody's convinience, pointers to my responses they are listed below:
 <http://www.ietf.org/mail-archive/web/lemonade/current/msg04620.html>
 <http://www.ietf.org/mail-archive/web/lemonade/current/msg04623.html>
 <http://www.ietf.org/mail-archive/web/lemonade/current/msg04624.html>
 <http://www.ietf.org/mail-archive/web/lemonade/current/msg04625.html>
 <http://www.ietf.org/mail-archive/web/lemonade/current/msg04631.html>
 <http://www.ietf.org/mail-archive/web/lemonade/current/msg04633.html>

Regards,
Alexey