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

[Spencer Dawkins <[e-mail]>]

Hi, Alexey,

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" <[e-mail]>


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

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

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

I'd say "quite a bit clearer". Thanks for the improvement to my suggestion!

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

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

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

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.

Just curious - is it obvious what the IMAP4 server does when an AUTHORIZED 
ANONYMOUS client provides this URL? 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.

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

- other implementers can't rely on them being treated differently, even 
though they are different.

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

Thanks,

Spencer 




_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art