Subject: [lemonade] WGCL Convert-05

From: Eric Burger <[email-masked]>
Date: Sun, 14 Jan 2007 20:21:49 -0800 (PST)

Just a reminder that WGLC closes in 3 days.  I haven't heard boo.

"Great idea and implementation"

"So less than ideal I couldn't bring myself to comment"

____________________________________________________________________________________
No need to miss a message. Get email on-the-go 
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail 

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 15 Jan 2007 11:14:12 +0100

> "So less than ideal I couldn't bring myself to comment"

Three serious problems and some irritants.

Serious: The document could do a better job of explaining why it's 
useful. It never has persuaded me to do much more than skim and ignore 
it. Mark would say «neat to have, not need to have». Maybe it _is_ a 
need-to-have, but reading the abstract/introduction hasn't shown me any 
need.

In section 3, the second paragraph could mention an additional reason to 
keep the original format: S/MIME. If you change the format, you break 
all signatures.

The examples on page 6 urgently need better formatting.

In 6.1, this sentence makes no sense to me: «A client requesting the 
server annotation "/convert/text/plain" MUST return "text/plain" as an 
allowed destination conversion.» I suggest removing the word «and» at 
the head of the following sentence.

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

In 6.1, «at the minimum» sounds wrong to my ears. Perhaps «at a minimum»?

In 6.1.1, I think the sentence on resize needs to make up its mind. 
Either it's an item in the list, in which case it's a SHOULD, or it's 
paragraph of its own after the list, in which case it's a gentle 
suggestion.

The formal syntax has lots of formatting problems. Because of that I 
didn't look closely for other problems.

Serious: The security considerations section omits a new attack: A 
client can APPEND a carefully crafted bad message followed by FETCH to 
attack the server. If the server's conversion function or library has a 
security problem, this could result in provilege escalation or denial 
of service.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 15 Jan 2007 17:17:31 +0000

>"So less than ideal I couldn't bring myself to comment"
The current version doesn't address issues raised by Dave and myself. I 
am still waiting for an update.

---

From: Mark Crispin <[email-masked]>
Date: Mon, 15 Jan 2007 10:07:08 -0800 (PST)

> approximate, or it should carry some arguments to specify the inexact

This also begs the question: why should such a concept exist in IMAP at 
all?

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 15 Jan 2007 20:36:38 +0100

Mark Crispin writes:
>> 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).
>
> This also begs the question: why should such a concept exist in IMAP at all?

Wasn't the answer to that question «OMA demand»?

Arnt (who didn't dare check whether this thing is required by profile-bis)

---

From: Mark Crispin <[email-masked]>
Date: Mon, 15 Jan 2007 11:46:35 -0800 (PST)

> Wasn't the answer to that question «OMA demand»?

And why isn't "no" an acceptable answer?  As in "no, we refuse to give you 
inexact data; we insist upon giving you precise, exact data."?

> Arnt (who didn't dare check whether this thing is required by profile-bis)

:-)

-- Mark --

http://panda.com/mrc

---

From: "Ben Last" <[email-masked]>
Date: Tue, 16 Jan 2007 08:11:38 -0000

> approximate, or it should carry some arguments to specify the inexact 

Apologies for the delay in responding: I plead pressure of work and the
oncoming juggernaut that is the 3GSM conference...

This (above) got me thinking about implementations (from the client
point of view): what entity makes the decision about what conversion to
apply, given that information loss is a problem? If it's the client, it
needs sufficient information to make a programmatic decision.  In the
current proposal, information loss is only signalled after a conversion.
In the worst case, that might lead to a client requesting a conversion,
noting the loss and re-requesting a different conversion; extra work for
the server.

Unfortunately, of course, the obvious solution is for the server to be
able to indicate whether or not information loss would occur, which
almost certainly requires some stages of conversion to take place in
order to determine that.  However, that would be more efficient than
doing the full conversion *plus* network transmission of all or part of
the result to the client before the client can identify that information
loss has occurred.

As an outline proposal (and I humbly acknowledge that any or all of this
is rather late and may be inapplicable), perhaps it should be possible
for the client to request a number of conversion formats that it will
accept, in order of preference, and for the server to respond with the
first format in which information loss does not occur?  This is, in some
ways, like the client specifically requesting SERVEROVERRIDE behaviour.

Second issue: size of the converted data.  Our client makes use of the
size of a body section that's to be downloaded for two reasons: first,
we can check to see whether there is enough space to store it (and
invoke smart storage management if required).  On a storage-limited
device, that's important: we've seen users who are used to PCs and
ignore the size of attachments when starting a download.  Secondly, we
download any section in chunks (for networking and command-interleaving
reasons) and that requires us to keep track of the current amount
downloaded and the final amount to download.  At best, the client should
have a way to request that size *before* requesting conversion.  Since
the sizes resulting from different conversions may vary consierably, the
client may want to request a set of sizes in order to determine the best
format to download.

Regards
Ben

R&D Manager
EMCC Software Ltd

---

From: Dave Cridland <[email-masked]>
Date: Mon, 15 Jan 2007 10:41:11 +0000

> need-to-have, but reading the abstract/introduction hasn't shown me 
It's kind of a need to have, but this, like so many things, is a 
matter of opinion.

There's two issues here:

1) In general, a handheld device might well not have the ability to 
view arbitrary attachment types, and it'd be useful to view these 
even if output is degraded in some way, such as lower resolution, 
loss of formatting, or whatever. In other words, this is the 
possibility that without something like this, some devices might no 
be able to access the information at all. I would hold that this is 
need to have, for the nature of what we're trying to do.

2) According to various bits of research, people do not typically 
edit attachments on a mobile device, they view them. Given that in 
general, even when a mobile device can display attachments, it does 
so by local conversion of some kind, it seems sensible to allow this 
case to be optimized on the wire. I'd say this is neat to have.

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