[Gen-art] Re: Gen-ART LC Review of draft-ietf-lemonade-rfc2192bis-08

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

Hi Spencer,
Thank you for the review.

> 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.

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).

> 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.

> 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)"?

I've added "(as defined in Section 2.1 of [IMAP4])" instead, I think 
this is slightly clearer.

> 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.

You are correct, the text is backward!
I've updated it as you suggested.

> 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.

Added.

>     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).

Right. Added "of this 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/

Fixed, thanks.

>     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...

I think it is clearer this way.

> 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.

Added.

>     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.
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.

> (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.

Done.

>     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,

It is a MUST on server implementations due to a security consideration.

> but that would be difficult to detect, and would not affect 
> interoperation (until, perhaps, an attacker figured this out, but 
> that's another story).

This MUST is not really observable by the client. Do you have any better 
ideas what to put here?

> 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.

> 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.

> 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/

Both changes made.

> 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.

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art