Subject: [secdir] SECDIR review of draft-ietf-lemonade-profile-bis-12.txt

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 11 Mar 2009 09:57:33 +0200

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This document defines a profile of IMAP, mail submission and Sieve protocol
for usage of performance constraints devices.

This document does not define new security mechanisms (or other extensions).
It points to the security related aspects associated with the profiled
version (e.g., the pawn ticket -- a fancy name for a simple concept). This
is a good document. 

Only a few minor editor comments and a question regarding the IANA
consideration section: 

The RFC Editor always edits my documents to have a capitalized subject
headers. 
E.g.: 
 s/Summary of the required support/Summary of the Required Support
 s/Message size declaration/Message Size Declaration

s/Lemonade Submission Servers MUST provide a service as described in
   [SUBMIT], and MUST support the following./ Lemonade Submission Servers
MUST provide a service as described in
   [SUBMIT], and MUST support the following extensions. 
 
s/Lemonade Message Stores MUST provide a service as described in
   [IMAP], and MUST support the following./Lemonade Message Stores MUST
provide a service as described in
   [IMAP], and MUST support the following extensions.

s/(See [SMTP-BURL] for more details)./(see [SMTP-BURL] for more details).

s/Therefore /Therefore,

s/Server-to-client notifications transforms/server-to-client notifications
transforms 

s/the Notification filter generates/the notification filter generates 

First occurance of OMA write Open Mobile Alliance (OMA)

"When clients submit new messages, link protection such as [TLS] guards
against an eavesdropper seeing the contents of the submitted message."

Maybe use "confidentially protection, such as TLS [TLS]," instead of link
protection

The IANA consideration section says "This document defines the URL-PARTIAL
IMAP capability Section 5.7.1. IANA is
   requested to add this extension to the IANA IMAP Capability registry.". 

Section 5.7.1 only references another specification where this capability is
defined, at least that's my reading. This document only defines a profile
and does not require any IANA considerations. 

Here is what Section 5.7.1 says:

"
5.7.1.  Support for PARTIAL in CATENATE and URLAUTH

   [IMAP-URL] introduced a new syntactic element for referencing a byte
   range of a message/body part.  This is done using the ;PARTIAL=
   field.  If an IMAP server supports PARTIAL in IMAP URL used in
   CATENATE and URLAUTH extensions, then it MUST advertise the URL-
   PARTIAL capability in the CAPABILITY response/response code.
"

Ciao
Hannes

---

From: Dave Cridland <[email-masked]>
Date: Wed, 11 Mar 2009 10:02:24 +0000

> like any other last call comments.
Thanks for the very thorough review. I think the vast majority of  
your comments we'll accept without question.

>    PARTIAL capability in the CAPABILITY response/response code.
[IMAP-URL] defines how to construct a URL which references a  
byte-range within a body part, and this is newer than CATENATE or  
URLAUTH. In particular, IMAP-URL only defines syntax, not protocol,  
and doesn't define where the various URL forms can be used at all.

CATENATE and URLAUTH are both defined with the assumption that they  
only handle URLs without this newer parameter, so the Profile  
document defines a new capability to signal that CATENATE and URLAUTH  
can be used with byte-range URLs as well as whole-part URLs.

So yes, the profile does need to define a new capability not defined  
within any of the referenced specifications.

I'll have a think about how this can be made clearer - if you've  
suggestions, they'd be most welcome.

Dave.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 11 Mar 2009 16:47:27 +0200

Hi Dave, 

Thanks for your quick response. 

>suggestions, they'd be most welcome.

Ok. Now I believe I understood this better. 

[IMAP-URL] defines a URL scheme for referencing objects on an IMAP server.
It does not define how you actually use the URL in order to get the
referenced objects. In any case, the ABNF for the URL is defined in that
document and it contains tokens that refer to specifications that are used
in the IMAP context, for example URLAUTH specified in RFC 4467. As such,
they define the semantic for these tokens. 

So, now you would like to use the token PARTIAL with the IMAP-URL. There
isn't really a separate registry of parameters for usage with the IMAP-URL,
as far as I can tell from my quick read. Section 11 of RFC 5092 only says
"Elements not defined here can be found in [ABNF], [IMAP4], [IMAPABNF], or
[URI-GEN]." Hence, this seems to mean that the tokens have to be registered
in http://www.iana.org/assignments/imap4-capabilities in order to be usable
for the IMAP-URL. 

Hence, you have to register the URL-PARTIAL token in
http://www.iana.org/assignments/imap4-capabilities in order to get this to
work. 

Is this roughly a correct summary? 

What section in
http://tools.ietf.org/html/draft-ietf-lemonade-profile-bis-12 describes the
semantic of the URL-PARTIAL token? You refer to Section 5.7.1 in the IANA
consideration section but that section doesn't really say anything in that
regard. 

Btw, maybe you should replace
"5.7.1. Support for PARTIAL in CATENATE and URLAUTH"
with 
"5.7.1. Support for URL-PARTIAL in CATENATE and URLAUTH"

Ciao
Hannes

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 11 Mar 2009 16:05:38 +0000

>Hi Dave,
Hi Hannes,

>referenced objects.
Correct.

>In any case, the ABNF for the URL is defined in that
Right.

>as far as I can tell from my quick read.
>
Correct.

>Section 11 of RFC 5092 only says
New tokens have to be registered, yes.
What actually happened was that RFC 4469 and RFC 4467 references the old 
IMAP URL RFC (RFC 2192). When the updated IMAP URL (RFC 5092) spec was 
finished, it contained an extra syntactic element - PARTIAL. However in 
order for an IMAP client to know if such token can be used with a 
particular CATENATE/URLAUTH capable servers, a new IMAP capability key 
needs to be advertised by the server.

>Is this roughly a correct summary? 
More or less.

>consideration section but that section doesn't really say anything in that
I am not sure what is your concern here. Section 5.7.1 currently says:

>"5.7.1. Support for URL-PARTIAL in CATENATE and URLAUTH"
The latter is slightly more confusing, IMHO, as one IMAP extension isn't 
typically included in another.
Maybe replace "PARTIAL" with ";PARTIAL=" IMAP URL element"?