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

[Alexey Melnikov <[e-mail]>]

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

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