Last Call Review of draft-ietf-lemonade-profile-bis-
review-ietf-lemonade-profile-bis-secdir-lc-tschofenig-2009-03-13-00
Review
review-ietf-lemonade-profile-bis-secdir-lc-tschofenig-2009-03-13
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