Subject: RE: [lemonade] WGLC CONVERT

From: "[email-masked]" <[email-masked]>
Date: Tue, 8 Jan 2008 15:11:13 +0200

Hi all,
I have reviewed this draft several times earlier, so this time I have only a few, since most of my comments are editorial.

Great job Alexey, thank You!

Comments:

1. ToC: page numbers are missing (editorial).

2. 4.2, par 5: typo in "MUST use the lowercases version"

3. 4.2, par 10(?): word change suggestion 'option'->'optional' in "supports the following types of option parameters"

4. 4.2, par 11: "As with conversion types, some "wildcarding" is permitted." 'some "wildcarding' sounds quite vague - can we specify 'some' exactly (to avoid misinterpretations)?

5. 5., third last par.: typo in "The server ought to endeavour to preserver"

6. 5., third last par.: wording change suggestion.
Original:
"But in a case like this, where characters are split (legally!) between fragments of an encoded parameter what is the server to do?  A safe answer is to consolidate parameters that are in pieces, convert them and emit them fragmenting them again if necessary to keep the line length less than 78."
Proposal:
"In case the characters are split (legally!) between fragments of an encoded parameter, the server MUST consolidate the parameter fragments, and convert, emit and re-fragment them as necessary in order to keep the line length less than 78."

7. 5., third last par.: remove extra 'to' in "Comments embedded like this can be moved to after the parameter:"

8. 5. last sentence: wording change suggestion.
Original:
"It is important the encoded words be left as encoded words as to do otherwise may alter the semantics of structured headers."
Proposal:
"The encoded words MUST remain encoded, otherwise the semantics of structured headers might be inadvertently altered."

9. 6. par 1: typo in "minally" -> "minimally"

10. 6. par 2: wording change suggestion.
Original:
"Note, a server implementation is not required to implement any conversion from the text MIME subtypes specified above, except for the mandatory to implement conversion described in section 6.1."
Proposal:
Original:
"Note, a server implementation is not required to support any conversion from the text MIME subtypes specified above, except for the mandatory transcoding parameters described in section 6.1."

11. 6. par 3 and example under it. Should PIX-X, PIX-Y and IMAGE/JPG be lowercase? (See case sensitivity in Section 5).

12. 6.1 title: suggest change.
Original:
"Mandatory Transcoding support"
Proposal:
"Mandatory Transcoding parameters"

13. 6.1 par 4: does this belong here? This section is about mandatory things, not SHOULDs.

14. 6.2 title: suggest change.
Original:
"Additional features for mobile usage"
Proposal:
"Additional Transcoding parameters for mobile usage"

15. 7.3 par 2: wording change suggestion.
Original:
         Clients MUST NOT remember sizes of converterted messages/
         body parts across multiple IMAP "sessions". (This requirement
         allows an server implementation to upgrade its transcoding
         component without breaking interoperability.)
Proposal:
"In order to guarantee safe upgrade of server transcoding components, clients MUST NOT assume that repeating a particular bodypart conversion yields the same result as a previous conversion of the very same bodypart - any characteristics of a bodypart might be different (format, size, etc)."

16. 12.2 [MEMAIL] The draft has expired long ago - do we keep this? (referenced only once in Section 1.)

17. General
In section one, we read this: "Conversion (adaptation, 
   transcoding) may be requested by the client and performed by the 
   server on a best effort basis or, when requested by the client,
   decided by the server based on server's 
   knowledge of the client capabilities, user or administrator 
   preferences or server settings."
best effort -> clear
client capabilities -> not in the scope
administrator preferences -> not in the scope
server settings -> not in the scope
What about user preferences? I think that this is something that is in the scope since the user will store His/Her preferences on the server. Should this be described somehow?

Thank you.

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

>-----Original Message-----
>From: ext Eric Burger [mailto:[email-masked]] 
>Sent: 18 December, 2007 23:45
>To: [email-masked]
>Subject: [lemonade] WGLC CONVERT
>
>The work group last call for CONVERT ends 8 January 2008.  
>Please have at it.
>
>http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-13.txt
>
>
>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.
>
>
>_______________________________________________
>lemonade mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/lemonade
>Supplemental Web Site:
>http://www.standardstrack.com/ietf/lemonade
>

_______________________________________________
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: Wed, 16 Jan 2008 12:41:16 +0000

Eric Burger wrote:

>The work group last call for CONVERT ends 8 January 2008.  Please have at
>it.
>
The WGLC for the document has ended.

There were some editorial comments from Dan and Zoltan that needs to be 
addressed by Peter and myself.

And then there was a big discussion on discovery of available 
conversion. Several mechanisms were proposed, but so far I heard no 
consensus (please correct me if I am wrong). I will send a separate 
message suggesting some way to move forward on this.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 17 Jan 2008 22:21:01 +0000

>I have reviewed this draft several times earlier, so this time I have only a few, since most of my comments are editorial.
Hi Zoltan,
Thank you for the comments.

>Great job Alexey, thank You!
And Peter :-).

>1. ToC: page numbers are missing (editorial).
RFC-editor will add this during publication.

>2. 4.2, par 5: typo in "MUST use the lowercases version"
Fixed.

>3. 4.2, par 10(?): word change suggestion 'option'->'optional' in "supports the following types of option parameters"
Fixed.

>4. 4.2, par 11: "As with conversion types, some "wildcarding" is permitted." 'some "wildcarding' sounds quite vague - can we specify 'some' exactly (to avoid misinterpretations)?
I think the text is quite clear on this:

   As with conversion types, some "wildcarding" is permitted. Thus if
   the same parameters are allowed for all conversions to image/gif,
   then the server can store the one metadata value
   "/convert/@/@/image/gif/parameters".

The first sentence points to wildcarding (use of "@") earlier in the 
same section. The second sentence gives an example.

>5. 5., third last par.: typo in "The server ought to endeavour to preserver"
Fixed.

>"In case the characters are split (legally!) between fragments of an encoded parameter, the server MUST consolidate the parameter fragments, and convert, emit and re-fragment them as necessary in or…
Ok.

>7. 5., third last par.: remove extra 'to' in "Comments embedded like this can be moved to after the parameter:"
Fixed.

>"The encoded words MUST remain encoded, otherwise the semantics of structured headers might be inadvertently altered."
The original text is more like a SHOULD. Let me think if this text is Ok.

>9. 6. par 1: typo in "minally" -> "minimally"
Changed.

>"Note, a server implementation is not required to support any conversion from the text MIME subtypes specified above, except for the mandatory transcoding parameters described in section 6.1."
Ok.

>11. 6. par 3 and example under it. Should PIX-X, PIX-Y and IMAGE/JPG be lowercase?
>
Parameter names are case insensitive, so I've added the following sentence:
   Note, that according to [MEDIAFEAT-REG], transcoding parameter names
   are case-insensitive.

MIME types are also case-insensitive.

> (See case sensitivity in Section 5).
>
I am not sure which text in section 5 is relevant. Can you clarify?

>"Mandatory Transcoding parameters"
Changed.

>13. 6.1 par 4: does this belong here? This section is about mandatory things, not SHOULDs.
Formally you are correct, however I think this paragraph belongs to this 
section.
The section can be renamed "Mandatory Transcoding parameters and other 
requirements", but this is a bit too obscure.

>"Additional Transcoding parameters for mobile usage"
This section doesn't talk about any transcoding parameters, so I think 
this change is wrong.

>"In order to guarantee safe upgrade of server transcoding components, clients MUST NOT assume that repeating a particular bodypart conversion yields the same result as a previous conversion of the v…
The term "session" is defined in section 1.2 of RFC 3501 and has a 
special meaning (i.e. a sequence of command from mailbox opening and 
until its closure).
Your text is less restrictive. My text is saying that a converted 
message/body part size can be cached for a duration of a session, but 
not beyond that.

>16. 12.2 [MEMAIL] The draft has expired long ago - do we keep this? (referenced only once in Section 1.)
Right. Unless there are objections, I will remove this informative 
reference.

>server settings -> not in the scope
While administrator preferences and server settings might not be in 
scope, I think they are an important implementation detail. So I think 
it is fine to reference them in an introductory section.

>What about user preferences? I think that this is something that is in the scope since the user will store His/Her preferences on the server. Should this be described somehow?
User preferences are specified using conversion parameters. I've added a 
sentence saying that.

---

From: <[email-masked]>
Date: Fri, 18 Jan 2008 12:38:59 +0200

Hi Alexey,
thank you for the replies.
I added a little here and there.

>From: ext Alexey Melnikov [mailto:[email-masked]] 
>Sent: 18 January, 2008 00:21
>To: Ordogh Zoltan (Nokia-D-MSW/Tampere)
>Cc: [email-masked]
>Subject: Re: [lemonade] WGLC CONVERT
>

Yes, of course. I am sorry about missing Peter. Peter, thank You.

>>"It is important the encoded words be left as encoded words 
>as to do otherwise may alter the semantics of structured headers."
>>Proposal:
>>"The encoded words MUST remain encoded, otherwise the 
>semantics of structured headers might be inadvertently altered."
>>

I did not mean changing the requirement here. If you feel that it is necessary to allow exceptions, the SHOULD will be OK, too.

>I am not sure which text in section 5 is relevant. Can you clarify?

Sorry, I messed up - this is in section 4.2:
   Note that names of server annotations are case-sensitive (see
   [METADATA]). In order to guaranty interoperability, clients and
   servers MUST use the lowercases version of <type> and <subtype> when
   constructing an annotation name described above.

I just noticed a typo in the text above: garanty -> guarantee

>Formally you are correct, however I think this paragraph 
>belongs to this section.
>The section can be renamed "Mandatory Transcoding parameters 
>and other requirements", but this is a bit too obscure.

I agree. I withdraw this comment.

>This section doesn't talk about any transcoding parameters, so 
>I think this change is wrong.

I read this there:
[quote]
   - Image conversions among the types image/gif,
     image/jpeg and image/png for at least the following parameters:
        o Size limit (i.e. reduce quality),
        o width,
        o height,
        o resize directive (crop, stretch, aspect ratio)

     The support for "depth" may also be of interest.
[/quote]
I thought that this section would be extended later with additional parameters - if not, I agree that the current title is sufficient.

>>"In order to guarantee safe upgrade of server transcoding 
>components, clients MUST NOT assume that repeating a 
>particular bodypart conversion yields the same result as a 
>previous conversion of the very same bodypart - any 
>characteristics of a bodypart might be different (format, size, etc)."
>>  
>>
>The term "session" is defined in section 1.2 of RFC 3501 and 
>has a special meaning (i.e. a sequence of command from mailbox 
>opening and until its closure).
>Your text is less restrictive. My text is saying that a 
>converted message/body part size can be cached for a duration 
>of a session, but not beyond that.

Hmmm. I thought that my text was more restrictive for the clients (performing the same conversion within the same session might not yield the same result, neither). Why do we need to tie it to the session? That would imply that the transcoding component cannot be updated when there are open email sessions that have performaed transcoding earlier (e.g. almost never). Also, the transcoding requests can be relayed to a different server every time a request comes in, and one server might not yield the same result as the other.
Also, I think caching is not relevant here (if it is cached, it will surely remain the same).

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 18 Jan 2008 18:03:36 +0000

Hi Zoltan,

>I thought that this section would be extended later with additional parameters - if not, I agree that the current title is sufficient.
It is not going to be extended in this document.

>Hmmm. I thought that my text was more restrictive for the clients (performing the same conversion within the same session might not yield the same result, neither). Why do we need to tie it to the session?
>
As transcoding are expensive, I would like to allow servers to be able 
to cache results for the duration of a session.

>That would imply that the transcoding component cannot be updated when there are open email sessions that have performaed transcoding earlier (e.g. almost never).
>
If the transcoding component needs to be upgraded, the server can force 
connection closure. I don't think such event would be frequent enough, 
so I don't see a reason for optimizing for it.

>Also, the transcoding requests can be relayed to a different server every time a request comes in, and one server might not yield the same result as the other.
>  
>
True, but the server must be careful enough doing that, so that if a 
client asks for size or bodypartstructure of a convert body part first, 
then it would match the result returned to a subsequent request (in the 
same session) for the converted body part itself.

>Also, I think caching is not relevant here (if it is cached, it will surely remain the same).
My intent was to allow for caching.
The requirement was formulated for clients, so maybe it would be better 
to reformulate it as a requirement on servers?

---

From: <[email-masked]>
Date: Mon, 21 Jan 2008 11:43:52 +0200

Hi Alexei,
I added some comments below.

>Sent: 18 January, 2008 20:04
>>I thought that this section would be extended later with 
>additional parameters - if not, I agree that the current title 
>is sufficient.
>>  
>>

Ok, then please consider this comment closed.

>components, 
>>>>clients MUST NOT assume that repeating a particular bodypart 
>>>>conversion yields the same result as a previous conversion of the 
>>>>very same bodypart - any characteristics of a bodypart might be 
>>>>different (format, size, etc)."
>>>>      
>>>>
>>Hmmm. I thought that my text was more restrictive for the 
>clients (performing the same conversion within the same 
>session might not yield the same result, neither). Why do we 
>need to tie it to the session?
>>
>As transcoding are expensive, I would like to allow servers to 
>be able to cache results for the duration of a session.

Servers? I thought that this word of warning was for the clients.

>>That would imply that the transcoding component cannot be 
>updated when there are open email sessions that have 
>performaed transcoding earlier (e.g. almost never).
>>
>If the transcoding component needs to be upgraded, the server 
>can force connection closure. I don't think such event would 
>be frequent enough, so I don't see a reason for optimizing for it.

True, makes sense and I accept this. Sessions are not cached ever, right? (I try to recall quick reconnect here, if you remember.)

>>Also, the transcoding requests can be relayed to a different 
>server every time a request comes in, and one server might not 
>yield the same result as the other.
>>  
>>
>True, but the server must be careful enough doing that, so 
>that if a client asks for size or bodypartstructure of a 
>convert body part first, then it would match the result 
>returned to a subsequent request (in the same session) for the 
>converted body part itself.

Well, you are the server implementors - if you are sure that everyone will remember this without spelling this out explicitly in the specification, I am ok with this explanation.

>The requirement was formulated for clients, so maybe it would 
>be better to reformulate it as a requirement on servers?

Hehe, here we go - I was talking about the client perspective at all times (since the text talks about clients). I guess we have an agreement then, but from different points of view. I feel that the text for the clients is valid and necessary, so could we change that and add a similar text (yours + something from our comments above) for the servers?

Thank You.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 22 Jan 2008 21:52:08 +0000

Alexey Melnikov wrote:

>>> The requirement was formulated for clients, so maybe it would be 
>>> better to reformulate it as a requirement on servers?
>>
>> Hehe, here we go - I was talking about the client perspective at all 
>> times (since the text talks about clients). I guess we have an 
>> agreement then, but from different points of view. I feel that the 
>> text for the clients is valid and necessary, so could we change that 
>> and add a similar text (yours + something from our comments above) 
>> for the servers?
>
> Sounds good to me.

After reviewing the document I think content caching is addressed in 
sufficient details at the end of section 7.3.
I've extended the text I had, using some of the text you've suggested. 
Here is what I have now:

         In order to allow for upgrade of server transcoding
         components, clients MUST NOT assume that repeating a
         particular body part conversion in another IMAP "session"
         would yield the same result as a previous conversion of
         the very same bodypart - any characteristics of the converted
         body part might be different (format, size, etc). In
         particular clients MUST NOT cache sizes of converterted
         messages/body parts beyond duration of any IMAP "session",
         or use sizes obtained in one connection in another IMAP
         connection to the same server.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonaFrom [email-masked] Wed Jan 23 06:04:43 2008
Date: Tue, 22 Jan 2008 21:52:08 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: [lemonade] WGLC CONVERT
Cc: [email-masked]

Alexey Melnikov wrote:

>>> The requirement was formulated for clients, so maybe it would be 
>>> better to reformulate it as a requirement on servers?
>>
>> Hehe, here we go - I was talking about the client perspective at all 
>> times (since the text talks about clients). I guess we have an 
>> agreement then, but from different points of view. I feel that the 
>> text for the clients is valid and necessary, so could we change that 
>> and add a similar text (yours + something from our comments above) 
>> for the servers?
>
> Sounds good to me.

After reviewing the document I think content caching is addressed in 
sufficient details at the end of section 7.3.
I've extended the text I had, using some of the text you've suggested. 
Here is what I have now:

         In order to allow for upgrade of server transcoding
         components, clients MUST NOT assume that repeating a
         particular body part conversion in another IMAP "session"
         would yield the same result as a previous conversion of
         the very same bodypart - any characteristics of the converted
         body part might be different (format, size, etc). In
         particular clients MUST NOT cache sizes of converterted
         messages/body parts beyond duration of any IMAP "session",
         or use sizes obtained in one connection in another IMAP
         connection to the same server.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 22 Jan 2008 21:21:50 +0000

Hi Zoltan,

[email-masked] wrote:

>>>>>"In order to guarantee safe upgrade of server transcoding components,
>>>>>
>>>>message/body part size can be cached for a duration of a 
>>>>session, but not beyond that.
>>>>        
>>>>
The text is trying to cover both :-).

>>>That would imply that the transcoding comde
Supplemental Web Site:

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 22 Jan 2008 21:21:50 +0000

Hi Zoltan,

>True, makes sense and I accept this. Sessions are not cached ever, right? (I try to recall quick reconnect here, if you remember.)
We got rid of sessions in Quick Reconnect, so there is no issue here.

>Well, you are the server implementors - if you are sure that everyone will remember this without spelling this out explicitly in the specification, I am ok with this explanation.
Ok, I will try to clarify this in the document.

Sounds good to me.

ponent cannot be 
>True, makes sense and I accept this. Sessions are not cached ever, right? (I try to recall quick reconnect here, if you remember.)
We got rid of sessions in Quick Reconnect, so there is no issue here.

>Well, you are the server implementors - if you are sure that everyone will remember this without spelling this out explicitly in the specification, I am ok with this explanation.
Ok, I will try to clarify this in the document.

Sounds good to me.

---

From: <[email-masked]>
Date: Wed, 23 Jan 2008 14:30:00 +0200

Hi Alexey,
this text is good, thank You.

>Sent: 22 January, 2008 23:52
>After reviewing the document I think content caching is 
>addressed in sufficient details at the end of section 7.3.

---

From: Bill McQuillan <[email-masked]>
Date: Wed, 23 Jan 2008 10:28:32 -0800

Noticed a typo (^^^ below).

>>         particular clients MUST NOT cache sizes of converterted
                                                             ^^^

-- 
Bill McQuillan <[email-masked]>

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 Jan 2008 21:44:18 +0000

>Noticed a typo (^^^ below).
Fixed, thanks.