Subject: [lemonade] Comments on draft-ietf-lemonade-convert-06.txt

From: Randall Gellens <[email-masked]>
Date: Fri, 20 Apr 2007 17:28:00 -0700

----------
Section 1:

OLD:
    This document defines the CONVERT extension to IMAP4 [RFC3501].
    It defines additional enhancements for optimization in a mobile
    setting: extensions to the
    IMAP4Rev1 protocol [RFC3501] that allows adaptation and transcoding
    of body parts as needed by the client.

NEW:
    This document defines the CONVERT extension to IMAP4 [RFC3501].
    CONVERT provides adaptation and transcoding
    of body parts as needed by the client.  This is primarily intended to be
    useful to mobile clients.

----------
Section 4.2:

OLD:
    Such annotation
    would contain a "value.shared" attribute, which is a semicolon
    separated list of output formats.

NEW:
    The "value.shared" attribute of this annotation contains a semicolon
    separated list of type/subtype output formats.

----------
OLD:
    Note that a special annotation named "/convert/<type>/@/types" can
    be used to reference any subtype of <type> media type.

NEW:
    In addition to the subtype-specific annotations, a special "wildcard"
    annotation named "/convert/<type>/@/types" MAY
    be used to reference any subtype of <type> media type.

----------
OLD:
    "/convert/sourcetype/destinationtype/params" annotation.

NEW:
 
"/convert/<source-type>/<source-subtype>/<dest-type>/<dest-subtype>/params" 
annotation.

----------
OLD:
    or it may present the parameters as a GUI

NEW:
    or it might, for example,  present the parameters as a GUI

(avoid confusion with normative words)

----------
OLD:
    parameter names should be standardized

NEW:
    parameter names is expected to be standardized

(just a guess, but the "should" is confusing")

Also, do we want to perhaps reference RFC 2912 here?

----------
Section 5:

OLD:
    The CONVERT extension defines a FETCH extension

NEW:
    CONVERT defines a FETCH extension

----------
OLD:
    same media type, with different encoding parameters.

NEW:
    same media type with different encoding parameters.

(delete comma as it is confusing)

----------
OLD:
    also expected to work with IMAP BINARY data item extension

NEW:
    also expected to work with the IMAP BINARY data item extension

----------
OLD:
    Each request for BODY or BINARY FETCH data item

NEW:
    Each request for a BODY or BINARY FETCH data item

----------
OLD:
    the client can use a special marker NIL

NEW:
    the client MAY use a special marker NIL

----------
OLD:
    Note that support for such "default
    conversion" request is OPTIONAL in servers.

NEW:
    Note that support for such "default
    conversion" requests is OPTIONAL in servers.

Also, how does the client discover if the server provides such support?

I think that the only use in providing this default conversion is to 
support very simple clients.  Thus, it doesn't make sense to make 
this an option for servers, since the very clients that might need it 
might also be too simple to have multiple code paths to handle it not 
being available, and anyway, what is the client to do?  If we are 
going to include default conversions, I think they should be 
mandatory for servers.  How the server decides remains out of scope, 
and we aren't requiring the server to make good choices (that's a 
quality-of-implementation thing), but this can't be an option.  It 
also doesn't seem to be any more of a burden to require the server to 
pick something if it is going to support something.

----------
Section 6:

OLD:
    they may
    decline to honor some requests

NEW:
    they MAY
    decline to honor some requests

Also, should we say anything here about how the server declines? 
That is, what does it send to the client?  Some other charset, a NO 
response, a rude insult?

----------
Section 6.1.1:

Do we really want to say SHOULD for text/html to text/plain?  Is this 
actually useful for any mobile device that can support IMAP?  I 
wonder if text/plain to text/html wouldn't be just as useful? (it is 
easier to implement).

----------
OLD:
    formats like proprietary document formats

NEW:
    formats such as proprietary document formats

----------
Section 8:

OLD:
    the server can reply

NEW:
    the server MAY reply

Do we want to say what the other server choices are?  Use some 
default values of its choosing?

----------
OLD:
    malformed MIME types may also generate

NEW:
    malformed MIME types MAY also generate

----------
OLD:
    (e.g. internal error

NEW:
    (e.g., internal error

----------
OLD:
    NO response should be returned

NEW:
    NO response SHOULD be returned

But why is this a SHOULD?  What are the server's other choices?  The 
next paragraph says to use NO for permanent errors.  I agree it would 
be helpful to let the client know if the error is permanent or 
temporary, so the client knows to retry later or not.  Something like 
"NO [TEMPFAIL]", or an additional TEMPFAIL extension response code 
later in the section?

----------
OLD:
    Otherwise, the server should return an OK response

NEW:
    Otherwise, the server SHOULD return an OK response

----------

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Deja Moo: The feeling that you've heard this bull before.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 26 Apr 2007 11:02:53 +0100

Hi Randy,
Thank you for the review! I've made most of the changes you've suggested.

I would like to discuss more significant issues. Below I've grouped them 
by topic and named them.

1). IANA registry for parameters:

>    parameter names are expected to be standardized
>

I was just planning to establish a new IANA registry. Or we can reuse an 
existing one. Suggestions are welcome.

Having an informative reference to RFC 2912 would be fine.

>    the client MAY use a special marker NIL

I don't want to use MAY, as the server might not support the special 

Currently the client has to try to use it. If it receives a tagged NO 
response, then default conversion is not supported.

> support very simple clients.  Thus, it doesn't make sense to make this 
> an option for servers, since the very clients that might need it might 
> also be too simple to have multiple code paths to handle it not being 
> available, and anyway, what is the client to do?  If we are going to 
> include default conversions, I think they should be mandatory for servers.

If we make it mandatory for servers, we need to define how it can be 
implemented, at least in general purpose IMAP servers. I have no idea 
what the choices are, especially which choices are good. So as a server 
implementor I would need some guidance about implementing this feature.

> How the server decides remains out of scope, and we aren't requiring 
> the server to make good choices (that's a quality-of-implementation 
> thing), but this can't be an option.

We don't want to encourage bad choices either.

> It also doesn't seem to be any more of a burden to require the server 
> to pick something if it is going to support something.

3). Mandatory to implement conversion:

> ----------
> Section 6.1.1:
>
> Do we really want to say SHOULD for text/html to text/plain?

I think we had this discussion before and I thought that consensus was 
declared.
However I feel that many people are unhappy with the choice, so maybe we 
don't actually have a consensus.

Do you think charset conversion (ISO-8859-* to UTF-8) is better?

> Is this actually useful for any mobile device that can support IMAP?

It is useful for a desktop client that doesn't support HTML.

> I wonder if text/plain to text/html wouldn't be just as useful? (it is 
> easier to implement).

It is easier, but I think it is pointless.

>    malformed MIME types MAY also generate

The whole sentence was replaced with:
   A syntactically invalid MIME media type SHOULD
   generate a BAD tagged response from the server. An unrecognized MIME
   media type generates a NO tagged response.

Does this address your concern?

---

From: Randall Gellens <[email-masked]>
Date: Thu, 26 Apr 2007 10:24:58 -0700

At 11:02 AM +0100 4/26/07, Alexey Melnikov wrote:

>  I would like to discuss more significant issues. Below I've grouped 
> them by topic and named them.
>
>  I was just planning to establish a new IANA registry. Or we can 
> reuse an existing one. Suggestions are welcome.
>

Sorry, I actually meant RFC 2506, which established an IANA registry 
for media features.  I was wondering if this could be re-used for our 
purposes.

>  I don't want to use MAY, as the server might not support the 
> special marker. More on this below:

I think we can't make this optional.  Either servers MUST support it, 
or we drop the feature.  More on this below.

>  Currently the client has to try to use it. If it receives a tagged 
> NO response, then default conversion is not supported.

I think that's a problem.  The extra complexity this imposes on the 
client outweighs the benefit of the feature, I think.

>
>>  I think that the only use in providing this default conversion is 
>> to support very simple clients.  Thus, it doesn't make sense to 
>> make this an option for servers, since the very clients that might 
>> need it might also be too simple to have multiple code paths to 
>> handle it not being available, and anyway, what is the client to 
>> do?  If we are going to include default conversions, I think they 
>> should be mandatory for servers.
>
>  If we make it mandatory for servers, we need to define how it can 
> be implemented, at least in general purpose IMAP servers. I have no 
> idea what the choices are, especially which choices are good. So as 
> a server implementor I would need some guidance about implementing 
> this feature.

Providing this guidance is good, but I think it is a harder problem 
then what we're trying to solve with this draft, so I'd say it should 
be done elsewhere.

We could compromise and add some clearly non-normative text that 
makes general suggestions.  For example, servers could keep a list of 
supported destination media subtypes.  If these are ranked according 
to some guess as to how widespread client support is, or how 
difficult rendering is, then the server can choose as a default 
conversion, absent any information as to the client's specifics, the 
highest-ranked non-identity subtype.  If the server has information 
as to what the client supports, it can pick the highest-ranked 
supported subtype, or the specific client support information can 
include a ranking.

>
>>  How the server decides remains out of scope, and we aren't 
>> requiring the server to make good choices (that's a 
>> quality-of-implementation thing), but this can't be an option.
>

It's subjective which default conversions are good versus bad 
choices.  But it's objective that making default conversion optional 
for servers complicates clients.  So we should either make this 
mandatory or drop it entirely.

>
>>  It also doesn't seem to be any more of a burden to require the 
>> server to pick something if it is going to support something.

>  I think we had this discussion before and I thought that consensus 
> was declared.
>  However I feel that many people are unhappy with the choice, so 
> maybe we don't actually have a consensus.
>

Better and more useful, perhaps.

>  It is useful for a desktop client that doesn't support HTML.

But are there any clients that don't support HTML?

>
>>  I wonder if text/plain to text/html wouldn't be just as useful? 
>> (it is easier to implement).
>

Perhaps not.  If a client has an HTML display engine, it is easier to 
use it than to reformat plain text to fit a small screen.  As an 
example, Eudora for Palm makes use of the Qpopper x-mangle option to 
have plain text (both format=flowed and format=fixed) converted to 
HTMl to make rendering easier.

>  Does this address your concern?

Yes, thanks.

-------------- Randomly-selected tag: ---------------
If you attack stupidity you attack an entrenched interest with friends
in government and every walk of public life, and you will make small
progress against it.                               --Samuel Marchbanks

---

From: Ted Hardie <[email-masked]>
Date: Thu, 26 Apr 2007 12:54:04 -0700

At 10:24 AM -0700 4/26/07, Randall Gellens wrote:
>> I was just planning to establish a new IANA registry. Or we can reuse an existing one. Suggestions are welcome.
>>
>Sorry, I actually meant RFC 2506, which established an IANA registry for media features.  I was wondering if this could be re-used for our purposes.

I thought that Section 6's statement on parameters put the OMA-specified
names as guidelines:

   IMAP servers which support CONVERT MAY support additional transcoding
   parameters for each media type. All such servers MUST minally support
   recognition of charset for text/* MIME types, although they may
   decline to honor some requests. For media types other than text, it
   is beyond the scope of this document to define conversion parameters.
   In general however, CONVERT compliant servers MAY choose to support
   additional parameters, and if so, they SHOULD follow the OMA STI 1.0
   spec [OMA-STI] adopting the same parameter names as defined in
   section 5.2.4 and above for the most popular image/*, video/*, and
   audio/* codecs

One possibility would be to match the OMA terms to the RFC 2506
IETF registry terms either by adding terms or providing the alternate
name (width & height becoming something like size-x and size-y).
It would also be possible to use the OMA terms directly, using
the RFC 2506 global tree (e.g. g.oma.SOMETHING).

I am not entirely sure, however, whether this is the right way to go.
I think some of the directives described (crop, stretch, aspect ratio)
may be a little difficult to express.  If this interoperability is desired,
we can probably work it out, but we should have the larger conversation
of whether it is the right direction.  Perhaps we should have Larry
Masinter, the current expert for the media feature registry have a look
at the document?

			regards,
				Ted

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 27 Apr 2007 12:07:04 +0100

Ted Hardie wrote:

>name
I think this is reasonable.
The existing registry seems to be a close fit for what we are trying to do.

>(width & height becoming something like size-x and size-y).
>  
>
A side note: size-x and size-y are in inches, while width and height are 
supposed to be in pixels.

>the RFC 2506 global tree (e.g. g.oma.SOMETHING).
Yes, this would work too.

>may be a little difficult to express.
>
I would be interested in rationalizing these attributes once the base 
CONVERT is done.

>If this interoperability is desired,
Yes please!

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 27 Apr 2007 12:09:16 +0100

> The existing registry seems to be a close fit for what we are trying 

I would also note that the "charset" attribute used in the CONVERT 
document is already in the registry.

---

From: Ted Hardie <[email-masked]>
Date: Fri, 27 Apr 2007 10:41:48 -0700

At 12:07 PM +0100 4/27/07, Alexey Melnikov wrote:

>A side note: size-x and size-y are in inches, while width and height are supposed to be in pixels.

The current registry's first enties are for pix-x and pix-y, so that is not a problem.

>I would be interested in rationalizing these attributes once the base CONVERT is done.
>

Okay, I'll drop a note to Larry, asking him to review it.
			regards,
				Ted

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 29 Apr 2007 13:11:12 +0100

> Section 8:

 [...]

> "NO [TEMPFAIL]", or an additional TEMPFAIL extension response code 

I've changed the text to say "MUST return NO [TEMPFAIL]". I also rewrote 
the text to show more examples on when TEMPFAIL should be returned.

I think it would be better to rewrite the sentence to avoid SHOULD:

   Otherwise, the server returns an OK response.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 29 Apr 2007 14:28:45 +0100

>    the server MAY reply

The full sentence reads:
   Some transcodings may require parameters. If a transcoding request 
with no parameters is sent for a format which requires parameters, the 
server MAY reply with a NO response.

> Do we want to say what the other server choices are?  Use some default 
> values of its choosing?

I think the server MUST return the tagged NO response. (If the server 
can use a default value, this would mean that the parameter is not 
required.)
In order to allow the server to signal which parameters are expected, 
I've added a new MISSINGPARAMETERS response code.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 30 Apr 2007 11:26:56 +0100

> or we drop the feature.  More on this below.

I rather keep it as a MUST.

> client outweighs the benefit of the feature, I think.

Do you expect many clients will request the default conversion?

>>> to support very simple clients.  Thus, it doesn't make sense to make 
>>> this an option for servers, since the very clients that might need 
>>> it might also be too simple to have multiple code paths to handle it 
>>> not being available, and anyway, what is the client to do?  If we 
>>> are going to include default conversions, I think they should be 
>>> mandatory for servers.
>>
>> what the choices are, especially which choices are good. So as a 
>> server implementor I would need some guidance about implementing this 
>> feature.
>

You just confirmed my fear ;-). That was the reason why I initially made 
this feature optional.

> We could compromise and add some clearly non-normative text that makes 
> general suggestions.  For example, servers could keep a list of 
> to some guess as to how widespread client support is, or how difficult 
> rendering is, then the server can choose as a default conversion, 
> absent any information as to the client's specifics, the 
> highest-ranked non-identity subtype.  If the server has information as 
> to what the client supports, it can pick the highest-ranked supported 
> subtype, or the specific client support information can include a ranking.

I would like to have an informative paragraph about this. Can I ask you 
to write one (some rewording of the above will do)?

> mandatory or drop it entirely.

Ok.