Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-02.txt

From: <[email-masked]>
Date: Wed, 7 Jun 2006 15:01:31 +0300

Hi all,
A few questions/comments:
 - Section 4.3, first paragraph. I saw some emails about including/not including Compression in CONVERT. What was the conclusion on this? Does the current bis reflect that agreement? OMA STI does not include parameters for compressing files.
 - Section 4.3, last paragraph. So, there will be a COMPRESS anyway?
 - Section 4.3 general. This section is confusing. Would it be possible to describe things from the compression level point of view saying this is low-level, that is application-level, and that is object-level compression. This is believed to be better for this, that is believed to be better for that. For low-level use this and that, for application-level use this and that, and for object-level use this and that. This is mandatory, while that is optional for the server. Clients to evaluate which is available and best used according to their capabilities and the current network conditions.
 - Section 4.5. Normative statement missing - is it a MUST, SHOULD or MAY?
 - "required by [RFC3501]. As noted above, servers SHOULD support" that note is quite far above - could we say "Section 4.3"?
 - Section 5: "STARTTLS | Required by IMAP [RFC3501]" Are we going to describe all dependencies? If not, remove, if yes, add all please.
 - Section 5: "LPROVISION, LSETPREF, LGETPREF | Section 4.4" these are not described in section 4.4.
 - Section 13, 1st bullet: double dot at the end of the paragraph.
 - Section 13, 3nd bullet: "Notifications (server to client)" -> "Server to client notifications", but: why the separation if they are discussed in the same draft anyway?

Thank You for the update, good stuff.

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

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: 31 May, 2006 01:50
To: [email-masked]
Cc: [email-masked]
Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-02.txt 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF.

	Title		: LEMONADE profile bis
	Author(s)	: S. Maes, et al.
	Filename	: draft-ietf-lemonade-profile-bis-02.txt
	Pages		: 55
	Date		: 2006-5-30
	
This document describes LEMONADE profile bis.  It contains pointers or mention to all the features that are normatively part of LEMONADE profile bis.

This document describes a profile (a set of required extensions, restrictions and usage modes) of the IMAP and mail submission protocols.  This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail.
This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission and to efficiently resynchronize in case of loss of connectivity with the server.

The Lemonade profile relies upon extensions to IMAP and Mail Submission protocols; specifically URLAUTH and CATENATE IMAP protocol
([RFC3501]) extensions and BURL extension to the SUBMIT protocol (SUBMIT).

It provides also extensions to provide support for realizations of OMA mobile email enabler (MEM) ([MEM-req] and [MEM-arch]) using Internet Mail protocols defined by the IETF.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-bis-02.txt

To remove yourself from the I-D Announcement list, send a message to [email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then
	"get draft-ietf-lemonade-profile-bis-02.txt".

A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-lemonade-profile-bis-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Randall Gellens <[email-masked]>
Date: Mon, 12 Jun 2006 17:34:49 -0700

In Section 1:
    It is based on LEMONADE profile [profile].

    This document describes the lemonade profile-bis that includes:

I don't think we should use the term "bis" anywhere in the document 
(just the title), since this document is an update to the previous 
profile document and hence replaces it.  Likewise, I wouldn't say "It 
is based on LEMONADE profile [profile]" but perhaps "is an update of" 
or something like that.  Similarly, the text (which is later in the 
same section) "are summarized in the LEMONADE profile [profile]" is 
confusing because this document is the lemonade profile.

I suggest deleting the text (later in this same section):
    and mechanisms of the OMA MEM
    Architecture [MEM-arch], following the LEMONADE point of view
    described in the  OMA MEM realization internet draft
    [OMAMEMrealization].

I think it might be confusing to readers who aren't looking to 
implement OMA MEM, but just want to support email or mobile email.  I 
don't think this text is needed.  The earlier part of the sentence 
makes it clear that this supports OMA MEM.  The reference to the OMA 
MEM realization Internet Draft would be a problem if that draft is 
not published as an RFC.

Likewise, the following text should be either deleted or moved to a 
new section to be called something like "Notes on Supporting OMA 
MEM", making clear that the section is to aid the working 
relationship between lemonade and OMA MEM, and is to be deleted by 
the RFC Editor prior to publication:
    Also, it is to be noted that this document solely describes
    normatively the LEMONADE profile bis.  It discusses LEMONADE
    understanding of the work in progress at OMA MEM ([MEM-req] and [MEM-
    arch] but does not provide a normative reading of these documents.
    Readers MUST refer to the Open Mobile Alliance web site for normative
    references on the Mobile Email Enabler (OMA MEM).  LEMONADE assumes
    that the LEMONADE profile bis can be used as basis for an OMA
    technical specification of a realization based on LEMONADE of the OMA
    MEM enabler.

Section 3: Should BURL be here as well as in Section 2?  At least a 
short mention with reference to Section 2?

In Section 3.3, I don't like the quotes around 'expand' in 'MUST 
"expand" all BURL'.  I'd suggest either removing them, or change 
'expand' to 'dereference'.  Although, in thinking about it, the 
wording could be taken the wrong way.  If the size of a message 
already exceeds a limit and there are still BURL parts not yet 
expanded, there is no need for the server to expand them.  Perhaps 
something along the lines of "When including a message size in the 
MAIL FROM command, clients MUST use a value that is at least as large 
as the size of the message after expansion of all BURL parts. 
Servers MUST NOT consider a message's size to be acceptable if it has 
not expanded all BURL parts."

Section 4.3: I think we agreed to go with the alternate paragraph 
that says "MUST provide [COMPRESS] support".

Sections 6-9 should, I think, be moved to the new section I propose 
above ("Notes on Supporting OMA MEM").  I don't want to confuse 
non-OMA readers.

In Section 9, the text "additional security measures like object 
level encryption" is asking for trouble (I was going to say "raw meat 
for the Security folks" but some of them may be vegetarian).  Perhaps 
it should be changed to "significant additional security 
considerations" (although that too is really hand-waving).

I like Section 10, but Sections 11-13 are difficult because they are 
so intertwined with OMA references and considerations.  I'm all for 
making it clear how our model and protocols fit into OMA MEM, but I 
also want to produce a stand-alone profile document that makes sense 
to non-OMA people.  I had been assuming that this document served 
that purpose.

In Section 14.3, "traverse firewalls" should be "deceive firewalls" 
since firewalls can be traversed with no additional security 
considerations.  That's the job of the firewall.  It's only when you 
try to fool the firewall in order to subvert its configured policy 
that you get into the additional issues.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Once I make up my mind, I'm full of indecision.
                                --Oscar Levant

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 20 Jun 2006 15:12:22 +0100

Randall Gellens wrote:

> or something like that.

Done.

>   Similarly, the text (which is later in the same section) "are 
> summarized in the LEMONADE profile [profile]" is confusing because 
> this document is the lemonade profile.

I deleted this sentence, as I didn't think it provided any extra 
information.

>    described in the  OMA MEM realization internet draft

Deleted. I've moved the reference to [MEM-arch] to the previous paragraph.

> MEM realization Internet Draft would be a problem if that draft is not 
> published as an RFC.

Right, unless the reference is informative.

> new section to be called something like "Notes on Supporting OMA MEM", 
> making clear that the section is to aid the working relationship 
> between lemonade and OMA MEM, and is to be deleted by the RFC Editor 
> prior to publication:

I tend to agree with your comments that all OMA related topics should be 
grouped under a new top level section. If my co-editors agree with this, 
I will discuss with them the best way to do that

> short mention with reference to Section 2?

I thought the section 5 defines the full list of IMAP and Submit 
extensions. Do you think that the section 3 also needs a pointer to BURL?

> 'expand' to 'dereference'

RFC 4468 uses the term "resolve", so I updated the Profile document to 
use the same term.

> .  Although, in thinking about it, the wording could be taken the 
> wrong way.  If the size of a message already exceeds a limit and there 
> are still BURL parts not yet expanded, there is no need for the server 
> to expand them.

Correct. So the server can reject the last BURL chunk that caused the 
message to exceed server's limit.
This is exactly the logic I've implemented in Isode Message Switch.

> Perhaps something along the lines of "When including a message size in 
> the MAIL FROM command, clients MUST use a value that is at least as 
> large as the size of the message after expansion of all BURL parts.

Good point. I've included this sentence.

> not expanded all BURL parts."

I guess this is true, but I think the Profile document should provide 
more details:
1). If the client has specified SIZE MAIL FROM parameter and it is 
bigger than the maximum allowed by the server for the user, then the 
server MUST reject the message right away.
2). The server SHOULD verify "accumulated size" of the message after 
processing each BURL/BDAT chunk, but MAY do this after receiving all of 
them.

> Section 4.3: I think we agreed to go with the alternate paragraph that 
> says "MUST provide [COMPRESS] support".

Done.

I will think about the rest of your comments:

> In Section 9, the text " additional security measures like object 
> to non-OMA people.  I had been assuming that this document served that 
> purpose.
>

---

From: Randall Gellens <[email-masked]>
Date: Wed, 21 Jun 2006 11:57:46 -0700

>> implement OMA MEM, but just want to support email or mobile email. 
>> I don't think this text is needed.  The earlier part of the 
>> sentence makes it clear that this supports OMA MEM.  The reference 
>> to the OMA MEM realization Internet Draft would be a problem if 
>> that draft is not published as an RFC.
>

Even then it is unfortunate, I think, because people reading the 
profile-bis RFC will see a reference to an expired draft.

>>  Section 3: Should BURL be here as well as in Section 2?  At least 
>> a short mention with reference to Section 2?
>

Just for clarity, I think.

>> wrong way.  If the size of a message already exceeds a limit and 
>> there are still BURL parts not yet expanded, there is no need for 
>> the server to expand them.
>
>  Correct. So the server can reject the last BURL chunk that caused 
> the message to exceed server's limit.
>>  Perhaps something along the lines of "When including a message 
>> size in the MAIL FROM command, clients MUST use a value that is at 
>> least as large as the size of the message after expansion of all 
>> BURL parts.
>
>>  Servers MUST NOT consider a message's size to be acceptable if it 
>> has not expanded all BURL parts."
>
>  I guess this is true, but I think the Profile document should 
> provide more details:
> bigger than the maximum allowed by the server for the user, then 
> the server MUST reject the message right away.

Yes, it would be bad for servers to reject a message after submission 
when it could have been rejected at MAIL FROM.

>  2). The server SHOULD verify "accumulated size" of the message 
> after processing each BURL/BDAT chunk, but MAY do this after 
> receiving all of them.

I agree.

-------------- Randomly-selected tag: ---------------
When a man's best friend is his dog, that dog has a problem.
                                             --Edward Abbey

---

From: Dave Cridland <[email-masked]>
Date: Fri, 23 Jun 2006 00:30:48 +0100

On Wed Jun  7 13:01:31 2006, [email-masked] wrote:
>  - Section 4.3, first paragraph. I saw some emails about 
> including/not including Compression in CONVERT. What was the 
> conclusion on this? Does the current bis reflect that agreement? 
> OMA STI does not include parameters for compressing files.
>  - Section 4.3 general. This section is confusing. Would it be 
> possible to describe things from the compression level point of 
> view saying this is low-level, that is application-level, and that 
> is object-level compression. This is believed to be better for 
> this, that is believed to be better for that. For low-level use 
> this and that, for application-level use this and that, and for 
> object-level use this and that. This is mandatory, while that is 
> optional for the server. Clients to evaluate which is available and 
> best used according to their capabilities and the current network 
> conditions.

Alexey has tidied this up, removing the inapplicable paragraphs.

>  - Section 4.5. Normative statement missing - is it a MUST, SHOULD 

It's a MUST, but expressed as a statement of fact for variety. (Note 
that CATENATE is even more extreme, dispensing with RFC2119 entirely).

>  - "required by [RFC3501]. As noted above, servers SHOULD support" 
> that note is quite far above - could we say "Section 4.3"?

Done.

>  - Section 5: "STARTTLS | Required by IMAP [RFC3501]" Are we going 
> to describe all dependencies? If not, remove, if yes, add all 
> please.

STARTTLS was historically not part of IMAP4rev1, it was mandated and 
included into RFC3501. Originally, though it was distinct, defined in 
RFC2595, and as such, I think it's a special case.

> are not described in section 4.4.

They're part of the notifications draft.

>  - Section 13, 3nd bullet: "Notifications (server to client)" -> 
> "Server to client notifications", but: why the separation if they 
> are discussed in the same draft anyway?

Section 13 is intentionally somewhat rough notes, it will vanish. 
(It's actually section 7.7, now).

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

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 23 Jun 2006 16:01:58 +0100

Dave Cridland wrote:

>> conclusion on this? Does the current bis reflect that agreement? OMA 
>> STI does not include parameters for compressing files.
>> possible to describe things from the compression level point of view 
>> saying this is low-level, that is application-level, and that is 
>> object-level compression. This is believed to be better for this, 
>> that is believed to be better for that. For low-level use this and 
>> that, for application-level use this and that, and for object-level 
>> use this and that. This is mandatory, while that is optional for the 
>> server. Clients to evaluate which is available and best used 
>> according to their capabilities and the current network conditions.
>
>>  - Section 5: "STARTTLS | Required by IMAP [RFC3501]" Are we going to 
>> describe all dependencies? If not, remove, if yes, add all please.
>

I agree.

> They're part of the notifications draft.

Actually, I removed them, as we are going to use METADATA instead.

>>  - Section 13, 1st bullet: double dot at the end of the paragraph.
Fixed.

>> "Server to client notifications",
>
Changed.

>> but: why the separation if they are discussed in the same draft anyway?
>

---

From: <[email-masked]>
Date: Mon, 26 Jun 2006 09:45:52 +0300

Hi Dave,

>They're part of the notifications draft.

Should we then update the reference from Section 4.4. to the
Notificiations draft?
Thank You.