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
Summary: This document is close to being ready for publication as a Proposed
Standard, but there is some more-than-nit text that I just can't parse, and
I have a decent number of questions about 2119 language, almost all being
SHOULDs with no "escape hatch". Nothing big. "Almost ready, with questions",
I think.
Nits included in these comments are not part of the Gen-ART review, but are
provided to other reviewers and editors for consideration.
Comments: as follow...
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. 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? 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
(by both? by either? mumble)?
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. 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?
2. Introduction
The IMAP URL follows the common Internet scheme syntax as defined
in [URI-GEN]. If :<port> is omitted, the port defaults to 143.
Spencer (nit): would it be appropriate to expand this to something like
"defaults to 143 (as assigned by IANA)"?
3.2. IMAP User Name and Authentication Mechanism
If no user name and no authentication mechanism is supplied, the
client MUST authenticate as anonymous to the server. If the server
advertises AUTH=ANONYMOUS IMAP capability, the client MUST use the
AUTHENTICATE command with ANONYMOUS [ANONYMOUS] SASL mechanism. If
SASL ANONYMOUS is not available, the (case-insensitive) user name
"anonymous" is used with the "LOGIN" command and the password is
supplied as the Internet e-mail address of the end user accessing
Spencer: would it be correct to say "and the Internet e-mail address of the
end user accessing the resource is supplied as the password"? The current
text seems backwards. I'm not sure anyone could actually MISinterpret it,
but it's not clear on first reading (at least, not to me).
the resource. The latter option is given in order to provide for
interoperability with deployed servers.
Note that if unsafe or reserved characters such as " " or ";" are
Spencer (probably a nit): I'm assuming that " " is a space character (and
not some other character that got clobbered in XML2RFC), but if so, saying
'" " (space)' would be clearer to me.
present in the user name or authentication mechanism, they MUST be
percent-encoded as described in [URI-GEN].
3.3. Limitations of enc-user
As per sections 3.1 and 3.2 the IMAP URI enc-user has two purposes:
Spencer (nit): it would be clearer to me if these cross-references were
explicitly to this document (and not to sections in some other document).
1) It provides context for user-specific mailbox paths such
as "INBOX" (section 3.1).
2) It specifies that resolution of the URL requires logging in
as that user and limits use of that URL to only that user
(Section 3.2).
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
Spencer (nit): s/restrictions/restriction/
unique mailbox names (see Section 3.1) whenever possible (*).
The URLAUTH component overrides the second purpose of the enc-user
in the IMAP URI and by default permits the URI to be resolved by
any user permitted by the <access> identifier. URLAUTH and <access>
identifier are described in section 6.1.
(*) 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...
5. Lists of messages
An IMAP URL referring to a list of messages has the following form:
imap://<iserver>/<enc-mailbox>[<uidvalidity>][?<enc-search>]
The <enc-mailbox> field is used as the argument to the IMAP4
"SELECT" or "EXAMINE" command. Note that if unsafe or reserved
characters such as " ", ";", or "?" are present in <enc-mailbox>
Spencer (nit): Again, adding "(space)", etc. seems clearer to me.
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. (There are quite a few SHOULDs without listed exceptions, so
please consider this a fairly general comment).
strings and non-synchronizing literals [LITERAL+] are allowed in
the <enc-search> content, however synchronizing literals are not
allowed, as their presence would effectively mean that the agent
interpreting IMAP URLs needs to parse an <enc-search> content, find
all synchronizing literals and perform proper command continuation
request handling (see sections 4.3 and 7 of [IMAP4]).
6.1.1.1. URLAUTH
The URLAUTH is a component, appended at the end of a URL, which
conveys authorization to access the data addressed by that URL. It
contains an authorized access identifier, an authorization mecha-
nism name, and an authorization token. The authorization token is
generated from the URL, the authorized access identifer, authoriza-
tion mechanism name, and a mailbox access key.
(Note that currently this specification only allows for the URLAUTH
Spencer (nit): when this specification is published as an RFC, "currently"
will mean "until updated or obsoleted", so I'd drop "currently" now.
component in IMAP URLs describing a message or its part.)
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, but that would be difficult to detect, and would not
affect interoperation (until, perhaps, an attacker figured this out, but
that's another story).
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?)
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?
9. Examples
The following examples demonstrate how an IMAP4 client program
might translate various IMAP4 URLs into a series of IMAP4 commands.
Commands sent from the client to the server are prefixed with "C:",
and responses sent from the server to the client are prefixed with
"S:".
The URL:
<imap://minbari.example.org/gray-council;UIDVALIDITY=385759045/;
UID=20/;PARTIAL=0.1024>
Results in the following client commands:
Spencer (nit - actually, two nits): the introduction to this section says
pretty clearly that other client command mappings are possible, and even if
all clients used the same mapping, commands can fail. So I'm suggesting
s/Results in/May result in/
Spencer (Which brings me to my next nit): the examples show both client
commands and server responses, so I'm suggesting s/client commands/client
commands and server responses/
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? If so, it might be nice to add this as a reason *why* "this
MUST NOT be relied upon".
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
