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

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 Apr 2007 10:02:41 +0100

Randall Gellens wrote:

> 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?

Right. -06 uses '/convert/image/@/types' for the same purpose.

>   LPerhaps also likewise for the parameters?

I haven't done this for parameters. If people think that this is needed, 
it can be easily added.

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

Right. The current text recommends that client check 
/convert/<type>/<subtype>/types first, and if it is not found, then the 
client should fall back to checking /convert/<type>/@/types.

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