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

From: Spencer Dawkins <[email-masked]>
Date: Thu, 02 Aug 2007 18:45:57 -0500

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-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 04 Aug 2007 05:10:25 -0600

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

> 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 

I guess this can be added, but I thought it was obvious.

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

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

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

> Spencer (nit): s/restrictions/restriction/

Fixed, thanks.

> Spencer (nit): I'm not used to seeing "footnotes" in Internet Drafrs...

I think it is clearer this way.

> Spencer (nit): Again, adding "(space)", etc. seems clearer to me.

Added.

> 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).
>
> Spencer (nit): when this specification is published as an RFC, 
> "currently" will mean "until updated or obsoleted", so I'd drop 
> "currently" now.

Done.

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

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

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

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

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

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 06 Aug 2007 06:18:55 -0500

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" <[email-masked]>

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

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

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

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

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

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

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

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

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

>> expected one or the other (since the two categories are mutually 
> 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...

>> important - perhaps ", but relative-path IMAP references are still in use 
>> in older IMAP implementations" or something similar?
>

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.

>> access" policy?
>> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 06 Aug 2007 21:31:39 +0100

Hi Spencer,

> chance the Gen-ART reviewer can remember what the review was trying to 
> say! Thanks for quick feedback.
>
> 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
>
>>> 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.
>>
>>> I guess what I'm trying to undestand is (a) will this document and 
>>> the apparent 4467bis be advanced together?
>>
>> 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.

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

 [...]

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

>>> 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.
>>
> Ah. This isn't a 2119 SHOULD. If I understand correctly, the intention 
> is to say
>

This reads better, thanks!

> So, based on the previous point, I'm thinking the review comment 
> should be "please make sure that your SHOULDs really are 2119 SHOULDs:
>
>>> 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,
>>

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

>>> have expected one or the other (since the two categories are 
>>> mutually exclusive and collectively exhaustive, aren't they?)
>>
>>
> 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
>

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...
>
>>> 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.
>>
> Ah. I thought all the unintended consequences from protocol reuse were 
> in the RAI area :-) Perhaps this could be stated more clearly? 
> Something like
>
>    relative-path IMAP references, they were found to be problematic 
> during 2006
>    MUST NOT generate relative-path IMAP4 references. Servers 
> conforming to this
> 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.

>>> 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).
>>
>> them as the same, as there are security considerations associated 
>> with them (as discussed in the quoted paragraph). I would welcome any 

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

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 07 Aug 2007 13:46:27 -0500

Hi, Alexey,

Just a follow-up note - I'm good with the proposed text as you describe it 
("Gen-ART reviewer is happy").

I'm still somewhat confused about "unpredictable" mailbox access keys, but I 
better understand your point ("128 bits of entropy" is the important part). 
Thanks for working with me on this one.

since I don't worry about threat models for a living, and with the current 
IESG your document is being reviewed by two SEC ADs, one retired SEC AD, AND 
SEC-DIR, I'll leave "unpredictable" for the professionals... if they are OK, 
I'll be more than OK.

Thanks,

Spencer

> Either way, neither "cryptographically" nor "unpredictable" is externally 
> observable.
>

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 17 Aug 2007 07:58:38 -0500

Document: draft-ietf-lemonade-rfc2192bis-09
Reviewer: Spencer Dawkins
Review Date: 2007-08-17
IETF LC End Date: 2007-06-28 (for 08)
IESG Telechat date: 2007-08-23

Summary: This document is ready for publication as a Proposed Standard

Comments:

My questions and comments from the 08 Gen-ART review have been addressed.

I like Russ's suggested text about 128 bits of entropy in the ID tracker, 
FWIW...

Spencer

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 17 Aug 2007 14:13:46 +0100

> My questions and comments from the 08 Gen-ART review have been addressed.

Thank you for the review, I think it improved the document.

> I like Russ's suggested text about 128 bits of entropy in the ID 
> tracker, FWIW...

I like Russ's suggestion as well.