Subject: Re: [lemonade] Open Issues with IMAP CONVERT

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Apr 2007 21:27:53 +0100

[email-masked] wrote:

>>>>3). There is one big issue surrounding INFORMATIONLOSS. I will publish         
>>>>
>>>>an updated draft shortly, but it will not tackle this issue. I will 
>>>>try to address the issue in the subsequent revision.
>>>>        
>>>>
>>>Could You elaborate this, please?
>>>      
>>>
>>The issue is how the client can figure out which bodypart was 
>>converted with loss when the client requested multiple 
>>conversions in a single FETCH command.
>>Some suggested to use URLs to identify the bodypart. Arnt wrote the
>>following:
>>    
>>
>>>Serious: I don't like the INFORMATIONLOSS response code - it's on the 
>>>      
>>>
>>>wrong response. As it stands, it means "one or more of the preceeding 
>>>
>>>untagged responses is approximate rather than exact". Either it should 
>>>      
>>>
>>>be a flag on BODYPARTSTRUCTURE to show exactly which conversion is 
>>>approximate, or it should carry some arguments to specify the inexact 
>>>      
>>>
>>>bodypart(s).
>>>      
>>>
>Can we take a moment and think about why we need this?
>I mean I am not sure that we need this:
> - Probably no client will upscale->no loss.
> - Most clients will downscale -> there is always loss.
> - Some clients might use format/size conversions-> If client requests
>explicit conversion, it should be aware that there might be loss, while
>if the client left the conversion choice up to the server, it should
>assume that there was a loss.
>
>What do You think?
>  
>
Hi Zoltan,
You are making convincing arguments for dropping the response code.

Would anybody like to defend why the INFORMATIONLOSS is needed?

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Dave Cridland <[email-masked]>
Date: Wed, 11 Apr 2007 11:51:04 +0100

> Would anybody like to defend why the INFORMATIONLOSS is needed?

Well, I'm not convinced it's needed, but I'll advance an argument.

Let's assume that a client has very limited capability for character 
sets. A message arrives in, say, Japanese, and the client requests a 
conversion of the textual message to ASCII. Severe information loss 
will take place, and the user almost certainly needs to know that 
this is the case.

Conversly, it may well be useful to know that the converted body part 
has been losslessly transcoded under some circumstances. Let's 
suppose an audio part arrives, and the user wishes to listen to it - 
if the converted part is unintelligible, but the part has been 
losslessly converted, it would be reasonable for the user to reply 
with a message saying so. However, if the process of conversion is 
responsible for the problem, then the user might either wish to wait 
until they are at a more capable client, or else reply asking for a 
different format.

This all said, I think Zoltán's arguments have convinced me that the 
common case will be INFORMATIONLOSS, and as a result we should be 
flagging lossless conversions if we flag anything at all.

I'd put myself at around 70% in favour of flagging lossless 
conversions, incidentally.

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: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 11 Apr 2007 13:02:24 +0200

In general terms, I think that if a test suite (or conformance tester) 
needs to distinguish between two cases, then it should be possible to 
do so using protocol. Testing is enough of a reason.

In other words, this is bad

* BYE I logged you out for this reason
* BYE I logged you out for that reason

because only human-readable text distinguishes between the two cases.

Good would be to use protocol, perhaps like this:

* BYE [THISREASON] logout for whatever reason
* BYE [THATREASON] some human-readable text

So: Is it likely that a test suite or conformance tester would need to 
distinguish between lossless and lossy conversion? Sounds plausible to 
me, but I've only glanced at the document.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 11 Apr 2007 14:48:19 +0100

> me, but I've only glanced at the document.

Conformance tester might not be a good enough reason to have 
INFORMATIONLOSS (or its opposite).

We might also have problems with defining what lossless conversion 
means. E.g. can conversion from text/html to text/plain be lossless?

---

From: Ned Freed <[email-masked]>
Date: Wed, 11 Apr 2007 07:58:54 -0700 (PDT)

> Well, I'm not convinced it's needed, but I'll advance an argument.

I think the information can be very useful in some cases, but only if you know
which parts had conversion losses and which parts did not. So while I remain
unpersuaded that a general "loss occcured" reply is useful, I can think of
cases where a "this part was converted with loss" would be.

> will take place, and the user almost certainly needs to know that

This is exactly the case that came to mind for me as well, although a better
example would perhaps be conversion from, say, utf-8 to, say, iso-2022-jp. In
the case of forcing everything to US-ASCII the only time it will work well is
if the original material was in fact US-ASCII with a poor label choice of
UTF-8. In the case of UTF-8 to ISO-2022-JP, it is entirely reasonasble for
UTF-8 to be used regardless of whether the underlying text is Japanese (in
which case conversion to ISO-2022-JP is fine) or Arabic (in which case the
conversion is going to trash the content).

A similar case might arise with conversion of formatted documents. In fact I
beleive this is the case that led to the inclusion of "conversion with loss"
responses in X.400.

> conversions, incidentally.

I can't get excited about whether or not there's a NOT in front of the
reported condition.

				Ned

---

From: "Robert A. Rosenberg" <[email-masked]>
Date: Wed, 11 Apr 2007 13:28:06 -0400

At 14:48 +0100 on 04/11/2007, Alexey Melnikov wrote about Re: 

>means. E.g. can conversion from text/html to text/plain be lossless?

That depends on what information is being lost. If it is only 
formatting (ie: You get the same text/plain as would occur with a 
multi-part/alternate email) then it is lossless. OTOH, if there are 
HTML entry characters and these can not be displayed in the 
text/plain charset then there is some information loss.

---

From: <[email-masked]>
Date: Thu, 12 Apr 2007 11:09:30 +0300

Hi Dave,
I added some responses below.

>>> explicit conversion, it should be aware that there might be loss, 
>>> while if the client left the conversion choice up to the server, it 
>>> should assume that there was a loss.
>>> 
>>> What do You think?
>>>  
>> Hi Zoltan,
>Let's assume that a client has very limited capability for 
>character sets. A message arrives in, say, Japanese, and the 
>client requests a conversion of the textual message to ASCII. 
>Severe information loss will take place, and the user almost 
>certainly needs to know that this is the case.

I suppose in this case the conversion shoud fail because there is no way
to convert Japanese to ASCII.

>Conversly, it may well be useful to know that the converted 
>body part has been losslessly transcoded under some 
>circumstances. Let's suppose an audio part arrives, and the 
>user wishes to listen to it - if the converted part is 
>unintelligible, but the part has been losslessly converted, it 
>would be reasonable for the user to reply with a message 
>saying so. However, if the process of conversion is 
>responsible for the problem, then the user might either wish 
>to wait until they are at a more capable client, or else reply 
>asking for a different format.

Could You provide a use case for this: the process of conversion is
responsible for creating unintelligible content.
I was thinking something like: You receive a large image (1600*1200),
and Your client requests coverting it to a server-selected size (and
server picks 32*32). But then I realized that in this case the culprit
is not the process of conversion. It is the server for picking an
extremently low resolution - instead of creating unintelligible content,
the server should fail this request instead.

---

From: "Eric Burger" <[email-masked]>
Date: Mon, 23 Apr 2007 16:39:22 -0700

I still do not see the use case.  Humans are in the loop and will notice
garbage in the message.  Vendors of conversion tools will learn when to
give up, as in the example below which will at best result in a
checker-board or, more likely, a 32x32 black square.  The parameters for
when to give up and just say, "I cannot convert this for you" is way
beyond our charter and expertise.  We only need to provide the mechanism
for specifying how to signal the inability to convert something because
the converter knows the result will be useless.

Likewise, VIRTUALLY ALL conversions will be lossy; that is what the user
is asking for!  If anything, it may be academically interesting to note
that the conversion was lossless.  Thus, I would offer either we do a
conversion, indicate we cannot do a conversion, or indicate the results
of the conversion would be useless.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, April 12, 2007 4:10 AM
To: [email-masked]; [email-masked]
Subject: RE: [lemonade] Open Issues with IMAP CONVERT

Hi Dave,

>conversion of the textual message to ASCII.
>Severe information loss will take place, and the user almost certainly 
>needs to know that this is the case.

>has been losslessly transcoded under some circumstances. Let's suppose 
>an audio part arrives, and the user wishes to listen to it - if the 
>converted part is unintelligible, but the part has been losslessly 
>converted, it would be reasonable for the user to reply with a message 
>saying so. However, if the process of conversion is responsible for the

>problem, then the user might either wish to wait until they are at a 
>more capable client, or else reply asking for a different format.

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

---

From: "Eric Burger" <[email-masked]>
Date: Mon, 23 Apr 2007 16:39:22 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, April 12, 2007 4:10 AM
To: [email-masked]; [email-masked]
Subject: RE: [lemonade] Open Issues with IMAP CONVERT

Hi Dave,