Subject: Re: [lemonade] RE: Review request for draft-ietf-lemonade-convert-06.txt

From: Alexey Melnikov <[email-masked]>
Date: Fri, 04 May 2007 18:25:53 +0100

Hi Larry,
Thank you for your feedback!

Larry Masinter wrote:

>On the specific question of whether it is reasonable
>to re-use existing IETF registered values, well, I
>don't see any reason not to, if they're being used
>with the same meaning.
>
>But my broader concern is that the sets of values chosen
>don't really seem to match what's necessary to be effective.
>From a content creation point of view, it seems like
>you need to know a lot more, and I'm not sure why content
>conversion would be different. 
>
>At least, that seems to be the tone of W3C work in this
>area, e.g., http://www.w3.org/TR/DDR-requirements 
>http://www.w3.org/2005/MWI/DDWG/ which is ongoing,
>  
>
I've glanced over the two URLs and didn't see any registry for 
conversion attributes.
Do you know if there is a registry that I can reference in the draft I 
am editing?

>and even of commercial products in this area
>(http://www.adobe.com/products/creativesuite/devicecentral/).
>
>In general, I think coordinating IMAP with web access
>mechanisms is a good idea, even if the web work isn't
>happening in the IETF.
>  
>
Agreed.

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

---

From: "Larry Masinter" <[email-masked]>
Date: Fri, 4 May 2007 18:44:53 -0700

You might consider looking more closely at RFC 3297:
"Content Negotiation for Messaging Services based on Email"
http://tools.ietf.org/html/rfc3297

even though IMAP is different than SMTP, most of the concepts
about message adaptation should apply; perhaps it should
be more transparent whether the adaptation is done by the IMAP
server or somewhere upstream?

You might also consider the proposed (Experimental) transparent
content negotiation framework:

http://www.ietf.org/rfc/rfc2295.txt

I don't think there is a clear distinction between renditions
that are previously made available and those that are converted
on demand.

>> Do you know if there is a registry that I can reference in the draft I 

The registries are more about either content attributes,
device capabilities or preference parameters, but their
purpose is for selection or conversion -- each content
attribute is either an attribute of the source
or an attribute of the destination.

I know there are conversion parameters that don't easily
fit into that framework (e.g., 'scale down 50%') but I'm
not sure of their appropriateness for the context you're
considering. Under what circumstances is it preferable
for the client to supply conversion parameters rather than
output constraints based on client capabilities?

Larry

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 07 May 2007 23:49:01 +0100

Hi Larry,

Larry Masinter wrote:

>about message adaptation should apply;
>
Yes, this seems close enough to what we are doing.

>perhaps it should be more transparent whether the adaptation is done by the IMAP
IMAP CONVERT only deals with adaptations that happen once the message is 
delivered to a mailstore.
But IMAP CONVERT can be implemented in a proxy server that performs 
conversion after retrieving data from a vanilla IMAP server.

>or an attribute of the destination.
Yes, this is how they are used in IMAP CONVERT.
(Does this mean that IMAP CONVERT can reuse RFC 2506's registry :-) ?)

>considering.
Taking your specific example: if you mean that the "scale down 50%" can 
be replaced by "I want resolution X by Y", then I agree.

> Under what circumstances is it preferable
I can't think of any at the moment.

Regards,
Alexey

---

From: Randall Gellens <[email-masked]>
Date: Wed, 16 May 2007 08:04:04 -0700

>  I can't think of any at the moment.

Perhaps user override?  For example, a message contains a PowerPoint 
file, which the device can't render.  User asks to see content. 
Client asks server to convert to HTML, shows that to user, but it 
looks so bad the user can't figure it out.  So the user asks to see 
it as an image.

This is a bit of a stretch, I'll grant.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
It is the business of the future to be dangerous.

---

From: "Larry Masinter" <[email-masked]>
Date: Sun, 20 May 2007 15:41:29 -0700

Show this to me "as an image" vs "as HTML" is still supplying
output constraints.

Now, it's common for desktop applications that do conversion to allow
you to supply parameters for the conversion process, e.g.,
Photoshop, when scaling an image, offers 5 different algorithms.

But I don't think that's a use case for messaging, where you
are trying to deal with content that you otherwise can't render.

Larry

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: Wednesday, May 16, 2007 8:04 AM
To: Alexey Melnikov; Larry Masinter
Cc: 'Ted Hardie'; [email-masked]; 'Graham Klyne'
Subject: Re: [lemonade] RE: Review request for
draft-ietf-lemonade-convert-06.txt