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
_______________________________________________
lemonade mailing list
lemonade@...
https://www1.ietf.org/mailman/listinfo/lemonade
attachment0 (149 bytes) 
