Subject: [lemonade] Profile Bis -03

From: Dave Cridland <[email-masked]>
Date: Mon, 26 Jun 2006 23:12:33 +0100

Hiya folks,

I submitted the attached version of draft-ietf-lemonade-profile-bis 
this morning, UK time, hence before the deadline, as version -03.

I'm guessing there'll be a slight delay before it's seen in the I-D 
repository, so here is an advance copy. Have fun, and see if you can 
find the deliberate errors.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: <[email-masked]>
Date: Tue, 27 Jun 2006 13:35:42 +0300

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?
Abstract: "this version of the LEMONADE profile." Is "this version" needed? It is going to supercede profile - should we say this instead?
Introduction: "LEMONADE assumes that the LEMONADE profile can be used..." Can we remove "LEMONADE assumes"?
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."
3.7 Looks a lot better now, thanks.
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?
4.4 "Server to client notifications as discussed in [I-D.ietf-lemonade-notifications].  Server to server notifications discussed in [I-D.ietf-lemonade-notifications] describes how NF interacts with the notifications mechanisms." The two references are the same - why not collapse these two into a single sentence without making a difference between client-server and server-server notifications at this point?
5.6 I-D.melnikov-imap-search-ret is an expired draft.
11.2.2. The discussion on this section did not happen yet (commented in earlier mail).

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

-----Original Message-----
From: ext Dave Cridland [mailto:[email-masked]] 
Sent: 27 June, 2006 01:13
To: Enhancements to Internet email to support diverse service enivronments
Subject: [lemonade] Profile Bis -03

Hiya folks,

I submitted the attached version of draft-ietf-lemonade-profile-bis this morning, UK time, hence before the deadline, as version -03.

I'm guessing there'll be a slight delay before it's seen in the I-D repository, so here is an advance copy. Have fun, and see if you can find the deliberate errors.

Dave.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 28 Jun 2006 13:34:18 +0100

>3.4.2 "This command can be omitted." Suggest same wording as previous: "This command is only metadata, thus it can be omitted."
RFC editor didn't like this sentence either.
[...]

>4.3 One question on this: should we mention that the size declared is supposed to be "before compression, encyption, transfer encoding, etc".
>
The ESMTP size is always the size of the fully constructed message. If a 
message part is using content transfer encoding, the encoded size is 
counted.
If you are asking about COMPRES= and STARTTLS, then no, the message size 
is the size of the message before any lower level transformations are done.

> 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?
>  
>
Yes. The section basically says that if a client wants to specify SIZE 
parameter, it must count all BURL parts as if there were expanded.
However this is just a SHOULD requirement, if the client doesn't know 
the final size, or if it is difficult to compute, then it should not 
specify the SIZE parameter at all.

[...]

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

---

From: Dave Cridland <[email-masked]>
Date: Thu, 29 Jun 2006 22:33:38 +0100

> General: shouldn't the cover page say dated June, expires in 

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.