RE: [lemonade] Profile Bis -03

On Tue Jun 27 11:35:42 2006, Zoltan.Ordogh@Nokia.com wrote:
> Thank You Dave for the update.
> Goog progress.
> Here are some comments/questions I came across while reading it:
> General: shouldn't the cover page say dated June, expires in 
> December?

Yes, I'd slightly messed up the boilerplate, which meant it was 
rejected.

The good news is that not only has that been put right, but it gave 
me the opportunity to address your comments in part. It's almost like 
I planned it all along.

> Abstract: "this version of the LEMONADE profile." Is "this version" 
> needed? It is going to supercede profile - should we say this 
> instead?

We can do.

> Introduction: "LEMONADE assumes that the LEMONADE profile can be 
> used..." Can we remove "LEMONADE assumes"?

"LEMONADE assumes" is referring to the WG, which cannot make claims 
about OMA MEM realization. I've changed it to "The LEMONADE working 
group believes", to make this distinction clearer.

> 3.4.1 "This command can be omitted, being for metadata only." 
> Suggest wording change to: "This command is only metadata, thus it 
> can be omitted."
> 3.4.2 "This command can be omitted." Suggest same wording as 
> previous: "This command is only metadata, thus it can be omitted."

I looked at what the RFC Editor did to the original ("This command 
can be omitted" in both), and I don't actually like it much, because 
it fails to explain why it can be omitted. I've tried out a new 
variant.

> 4.3 One question on this: should we mention that the size declared 
> is supposed to be "before compression, encyption, transfer 
> encoding, etc". Another question: if I do forward without download, 
> what size do I declare here? I might not have fetched the 
> attachment, so I might have no idea how big it is - does the "size 
> of the message after expansion of all BURL parts" statement take 
> care of this?

It should do, by reference to RFC1847. But I've attempted to clarify 
this a little.

In general, clients do know the size of an attachment in its encoded 
form without downloading, from the BODYSTRUCTURE. In the case of 
forwarding a non-leaf part (say, a multipart/related or 
multipart/alternative) by reference, though, the client almost 
certainly wouldn't know. If it assembled the message via CATENATE, 
though, it would know the complete message size (by FETCHing 
RFC822.SIZE in a command pipelined with the GENURLAUTH, so there's no 
additional round-trip there).

> 5.6 I-D.melnikov-imap-search-ret is an expired draft.

That's updated. However, I missed changing the reference for 
compression from gulbrandsen-imap-deflate to ietf-lemonade-compress - 
I couldn't do this before, as the referencing library would have 
generated incorrect authorship for it, but I could have done when 
redoing the boilerplate.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade