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

From: Chris Newman <[email-masked]>
Date: Wed, 02 Apr 2008 14:00:53 -0700

Please treat my remaining issues as if they were last call comments.

--On March 31, 2008 18:21:00 +0100 Alexey Melnikov 
<[email-masked]> wrote:
>>>  Comments embedded like this SHOULD be preserved during
>>>  conversion, but MAY be removed entirely.
>>>
>> This "SHOULD" and "MAY" are contradictory.  I suggest re-wording.
>>
> The intend was to say that comments can be preserved at the place where
> they were found, they can be preserved, but moved, or they can be removed.
> I thought this sentence was sufficiently clear, any suggestion how to
> improve it?

I recommend picking one or the other rather than giving contradictory 
advice:

Either:    Comments embedded like this SHOULD be preserved during 
conversion.
or:        Comments embedded like this MAY be removed entirely.

I slightly prefer the former.

Another approach would be:
  Comments embedded like this SHOULD be preserved during conversion, but 
clients MUST
  gracefully handle the situation where comments are removed entirely.

>> Has there been a discussion of support for message/global-headers as a
>> target media type here?
>
> Right. The CONVERT extension would support that, if we allow for target
> MIME type above. I am frankly scared of putting any text about
> message/global-headers into the document, considering that all EAI
> documents are going to be Experimental at first. But once EAI updates all
> documents to be on standard track, that would be an obvious thing to look
> at.
>
> I was thinking about suggesting that the output for BODY[HEADER] should
> be headers in UTF-8 (with no encoded words), i.e. effectively they would
> be in message/global-headers format. But Peter convinced me that all
> existing email clients would need to support encoded words, so it is
> better to leave the converted headers with encoded UTF-8 words as well.

As long as a future version could be compatibly extended to support 
converting headers to message/global-headers, I'm fine.  But on reading the 
spec I wasn't sure but didn't have time to think about that in depth.

>>>  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.
>>
> Correct.
>
>> 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.
>>
>>
> Clients can't have this guaranty with IMAP anyway, because pretty much
> all existing servers reorder [at least some] of FETCH data items.
>
> This requirement is for clients benefit. I.e. the client can expect it to
> be the first data item (the second, if UID is also returned), so it can
> take advantage of this.
> I wish we had something similar about UID data item in FETCH.

Then please write it as a client requirement, please.  State that if the 
client lists BODYPARTSTRUCTURE before BINARY, then the server MUST return 
BODYPARTSTRUCTURE prior to BINARY.  That achieves the client requirement 
without constraining the server implementation.

I'd like a server implementation that returns items in the order requested 
by the client to be compliant with the specification.  I see no reason to 
declare such a server non-compliant in order to achieve the necessary 
client feature.

>> Section 8.4: AVAILABLECONVERSIONS
>>
>> Unlike the "CONVERSIONS" command, this response item provides no way to
>> determine support for features beyond the media type itself.
>>
> This was intentional. If the client wants to use conversion parameters,
> it is either going to use a fixed set of parameters, or it can discover
> which ones are available using the CONVERSIONS command. I didn't think it
> was worth adding extra complexity and increase response size for
> something which is unlikely to be used by the client.

Ok, that's good enough for me.

>> 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.
>>
> The use case is as follows: the CONVERSIONS command for the source MIME
> type would return too many choices (for example for
> application/octet-stream). But for a specific body part conversion there
> is a smaller set of target MIME types, which can be presented to the user
> in a dialog, which allows the user to pick one of the supported MIME type
> viewers. Something like:
>
> This body part can be converted to one of the following MIME types,
> please select your preferred viewer:
> o image/jpeg (default viewer)
> o application/pdf (Adobe Acrobat)
> o text/plain (Notepad)

Ok.  Thanks for the clarification.

		- Chris

_______________________________________________
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: Thu, 03 Apr 2008 17:11:42 +0100

Chris Newman wrote:

> converting headers to message/global-headers, I'm fine.  But on 
> reading the spec I wasn't sure but didn't have time to think about 
> that in depth.

Right.
Actually, if one specifies a regular BINARY conversion from anything to 
message/global-headers, then things will just work. No changes to the 
draft needed.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 18 Apr 2008 10:17:12 +0100

Chris Newman wrote:

> Then please write it as a client requirement, please.  State that if 
> the client lists BODYPARTSTRUCTURE before BINARY, then the server MUST 
> return BODYPARTSTRUCTURE prior to BINARY.  That achieves the client 
> requirement without constraining the server implementation.

> I'd like a server implementation that returns items in the order 
> requested by the client to be compliant with the specification.  I see 
> no reason to declare such a server non-compliant in order to achieve 
> the necessary client feature.

Ok, after further thought I decided that your proposal is reasonable. So 
I've changed the text to read:

    If the client lists a BODYPARTSTRUCTURE data item for a section-part
    before a BINARY data item for the same section-part,
    then, in the CONVERTED response, the server MUST return
    the BODYPARTSTRUCTURE data prior to the BINARY data.

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 18 Apr 2008 10:54:18 -0400

Hi Alexey,

>     the BODYPARTSTRUCTURE data prior to the BINARY data.

And what if the server splits the response into two CONVERTED responses, 
one with BODYPARTSTRUCTURE and one with BINARY. Is the server also required 
to send the BODYPARTSTRUCTURE response before the BINARY response in that 
multi-response case? If so, that needs to be stated too.

-- 
Cyrus Daboo

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 18 Apr 2008 16:37:38 +0100

Cyrus Daboo wrote:

> And what if the server splits the response into two CONVERTED 
> responses, one with BODYPARTSTRUCTURE and one with BINARY. Is the 
> server also required to send the BODYPARTSTRUCTURE response before the 
> BINARY response in that multi-response case?

Yes :-).

> If so, that needs to be stated too.

Ok, I should add an example. Maybe even a couple.