[lemonade] AD review of draft-ietf-lemonade-convert-16.txt

I would like the following issue addressed before IETF last call:

---
Section 6
>   suitable target media type.  This document doesn't describe how the
>   server makes such a choice.  For example, the server can know
>   characteristics of the device through a device description mechanism,
>   or it can have a prioritized list of MIME types based on how
>   widespread they are, how difficult their rendering is, etc.  Note
>   that servers are REQUIRED to support "default conversion" requests.

This mandates support for default conversions without setting any
constraints or even clear expectations for what the default conversion
will do.  While I understand the need for default conversion (and
suspect it may be the common case use for this extension if this deploys
successfully), this gives the server too much room to do
something stupid (such as the identity conversion) and in the process
risks defeating the utility of this function through
non-interoperability.  This is not sufficient to create interoperable
implementations.

What's needed is a clear statement of the expectation for default 
conversions.
The mechanism the server uses can then be measured against the expectation 
to
determine the quality of the server implementation.  But without stating the
expectation, there are too many reasonable expectations and thus no way to
measure the quality of a server implementation.  Here are some examples of
expectations you could set:

* Reduce the size of converted parts to a minimum that remains useful for 
fast
  preview purposes

* Convert the media types, charsets, codecs and other customizable 
parameters to
  the most standard or widely deployed options available in that media 
category.
  Minimize quality loss in this conversion.

* Convert the media types, charsets, codecs and other customizable 
parameters to
  ones that maximize the rendering speed of the media on a display device 
appropriate
  for that media type.

* Convert the media types, charsets, codecs and other customizable 
parameters to
  ones that can be rendered by a device without the need for any patent 
licenses.

* Based on out-of-band information about the client device, convert the 
media to
  types the device is likely to support and display successfully while 
removing
  any unnecessary detail that exceeds the capabilities of the device (e.g. 
scaling
  images to just fit on the device's screen).  When out-of-band device 
information
  is unavailable, assume a default device with the following 
characteristics: ...
  The characteristics of the default device may be adjusted by server 
configuration.

I'd also feel more comfortable if there was an optional way for the client
to inform the server of its identity (e.g., RFC 2971 with the constraint
about server interpretation lifted for this one purpose and perhaps a
device-id tag added).
---

The following issues fall into the "last call comment" category and if you
want to enter IETF last call without addressing these, that's fine.  But I
recommend addressing some of these with a revision prior to IETF last call
to reduce last call controversy.

High-level comments:

* As a matter of technical architecture, I would prefer that we had a
generic data conversions service and hooked it into IMAP via URLAUTH,
rather than making IMAP itself more complex.  If the IESG is doing their
job correctly, this should be raised as an issue during IESG review and
I will need a response to provide the IESG in the event this question
comes up.

* The IETF has a standards track protocol (OPES, RFC 4037) designed so
that servers can call-out for conversions.  While there is no requirement
to implement IMAP Convert using OPES, it is one valid implementation
technique and an informative reference would be nice.  Further, if IMAP
convert is implemented via a protocol call-out mechanism, I would like
implementer feedback on whether OPES is a good fit for that usage.

* The Lemonade charter mandates that the CONNEG framework will used if
content negotiation is needed.  IMAP CONVERT performs content
negotiation using a different negotiation framework, but it leverages
the media-features registry from CONNEG.  After consultation with the
former area director responsible for the lemonade charter is my
understanding that the primary purpose of that line in the charter was
to prevent creation of a new media feature vocabulary.  As a result, my
judgement is that the document just barely passes the bar set by the
charter.  However, I am open to input on whether my interpretation of
the charter is correct.

Detailed comments:

Section 3
>   The CONVERT extension does not address conversion during streaming
>   of attachments.

This is an odd statement because there's no context to understand it
within the document (there is within the WG charter, but we can't assume
readers will have read the charter). If you're going to say this, say
why and provide an informative reference to the document or documents
that can provide this functionality (for example, a combination of IMAP
URLAUTH and extensions for RTSP session negotiation could provide
streaming functionality).

Section 5.1

The document does not state which IMAP states (Authenticated, Selected)
the conversions command is made available.  At a minimum, I see no reason
it should be available in unauthenticated state and it would be best from
a security perspective if it was not permitted during that state.

Also, the document does not include a section for the "CONVERSIONS"
untagged response as is traditional in IMAP documents.  Was this omission
intentional?

Section 6
I find the name "BODYPARTSTRUCTURE" misleading as the result does not in
fact reflect the structure of the body part.  I suggest
"CONVERTEDSTRUCTURE" as an alternative.

>   The UID CONVERT command is different from the CONVERT command in the
>   same way as the UID FETCH command is different from the FETCH
>   command:

Note RFC 3501 section 7.4.1 describes another difference between FETCH
and UID FETCH that applies to CONVERT and UID CONVERT.

>   Comments embedded like this SHOULD be preserved during
>   conversion, but MAY be removed entirely.

This "SHOULD" and "MAY" are contradictory.  I suggest re-wording.

Section 8.2:
>   No destination MIME type may be specified with BODY[HEADER],
>   BODY[section.HEADER], or BODY[section.MIME].  It is important the
>   encoded words be left as encoded words as to do otherwise may alter
>   the semantics of structured headers.

Has there been a discussion of support for message/global-headers as a
target media type here?  That might actually be an interesting
poor-man's approach to EAI compatibility.  I'm not saying it's something
that has to be done, but cross-WG issues do need to be evaluated during
IESG review so I'd like some discussion of this topic before IESG review.

>   returned for the exactly the same conversion in the same IMAP
                 XXX

>   A response to a CONVERT command containing the BODYPARTSTRUCTURE data
>   item MUST return a BODYPARTSTRUCTURE data item (in the CONVERTED
>   response) before any other data items for the same body part.

This is an odd requirement and to me violates the principle of least
astonishment.  I believe it's also the first time we've required an IMAP
server to re-order the response data items. I'd be a lot more
comfortable with a requirement that in the event BODYPARTSTRUCTURE is
listed prior to BINARY for the same part in the request that it MUST
also be listed first in the response.  That achieves the same goal
(clients can be sure to get it first if they want it first) without
mandating the server re-order response data items.

Section 8.3
>         request). The return value MUST be exact and MUST NOT change
>         during a duration of an IMAP "session". This allows a client

I'm not sure such a strict "MUST NOT change" is a good idea.  One case
where it may change is if the message is expunged from underneath the
client.  I think clients need the ability to handle a change to an error
(or 0/NIL) in the event the part is removed and saying so (preferably
with an example) is likely helpful to interoperability.

>   Note for client implementors: client authors are cautioned that this
>   might be an expensive operation for some server implementations.
>   Needlessly issuing this request could result in degraded performance
>   due to servers having to calculate the value every time the request
>   is issued.  For that reason it is not a good idea to needlessly
>   request BINARY.SIZE and use it in a UI to allow a user to chose
>   between multiple conversions.

While advice along these lines is needed, this seems a bit off to me as
it places constraints on UIs which we have no business making and
needlessly makes a value judgement about client implementation models.
Perhaps something more like this would be better:

   Note for client implementors: client authors are cautioned that this
   might be an expensive operation for some server implementations.
   Requesting BINARY.SIZE for a large number of converted body parts or
   for multiple conversions of the same part can result in slow
   performance and/or excessive server load and is discouraged.  Clients
   should consider implementation approaches that limit this request to
   only the most necessary cases and are encouraged to test the
   performance impact of BINARY.SIZE with multiple server implementations.

Section 8.4: AVAILABLECONVERSIONS

Unlike the "CONVERSIONS" command, this response item provides no way to
determine support for features beyond the media type itself.  I want to
verify that this is acceptable to the WG as it seems an unusual
restriction to me.  I also find myself somewhat dubious of the utility
of this feature.

Section 10
>          convert-err-descript = string
>               ; Human readable text explaining the conversion error

Please state the charset for this, and if its value may be modified by
the LANGUAGE command.

Section 12
1st paragraph -- another mitigation is for the client to authenticate
the server using a mutual authentication mechanism and integrity layer
and trust the server not to provide dangerous content.

3rd paragraph -- an appropriate mitigation is to log the client
authentication identity for append and/or convert operations so
administrative measures can be applied to the situation.

4th paragraph -- I would recommend deleting this.  Convert doesn't alter
the nature of the spam threat in any way.  If you want to note the spam
threat, include a reference to one or more of the BCPs on the topic.

		- Chris

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade