Subject: [lemonade] WGLC Convert

From: Eric Burger <[email-masked]>
Date: Tue, 10 Oct 2006 22:25:41 -0400

<http://tools.ietf.org/wg/lemonade/draft-ietf-lemonade-deployments/draft-iet
f-lemonade-deployments-03.txt>

Have at it.  WGLC closes 10/25/06.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 11 Oct 2006 17:37:57 +0100

Eric Burger wrote:

><http://tools.ietf.org/wg/lemonade/draft-ietf-lemonade-convert/draft-ietf-le
>monade-convert-04.txt>
>
Two months ago I've sent authors an updated version that fixes various 
ID nits (lots of non-ASCII characters), typos (like reference to 
LDELIVER in section 4.1) and references to commands that were recently 
renamed (e.g. GETANNOTATION). There is also a missing reference to RFC 
3516 (BINARY).

All those issues must be fixed before sending the document to IESG.

I can send the full list of comments to the mailing list, but is it 
worth complaining about every single non-ASCII character in the document?

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 11 Oct 2006 17:59:15 +0100

> worth complaining about every single non-ASCII character in the document?

One more thing, this document can't be published until METADATA is done.

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 11 Oct 2006 13:05:45 -0400

Hi Alexey,

> One more thing, this document can't be published until METADATA is done.

This week is 'get all my drafts done' week!

-- 
Cyrus Daboo

---

From: Randall Gellens <[email-masked]>
Date: Wed, 11 Oct 2006 17:30:09 -0700

>  Have at it.  WGLC closes 10/25/06.

I does not appear that my comments against -03 have been addressed. 
These were sent in email on 5/31/06 at 8:38 AM.  So these comments 
are carried forward to -04.

Additionally, the Abstract should be self-contained (no references) 
and should be more clear, to give someone scanning the I-D 
announcements an idea of what the document does.

Please replace the existing Abstract with:

    CONVERT defines IMAP extensions 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.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
We have the best politicians money can buy.

---

From: Ray Cromwell <[email-masked]>
Date: Wed, 11 Oct 2006 18:25:14 -0700

Sorry guys, I deeply apologize for the confusion. This is not the 
correct draft, it appears what was submitted is an old version, possibly 
even one from the last meeting. This document is apparently a version 
from around 6/19/06, whereas the one that was supposed to be submitted 
was from 8/7/06. I did get your message Alexey, and I had run it through 
the nit checker and fixed all the boilerplate, references, and non-ascii 
characters that the checker complained about. I also believe I had taken 
most of Randy's (as well as Eric's) comments into account.  I'm going to 
diff the one submitted against my version, and see what still hasn't 
been fixed, if any, and if it includes fixes from Randy.

-Ray

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 12 Oct 2006 22:35:21 +0100

In a private discussion with Dave Cridland, he pointed out that if the 
client requests both BODY[<section>.CONVERT ...] and BODY[<section>] in 
the same FETCH request, there is no way for the server to return both of 
them in the corresponding FETCH response, because both of them will be 
labeled BODY[<section>].
So, either the syntax should be extended to allow for this, or the 
document should explicitly mention this restriction.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 12 Oct 2006 22:49:12 +0100

On Thu Oct 12 22:35:21 2006, Alexey Melnikov wrote:
> In a private discussion with Dave Cridland, he pointed out that if 
> the client requests both BODY[<section>.CONVERT ...] and 
> BODY[<section>] in the same FETCH request, there is no way for the 
> server to return both of them in the corresponding FETCH response, 
> because both of them will be labeled BODY[<section>].

There are other cases, too, such as requesting multiple conversions.

I'm also curious about how this might interact with URLs, and, 
through the URL form, how it might impact both URLAUTH (and therefore 
BURL), and CATENATE. I think there are valid use-cases for URL usage 
of CONVERTed parts. For obvious reasons, there's no practical method 
for using anything but STRICT here; this at least needs to be dealt 
with.

Finally, I'm not sure that signalling modes of failure for conversion 
is best done within the tagged OK. We only send one of those, for 
potentially many conversions. It seems logical to me that the result 
of the conversion might, therefore, be named FETCH item consisting of 
a set of MIME information, a literal (or NIL), and a set of tokens 
indicating INFORMATIONLOSS etc. By naming the item, we can cure the 
point I discussed with Alexey which he notes above, as well as making 
this somewhat simpler for URL handling.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 12 Oct 2006 22:59:59 +0100

>2. Relation with other E-mail specifications
 >      
 >   CONVERT does not address conversion and streaming of media as also
 >   identified of interest by Lemonade. 
 >   CONVERT depends on the METADATA extension [ANNOTATEMORE] to support
 >   discovery of supported conversion formats. In addition, to use
 >   CONVERT, the client and server MUST support the IMAP Binary
 >   specification [RFC3516].

The MUST make sense for servers. However it is kind of pointless for 
clients. Surely, if the client never uses BINARY or BINARY[CONVERT], it 
doesn't need to know anything about RFC 3516.

---

From: Ray Cromwell <[email-masked]>
Date: Sun, 22 Oct 2006 17:48:30 -0700

> this somewhat simpler for URL handling.
Dave,
   I agree that this fixes a hole in the spec with respect to signaling 
failures when multiple conversions are requested, but I did not 
understand Alexey's comment "In a private discussion with Dave Cridland, 
he pointed out that if the client requests both BODY[<section>.CONVERT 
...] and BODY[<section>] in the same FETCH request, there is no way for 
the server to return both of them in the corresponding FETCH response, 
because both of them will be labeled BODY[<section>]." The draft 
specifies that the result of conversions is a BODYPARTSTRUCTURE[section] 
not BODY[section], so seems that if the client requested the same 
section twice, the client could disambiguate them as BODY vs 
BODYPARTSTRUCTURE.  There would be a problem however if you requested 
the same section with two different conversions, then you'd get two 
BODYPARTSTRUCTURE[section] in the corresponding response, with only the 
resultant mime-type and transcoding parameter information 
differentiating them. However BODYPARTSTRUCTURE represents the resultant 
conversion, not the requested conversion (unless STRICT is used), so the 
client can't depend 100% on matching up the conversion result in a 
BODYPARTSTRUCTURE with the request if there is such ambiguity (e.g. 
asking for section 3 as both IMAGE/GIF and IMAGE/JPEG) In any case, I 
think the gist of the problem you pointed out is right, but I had a 
nagging feeling I might be misunderstanding it because it seemed to me 
that if you requested a non-converted section, plus a converted version 
in the same request, the client could still tell the difference.

  I think we can hash it out during the IETF'67 Lemonade FtF or 
afterwards on the list, but I do agree there needs to be a fix, thanks 
for pointing it out. We probably need to be more clear in the draft 
about the result of a CONVERT (that it is a BODYPARTSTRUCTURE along with 
the converted data, and not BODY), we may also want to make it return 
BODYPARTSTRUCTURE[section.CONVERT requested-params] instead of 
BODYPARTSTRUCTURE[section] as well as extending it to allow error 
signaling on each converted part. I'm open to extending the result 
and/or renaming it if there is confusion with BODYSTRUCTURE/BODY.

-Ray

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 25 Oct 2006 16:44:47 +0100

Ray Cromwell wrote:

> understand Alexey's comment "In a private discussion with Dave 
> Cridland, he pointed out that if the client requests both 
> BODY[<section>.CONVERT ...] and BODY[<section>] in the same FETCH 
> request, there is no way for the server to return both of them in the 
> corresponding FETCH response, because both of them will be labeled 
> BODY[<section>]." The draft specifies that the result of conversions 
> is a BODYPARTSTRUCTURE[section] not BODY[section],

I was looking at the following example on page 6:

      C: a001 FETCH 2 BODY[3.CONVERT ("APPLICATION/PDF")]
      S: * 2 FETCH (BODYPARTSTRUCTURE[3] ("APPLICATION" "PDF" () NIL 
         NIL "Base64" 2135 NIL NIL NIL) BODY[3] {2135}
         <the document in .pdf format>
         )
      S: a001 OK FETCH COMPLETED

BODYPARTSTRUCTURE will return the structure of the converted part. But 
its content is actually is returned in BODY[<section>].

> so seems that if the client requested the same section twice, the 
> client could disambiguate them as BODY vs BODYPARTSTRUCTURE.

I was talking about the following case:

      C: a002 FETCH 2 BODY[3.CONVERT ("APPLICATION/PDF")]  BODY[3]

Ok, it might be a contrived example, but it is still valid. A better one is:

      C: a003 FETCH 2 BODY[3.CONVERT ("APPLICATION/PDF")]  
BODY[3.CONVERT ("TEXT/HTML"]

For the second example (with tag a003), it is not possible to return 2 
BODYPARTSTRUCTURE[3] in the same FETCH response, because the client will 
not know which one is which. The client can potential try to guess by 
parsing it, but it wouldn't work for the case when "server knows better 
what the client supports".

On top of that, data for both BODY[3...] requests have to be returned as 
2 different BODY[3] items, which can't be repeated either, because the 
client would certainly have no idea which one is which.

> There would be a problem however if you requested the same section 
> with two different conversions, then you'd get two 
> BODYPARTSTRUCTURE[section] in the corresponding response, with only 
> the resultant mime-type and transcoding parameter information 
> differentiating them. However BODYPARTSTRUCTURE represents the 
> resultant conversion, not the requested conversion (unless STRICT is 
> used), so the client can't depend 100% on matching up the conversion 
> result in a BODYPARTSTRUCTURE with the request if there is such 
> ambiguity (e.g. asking for section 3 as both IMAGE/GIF and IMAGE/JPEG)

Exactly.

> In any case, I think the gist of the problem you pointed out is right, 
> but I had a nagging feeling I might be misunderstanding it because it 
> seemed to me that if you requested a non-converted section, plus a 
> converted version in the same request, the client could still tell the 
> difference.
>
> about the result of a CONVERT (that it is a BODYPARTSTRUCTURE along 
> with the converted data, and not BODY), we may also want to make it 
> return BODYPARTSTRUCTURE[section.CONVERT requested-params] instead of 
> BODYPARTSTRUCTURE[section]

I was about to propose the same. So the first example becomes:

      C: a001 FETCH 2 BODY[3.CONVERT ("APPLICATION/PDF")]
      S: * 2 FETCH (BODYPARTSTRUCTURE[3.CONVERT ("APPLICATION/PDF")] 
("APPLICATION" "PDF" () NIL 
         NIL "Base64" 2135 NIL NIL NIL) BODY[3.CONVERT 
("APPLICATION/PDF")] {2135}
         <the document in .pdf format>
         )
      S: a001 OK FETCH COMPLETED

> as well as extending it to allow error signaling on each converted 
> part. I'm open to extending the result and/or renaming it if there is 
> confusion with BODYSTRUCTURE/BODY.