Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt

From: [email-masked]
Date: Tue, 30 May 2006 18:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF.

	Title		: CONVERT
	Author(s)	: S. Maes, R. Cromwell
	Filename	: draft-ietf-lemonade-convert-03.txt
	Pages		: 18
	Date		: 2006-5-30
	
CONVERT defines extensions to the IMAPv4 Rev1 protocol [RFC3501] for 
optimization in a mobile setting, aimed at allowing adaptation and 
transcoding of attachments as needed by the client. Conversion 
(adaptation, transcoding) may be requested by the client and 
performed by the server on a best effort basis or decided by the 
server based on its knowledge of the client capabilities, user or 
administrator preferences or its settings.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-lemonade-convert-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-lemonade-convert-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: <[email-masked]>
Date: Wed, 31 May 2006 11:34:09 +0300

Hi Stephane,
I am looking for clarification.
What is the purpose of section 10. Compression?
I mean what does it have to do with the conversion draft? I thought compression is applicable to anything. As such, it is not necessary to describe it in this draft.

Best regards: Zoltán Ördögh
E-mail: zoltan.ordogh at nokia.com
Phone: +358 50 386 0566

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: 31 May, 2006 01:50
To: [email-masked]
Cc: [email-masked]
Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt 

	Title		: CONVERT
	
CONVERT defines extensions to the IMAPv4 Rev1 protocol [RFC3501] for optimization in a mobile setting, aimed at allowing adaptation and transcoding of attachments as needed by the client. Conversion (adaptation, transcoding) may be requested by the client and performed by the server on a best effort basis or decided by the server based on its knowledge of the client capabilities, user or administrator preferences or its settings.

To remove yourself from the I-D Announcement list, send a message to [email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then
	"get draft-ietf-lemonade-convert-03.txt".

A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Send a message to:
	[email-masked].
In the body type:

---

From: "Stephane H. Maes" <[email-masked]>
Date: Wed, 31 May 2006 05:10:07 -0700

We decided in Dallas to consider object level compression via convert.

Stephane 

_____
Stephane H. Maes, PhD,
Director of Architecture, Mobile, Voice, and Communications Platforms, Oracle.
Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296
e-mail: [email-masked]
IM: shmaes (AIM/Y!/skype) or [email-masked] (MSN Messenger) or [email-masked] (Google)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, May 31, 2006 1:34 AM
To: [email-masked]
Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt

Hi Stephane,

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: 31 May, 2006 01:50
To: [email-masked]
Cc: [email-masked]
Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt 

	Title		: CONVERT

Send a message to:
	[email-masked].
In the body type:

Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

---

From: <[email-masked]>
Date: Wed, 31 May 2006 15:51:03 +0300

Aha, I knew I was missing something, thank You.
So it means that now the client needs to request compression explicitly every time, right?

-----Original Message-----
From: ext Stephane H. Maes [mailto:[email-masked]] 
Sent: 31 May, 2006 15:10
To: [email-masked]
Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt

Stephane 

_____
Stephane H. Maes, PhD,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, May 31, 2006 1:34 AM
To: [email-masked]
Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt

Hi Stephane,

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: 31 May, 2006 01:50
To: [email-masked]
Cc: [email-masked]
Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt 

	Title		: CONVERT

Send a message to:
	[email-masked].
In the body type:

---

From: Randall Gellens <[email-masked]>
Date: Wed, 31 May 2006 08:38:05 -0700

Please edit the document to replace non-US-ASCII characters (I think 
there are a number of instances where 'smart quotes' in Word were 
converted to 8-bit characters.)

I'd suggest deleting the first two paragraphs of Section 2 (Relation 
with other E-mail specifications), and replace the third paragraph 
with "Conversion during streaming of attachments is out if scope of 
the CONVERT extension."

I'd suggest changing Section 3 from:
    This document does not specify how conversions are to be done by the
    server. It is however noted that the conversion MUST NOT affect the
    document stored in the message storage server in order to remain
    accessible unaffected through other clients that do not request
    conversion as well as in order to allow replies or forward of the
    documents as they were originally received by the server.

To:
    Conversions only affect what is sent to the client; the original data
    in  the message store MUST NOT be altered.  This document does
    not specify how the server performs conversions.

    (The requirement that original data be unaltered allows such data to
    remain accessible by other clients, permits replies or forwards of the
    documents, and preserves BODYSTRUCTURE and related information.)

I'd also suggest changing the name of Section 3, perhaps to "Scope of 
Conversions".

In Section 4.1, is LDELIVER there by accident?

In Section 4.2, what does "For any proposed conversion, the client 
MAY discover a list of optional parameters that the conversion SHOULD 
accept" mean?

Also in Section 4.2, perhaps it would be more compact, and easier on 
clients and servers, to advertise the supported conversions under the 
media type rather than sub-type?  So rather than have 
'/convert/image/jpeg' just have '/convert/image' contain the 
supported destination formats?  LPerhaps also likewise for the 
parameters?  This may come down to how these mailbox annotations are 
generated and used: if servers generate the annotations dynamically, 
and if clients fetch and consume them immediately prior to requesting 
a conversion, then having the extra levels of hierarchy are fine. 
But if the data will be stored or cached by either side, flattening 
seems beneficial.  I know the example shows a server that can convert 
from only one image format but can convert into a number of them. 
But is that realistic?  It's also true that it would be possible for 
conversion parameters to be advertised that don't make sense or 
aren't supported for all subtypes, but how likely is it that clients 
would request them, and even so, this can be handled with an error.

In the case of some media types (especially 'application') it might 
not make sense to flatten the hierarchy.

In Section 5, if the client asks for US-ASCII, is it proper for the 
server to unilaterally return UTF-8?  If the client supports UTF-8, 
wouldn't it have asked for it?  It might be better for the server to 
either encode the non-US-ASCII characters or return an error.  I 
realize the STRICT qualifier can force this, but it seems to apply to 
both media type/subtype and parameters.

Also in Section 5, the text mentions the server having knowledge of 
the device: how does the client identify a specific device?  Users 
may have multiple devices.

Also in Section 5, the wording says that if a client doesn't use 
STRICT the server MAY honor its request.  That seems a strange way to 
allow the server to use whatever knowledge it has of the client. 
Would it make more sense to have a ORWHATEVER modifier for this?  So 
STRICT would mean MUST do this, ORWHATEVER means MAY do this, and 
nothing means SHOULD do this.  Alternatively, the destination format 
and parameters could be omitted to request the server to use its 
knowledge.

In  Section 6, what is a "CONVERT server"?  Is it an IMAP server that 
supports CONVERT, or is it a media conversion server utilized by the 
IMAP server to perform conversions?

In Section 6.1, I think you meant "while preserving" instead of 
"without preserving".

In Section 6.1.1, what does it mean to "recommend" SHOULDs?

Also in Section 6.1.1, does "conversion of HTML and XHTML documents 
to text" mean to 'text/plain'?

In Section 8, would it be better to use NO rather than BAD?  These 
errors are dependent on the target data or server resources.  BAD 
does not seem appropriate.

In Section 10, I really think compression belongs in its own 
document.  Personally, I think Ned and others made very compelling 
arguments in Dallas that there are no use cases where clients 
wouldn't want compressible data compressed, but even if there turn 
out to be, and even if compression therefore ends up using CONVERT, 
it can be an extension to it.  But otherwise compression can be 
something that the server advertises support for and the client 
requests once ("compress at will") with the server determining based 
on its own criteria which data to compress.

In Section 11, I think encryption also belongs in its own document. 
There are too many issues with it that should be dealt with on their 
own, not tied up with conversion.

In Appendix A, what does "The enterprise network is assumed to be 
secure" mean?  Secure in what way?

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Implementation is the sincerest form of flattery.

---

From: Randall Gellens <[email-masked]>
Date: Wed, 31 May 2006 08:43:23 -0700

>  We decided in Dallas to consider object level compression via convert.

I don't think we did.

It was proposed in Dallas that compression be done (along with 
several other proposals on compression) but I believe Ned and others 
made compelling arguments that compression should be done by the 
server compressing data whenever it makes sense to do so and the 
client can decompress.

What convinced me was the absence of any use cases where the client 
wouldn't want data to be compressed (assuming it can decompress). 
Since the server has access to the data prior to compression, it is 
in the best position to determine if compression makes sense.  It's 
been stated that decompression is cheaper for a mobile client than 
over the air reception, so its always in the client's interests.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
We adore chaos because we love to produce order.
                                  --M. C. Escher

---

From: Randall Gellens <[email-masked]>
Date: Wed, 31 May 2006 08:38:05 -0700

To:

---

From: Randall Gellens <[email-masked]>
Date: Wed, 31 May 2006 08:43:23 -0700

I don't think we did.

---

From: Dave Cridland <[email-masked]>
Date: Wed, 31 May 2006 18:36:47 +0100

>>  We decided in Dallas to consider object level compression via 
No, we did, but we didn't reach consensus that we would be mandating 
object-level compression at all - we just decided that if we were 
going to do it, we'd do it via conversion.

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: Ned Freed <[email-masked]>
Date: Wed, 31 May 2006 10:49:58 -0700 (PDT)

> server compressing data whenever it makes sense to do so and the

To be fair, I also pointed out that a side effect of object conversion could be
a significant reduction in object size, and that in some cases this will
produce a much smaller object than any general compression scheme ever could.
Obvious examples are the conversion of hi-res audio or video to formats more
appropriate for use on a cell phone with limited visual and audible fidelity.

But this falls far short of adding a compression facility to the convert
extension. I remain to be convinced that this is a good idea.

> wouldn't want data to be compressed (assuming it can decompress).

Exactly so. I also find the argument that compressing already compressed
data is an issue to be pretty weak: Modern compression formats provide the
ability to switch off compression, and it shouldn't be hard to have a list
of formats where compression is unlikely to be useful and can be disabled.

> over the air reception, so its always in the client's interests.

Also true. A really smart server could determine in advance whether a given
object is worth compressing before transfer. Of course such calculations go
straight into the dumpster when a conversion operation is used - in that
case the server has to go by general media type characters or else perform
the compression and see if it helps before sending the data.

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 31 May 2006 20:19:21 +0200

Ned Freed writes:
> I also find the argument that compressing already compressed data is 
> an issue to be pretty weak: Modern compression formats provide the 
> ability to switch off compression, and it shouldn't be hard to have a 
> list of formats where compression is unlikely to be useful and can be 
> disabled.

Not very hard.

If a COMPRESS=DEFLATE + BINARY server knows to send Z_SYNC_FLUSH when a 
literal starts and finishes and is big enough to make the flush 
worthwhile, and sets its compression level to zero when the first two 
bytes of the literal are either 0xFF 0xD8 or 0x1F 0x8B, you're already 
more than 80% of the way there.

A COMPRESS=DEFLATE receiver just works, even when the sender plays such 
tricks. Its zlib receives the literal uncompressed and the client never 
knows that anything hapened.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 31 May 2006 20:22:43 +0200

Arnt Gulbrandsen writes:
> If a COMPRESS=DEFLATE + BINARY server knows to send Z_SYNC_FLUSH when 
> a literal starts and finishes and is big enough to make the flush 
> bytes of the literal are either 0xFF 0xD8 or 0x1F 0x8B, you're 
> already more than 80% of the way there.

Shall I write a new revision where I explain this in bothersome detail?

Arnt

---

From: Randall Gellens <[email-masked]>
Date: Wed, 31 May 2006 12:15:52 -0700

At 8:22 PM +0200 5/31/06, Arnt Gulbrandsen wrote:

>  Arnt Gulbrandsen writes:
>>  If a COMPRESS=DEFLATE + BINARY server knows to send Z_SYNC_FLUSH 
>> when a literal starts and finishes and is big enough to make the 
>> flush worthwhile, and sets its compression level to zero when the 
>> first two bytes of the literal are either 0xFF 0xD8 or 0x1F 0x8B, 
>> you're already more than 80% of the way there.
>

Yes, please.
-------------- Randomly-selected tag: ---------------
Computer Science: solving today's problems tomorrow.