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

Hi Chris,

Chris Newman wrote:

>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.
>  
>
You and I discussed this briefly in jabber. Let me summarize our discussion:
1). An IMAP extension that provides body part conversion with support 
for partial download is easy for IMAP clients to implement.
Many IMAP clients already support downloading body parts in chunks 
(using partial FETCH), CONVERT provide a natural extension to that.

2). Based on feedback from client developers, the CONVERT extension 
supports BODYPARTSTRUCTURE (MIME structure of the converted body part) 
and BINARY.SIZE (size of the converted body part) CONVERT requests. Both 
as similar to functionality provided by IMAP FETCH command.
Any alternative solution has to provide the same functionality.

3). Mobile clients would be happier with having fewer TCP connections

And finally:

4). Lemonade WG is only chartered to extend SMTP and/or IMAP, so a 
separate protocol is out of scope for the WG.

>* 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.
>
I've skimmed through RFC 4037 and I think it can be a reasonable 
protocol for implementing conversions. It does have some tricky commands 
(like various optimizations) and might be overkill for some implementations.

I am not entirely sure where to add the informative reference to RFC 4037.

>* 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,
>
My understanding is that the content negotiation language defined in RFC 
2533 is much more complex, rarely used and thus would be overkill for 
CONVERT.

>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.
>
I tend to agree with the former AD.

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

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