Spencer Dawkins wrote:
Hi, Alexey,
Hi Spencer,
Gen-ART reviewers ADORE editors who respond quickly, because there's a
chance the Gen-ART reviewer can remember what the review was trying to
say! Thanks for quick feedback.
I'm fine with most of the resolutions you proposed, so I'm dropping
everything that I agree with (except that a couple of your resolutions
are so much better than my proposed text that I wanted to say that
explicitly :-).
I have a couple of notes below. This review was done as input to Last
Call, so please handle as you would handle any other Last Call
comments (talk to your document shepherd).
Thanks,
Spencer
From: "Alexey Melnikov" <[EMAIL PROTECTED]>
Spencer Dawkins wrote:
Document: draft-ietf-lemonade-rfc2192bis-08
Reviewer: Spencer Dawkins
Review Date: 2007-08-02
IETF LC End Date: 2007-06-28 (yes, this review is late).
IESG Telechat date: 2007-08-23
Abstract
This document obsoletes RFC 2192. It also updates RFC 4467.
Together with update to RFC 4467 they will obsolete RFC 4467.
Spencer: Pronoun problem here - what is "they"? I'm reading this as
(1) this document obsoletes RFC 2192, (2) this document also updates
RFC 4467, but (3) there is ALSO another update to 4467 (let's call
it 4467bis), and (4) 2192bis and 4467bis, taken together, will
obsolete 4467.
Correct. I've changed "they" to "it".
If that's not what the text actually means, I can't understand this
paragraph well enough to suggest text.
I guess what I'm trying to undestand is (a) will this document and
the apparent 4467bis be advanced together?
No, 4467bis is not written yet ;-)
so that on one fine day, 2192bis and 4467bis are published as RFCs,
and 4467 is marked as obsoleted, or (b) are you expecting that 4467
will be marked as updated by 2192bis OR by 4467bis until both are
published as RFCs, and then 4467 will be marked as obsoleted
Yes, obsoleted by both.
(by both? by either? mumble)?
I am thinking that it might be better to remove the sentence
"Together with update to RFC 4467 they will obsolete RFC 4467", as it
is trying to put a requirement on a future document (4467bis).
Agree with this resolution (since the lemonade/imap community might
change plans before the future document is written, or may simply not
write the second document, the RFC Editor will be a lot happier with
your proposed resolution, I bet).
Ok, done.
1. Conventions used in this document
Note that the syntax shown in sections 2-6 is informal. The
authoritative formal syntax for IMAP URLs is defined in section 11.
If there are any differences between syntax shown in sections 2-6
and section 11, then the syntax shown in section 11 must be treated
as authoritative.
Spencer: Please help me here. This text says that SYNTAX in sections
2-6 is informal (which I'm probably misinterpreting as
"informative", but these sections also contain 2119 language, which
in a Proposed Standard would be normative.
You might be reading too much into my text ;-)
This paragraph is trying to say:
1). Sections 2-6 might not be using ABNF
2). In case there are any differences (or errors) between syntax in
sections 2-6 and section 11, then section 11 contains the correct
syntax.
How about changing:
Note that the syntax shown in sections 2-6 is informal. The
authoritative formal syntax for IMAP URLs is defined in section 11.
to:
Note that the syntax shown in sections 2-6 is informal, the
authoritative formal syntax for IMAP URLs is defined in section 11.
?
Can we do this? (and should we do this?) Is it worth saying "2119
requirements in sections 2-6 are, of course, normative" in this
section?
I guess this can be added, but I thought it was obvious.
Obvious is relative, of course... :-) Based on our exchange, I'm
suggesting "Note that the ABNF syntax shown in section 11 is
normative. Examples in sections 2-6 may use a less formal syntax that
does not match the normative ABNF shown in section 11, if the result
helps the reader to understand the point being made in an example.
Non-syntax requirements included in sections 2-6 are, of course,
normative."
Combining your proposal with my existing text I now have:
Note that the ABNF syntax shown in section 11 is normative.
Sections 2-6 may use a less formal syntax that does not necessarily match
the normative ABNF shown in section 11. If there are any differences between
syntax shown in sections 2-6 and section 11, then the syntax shown in
the Section
11 must be treated as authoritative.
Non-syntax requirements included in sections 2-6 are, of course, normative.
(I avoided talking about examples, as they don't use ABNF.)
[...]
3.3. Limitations of enc-user
An obvious limitation of using the same field for both purposes is
that the URL can be resolved only by the mailbox owner. In order
to avoid this restrictions, implementations should use globally
unique mailbox names (see Section 3.1) whenever possible (*).
(*) There is currently no general way in IMAP of learning a glob-
ally unique name for a mailbox. However by looking at the NAMESPACE
[NAMESPACE] command result it is possible to determine if a mailbox
name is globally unique or not.
Spencer (nit): I'm not used to seeing "footnotes" in Internet Drafrs...
I think it is clearer this way.
Well, yeah, I agree. My point is that
ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt
says
(8) Footnotes
Do not use footnotes. If such notes are necessary, put them
at the end of a section, or at the end of the document.
So my suggestion is to discuss this with the RFC Editor now ("and not
during AUTH-48, which might be the first time you realize that the RFC
Editor has proposed changed text"), and figure out what is clearer AND
consistent with about 5000 previously-proposed RFCs ;-)
Ok.
I had footnotes in one or two other recently published RFCs. The
responsible RFC editor always did the right thing :-).
5. Lists of messages
they MUST be percent-encoded as described in [URI-GEN].
The "?<enc-search>" field is optional. If it is not present, the
entire content of the mailbox SHOULD be presented by the program
interpreting the URL. If it is present, it SHOULD be used as the
arguments following an IMAP4 SEARCH command with unsafe characters
such as " " (which are likely to be present in the <enc-search>)
percent-encoded as described in [URI-GEN]. Note that quoted
Spencer: If these SHOULDs are in the previous version of this
document with no explanation, that's OK, but if there are
well-understood and agreed reasons for NOT doing what the SHOULDs
require, it would be nice to point them out here.
The client may instead open the mailbox, download all messages and
perform the search itself. Thus the SHOULD.
Ah. This isn't a 2119 SHOULD. If I understand correctly, the intention
is to say
The "?<enc-search>" field is optional. If it is not present, the
program interpreting the URL will present the entire content of the
mailbox.
If the "?<enc-search>" field is present, the program interpreting the
URL should use the contents of this field as arguments following an
IMAP4 SEARCH command. These arguments are likely to contain unsafe
characters such as " ". If unsafe characters are present, they
MUST be
percent-encoded as described in [URI-GEN].
Is this what the text is intended to say?
This reads better, thanks!
I am not sure I want to go into such level of details in the document
;-). Besides the list of things that clients SHOULD NOT do might be a
bit long.
I understand completely...
(There are quite a few SHOULDs without listed exceptions, so please
consider this a fairly general comment).
So, based on the previous point, I'm thinking the review comment
should be "please make sure that your SHOULDs really are 2119 SHOULDs:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
and, to be specific, a SHOULD would be a MUST in most circumstances.
6.1.1.2. Mailbox Access Key
The mailbox access key is a random string with at least 128 bits of
entropy. It is generated by software (not by the human user), and
MUST be unpredictable.
Spencer: is "MUST be unpredictable" sufficiently defined? And I'm
not sure this is a 2119 MUST - it would be a bad idea to generate
keys by adding one to the previous key,
It is a MUST on server implementations due to a security consideration.
Ah, perfect. Then the text could be something like
Servers MUST generate the mailbox access key cryptographically,
with at least 128 bits of entropy.
I think "cryptographically" is not important. A monkey that can produce
128 bits of entropy by throwing bananas will work too :-).
I think the important part is "unpredictable".
Either way, neither "cryptographically" nor "unpredictable" is
externally observable.
Are you Ok with leaving these 2 sentences as is? (They are exactly the
same as in RFC 4467.)
Is this what the text is intended to say?
6.1.2. URLAUTH extensions to IMAP URL
The "authuser" <access> identifier indicates that use of this URL
is limited to IMAP sessions which are logged in as an authorized
user (that is, have authorization identity as an authorized user)
of that IMAP server. Use of this URL is prohibited to anonymous
IMAP sessions.
Spencer (nit): this paragraph reads oddly, since it says "is limited
to authorized user" AND "is prohibited to anonymous users". I would
have expected one or the other (since the two categories are
mutually exclusive and collectively exhaustive, aren't they?)
Yes, but one can misunderstand AUTHENTICATE ANONYMOUS sessions as
sessions logged in as an authorized user. So the second sentence
clarifies that this is not the case.
Probably so, for people who know more about IMAP4 than I do. If people
like me will be reading this specification, perhaps your clarifying
text should be included in the draft? Something like
The "authuser" <access> identifier indicates that use of this URL
is limited to IMAP sessions which are logged in as an authorized
user of that IMAP server, not as AUTHORIZED ANONYMOUS. Use of this
URL is prohibited to anonymous IMAP sessions.
After thinking more about this I think it would be better to say
"non-anonymous" instead of "authorized":
The "authuser" <access> identifier indicates that use of this URL
is limited to authenticated IMAP sessions which are logged in as any
non-anonymous user (that is, have authorization identity as a non-anonymous
user user) of that IMAP server. To restate this: use of this type of
URL is prohibited to anonymous IMAP sessions, i.e. any URLFETCH command
containing this type of URL issued in an anonymous session MUST return NIL
in the URLFETCH response.
Just curious - is it obvious what the IMAP4 server does when an
AUTHORIZED ANONYMOUS client provides this URL?
Servers should fail to return any data for such URLs.
I've added ", i.e. any URLFETCH command ..." to make this clear.
A pointer to an IMAP4 specification would be nice, if you're hoping
for consistent server behavior...
7.2. relative-path References
A relative reference that does not begin with a slash character is
termed a relative-path reference [URI-GEN]. Implementations SHOULD
NOT generate or accept relative-path IMAP references.
Spencer: it might be nice to say why this deprecated concept is
important - perhaps ", but relative-path IMAP references are still
in use in older IMAP implementations" or something similar?
Actually I am not sure that relative-path IMAP references are used
much, they were found to be quite problematic during the Lemonade
interop last year.
The text is here because URI-GEN allows for relative-path references.
Ah. I thought all the unintended consequences from protocol reuse were
in the RAI area :-) Perhaps this could be stated more clearly?
Something like
A relative reference that does not begin with a slash character is
termed a relative-path reference [URI-GEN]. Although [URI-GEN] allows
relative-path IMAP references, they were found to be problematic
during 2006
interoperability testing. Clients conforming to this specification
MUST NOT generate relative-path IMAP4 references. Servers
conforming to this
specification MUST NOT accept relative-path IMAP references.
If you/your document shepherd is more comfortable with SHOULD NOT for
the server behavior, that would still be an improvement, but you
probably have the obligation to say what the server SHOULD do with a
relative-path IMAP reference in that case.
Considering that you are the second person who raised this issue, I will
go with your proposal.
I would prefer SHOULD NOT in the last sentence, but the idea of
explaining how to handle this properly scares me, so I will stick with
the MUST NOT for now :-). If I change my mind, I will let you review the
updated text.
10.1. Security Consideration specific to URLAUTH authorized URL
The decision to use the "anonymous" access identifier should be
made with extreme caution. An "anonymous" access identifier can be
used by anyone; and therefore use of this access identifier should
be limited to content which may be disclosed to anyone. Many IMAP
servers do not permit anonymous access; in the case of such servers
the "anonymous" access identifer is equivalent to "authuser", but
this MUST NOT be relied upon.
Spencer: OK, light-years beyond my expertise here, but are you
telling me that there's no way for a client to discover the server's
"no anonymous access" policy?
There is a way for a client to discover if the server supports
anonymous authentication (the server will refuse AUTHENTICATE
ANONYMOUS if it doesn't).
There is also a way for the client to discover if anonymous access
identifier is supported: the client can try to sign an URL with the
anonymous access identifier and see if it gets refusal from the server.
If so, it might be nice to add this as a reason *why* "this MUST NOT
be relied upon".
The point of this MUST is to make sure that implementors don't treat
them as the same, as there are security considerations associated
with them (as discussed in the quoted paragraph). I would welcome any
suggestions about how to make this clearer.
I'm out of my depth here, but it seems that you're saying
- they aren't the same, but
- some implementors treat them the same, so
Only server that don't support anonymous access would treat them as same.
- other implementers can't rely on them being treated differently,
even though they are different.
IMHO, other implementors shouldn't care whether they are treated
differently or not. The two URL types are semantically different,
treating them as the same is just not safe.
I would prefer adding text that requires conformant implementations to
treat them differently ("correctly") - the current text seems to place
the burden of dealing with nonconforming implementations on conforming
implementations, and that's a bigger burden than "conservative in what
you send, liberal in what you accept"....
Thinking more about this: the first part of the last sentence is just an
observation, while the second part of the same sentence is trying to
prevent people from doing stupid things if they misinterpreted the first
part. So, I don't actually think that this sentence adds any value.
Server implementors for servers that don't support anonymous access
would just come to the same conclusion.
So, in order to avoid any confusion I would remove the last sentence.
Unless you think that the document should state that the two URL types
MUST NOT be treated by clients as the same.
Regards,
Alexey
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
