[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [lemonade] WGLC IMAP URL - update; comments
Hi all,
here are some comments for -04:
1. Possible typo in "3. IMAP userinfo component" -> iuserinfo? Or, does it mean userinfo of [URI-GEN]?
2. Clarification needed for section 3.1: in medias res.
Assuming a top-down reading order, the terms "enc-user" and "iuserinfo" have not been mentioned yet so the reader will have no clue what these terms mean. I scrolled back up to section 2, but there are no such things either. It might also be that there is something missing under "3. IMAP userinfo component" because that section seems to be empty (only a heading without text). Reading the ABNF clears this up, but ABNF is at the end of the document. Perphaps moving the first paragraph of section 3.2 to section 3?
3. Unclear reference in section 3.2 first paragraph: "The userinfo component [URI-GEN] of an IMAP URI ..."
[URI-GEN] is not the userinfo component, but [URI-GEN] does have a userinfo component - could this be somehow captured? Suggest removing [URI-GEN].
4. Typo in section 3.2 first paragraph: "may contains" -> "may contain"
5. Caps use in section 3.2 first paragraph: "an IMAP user Name"
6. Is this really needed: "(Note that the "enc-user" also defines a mailbox naming scope as described in section 3.1)" I mean if you keep this paragrapsh here, it should not be needed because You should have read that part already... Then again, if You moved it up to section 3, then it should be either re-worded to cover all other sub-sections as well.
7. Clarification needed in section 3.2 paragraph 1: "They are used in the "LOGIN" or "AUTHENTICATE" commands after making the connection to the IMAP server."
What exactly does "They" refer to?
8. Extra "for" in section 3.2 paragraph 2: "in order to provide for interoperability with"
9. Clarification needed in section 3.2 paragraph 3: Shouldn't this be moved in from of the previous paragraph? That talks about what happens when there no user name, so it would seem logical to use the user name first, and then if there no user name, use anonymous instead.
10. Clarification needed in section 3.2 paragraph 5: "If no user name is specified, one SHOULD be obtained from the mechanism or requested from the user as appropriate."
Iis this really a SHOULD? When AUTH is used I would not expect anonymous to be used, therefore the user MUST have a user name. The next paragraph seems to give some more info on this, but not really: it looks like a client is allowed to send anonymous AUTH.
11. Clarification needed in section 3.2 paragraph 6: "This allows a URL which grants read-write access to authorized users, and read-only anonymous access to other users."
What exactly does "this" refer to?
12. Wording change in section 3.2 paragraph 8: "care must be taken when resolving a URL which requires or requests any sort of authentication" Wouldn't there be an easier way to say this?
13. Wording change suggestion in section 3.2 paragraph 8:
"If authentication credentials are supplied to the wrong server, it may compromise the security of the user's account. The program resolving the URL should make sure it meets at least one of the following criteria in this case:"
->
"Supplying authentication credentials to the wrong server may compromise the security of the user's account, therefore the program resolving the URI should meet at least one of the following criterias:"
Note that I replaced URL with URI - do we want to do this for the rest of the document?
14. Clarification needed in section 3.2 paragraph 9: "Note that user entry of the URL may or may not count as a trusted source, depending on the experience level of the user and site policy."
How can the "experience level of the user" govern whether the source is trusted? Sounds awfully wrong - things should be secure in any case.
How does one calculate the "experience level of the user" and what counts as a "safe" level?
I thought bullet (3) would cover the user's mistakes.
15. Typo in section 3.2 paragraph 9: "SASL mechaninism" -> "SASL mechanism"
16. Wording chage suggestion in section 3.2 paragraph 9:
"An authentication mechanism is used which will not reveal information to the server which could be used to compromise future connections."
->
"Use an authentication mechanism with the server that does not reveal any information that could be used to compromise future connections."
17. Section 3.2 paragraph 10. I do not think that such authentication should be allowed. Why not force anonymous instead? Well, at least this is hinted in the next paragraph with saying: "If a URL does not contain a user name or authentication mechanism, then only an anonymous connection may be re-used.", so which one is it? Allow omitting user name or force anonymous? I would prefer the latter.
Also, there is a bunch of line breaks after this paragraph - something missing, or accidental insertion?
18. Question regarding section 3.2 last paragraph: the paragraph is fine, but seeing the work in EAI group should we add some UTF8 considerations here? Actually, make this comment general. I found section 8 later on. Should section 8 be reference earlier (to avoid such questions)?
19. Wording change suggestion in 3.3 paragraph 1:
"An obvious limitation of using the same field for both purposes is that the URL can only be resolved by the mailbox owner."
->
"An obvious limitation of using the same field for both purposes is that the URL can be resolved only by the mailbox owner."
20. Wording change suggesting in section 5, last paragraph:
"If it is not present, the contents of the mailbox SHOULD be presented by the program interpreting the URL."
->
"If it is not present, all contents of the mailbox SHOULD be presented by the program interpreting the URL."
21. Question about this requirement in section 6.1.1.2 paragraph 1: "MUST be unpredictable"
How can I verify that the random string that I have generated in unpredictable?
22. Question for section 6.1.1.2 and 6.1.1.5.
Can these strings include spaces and other "fun stuff" that might break an IMAP URI? I read no restriction here. Similarly, any considerations for UTF-8 here (I mean 128bit means something else using US-ASCII and UTF8)? I would expect at least a statement that the limitations described in [URLAUTH] apply here as well, no additional restrictions.
23. Clarification needed in section 6.1.2 paragraph 4. What is "submit+", what is a "access identifier prefix" and what is a "userid" - these have not been mentioned before, and these are not in the ABNF either.
Same question for "user+", "authuser" in the following paragraphs.
24. Re-location proposal for section 6.1.2 last paragraph: shouldn't this be in section 6.1.1.5?
25. General comment to section 6: an example or two would be nice.
26. Question on section 7.2 paragraph 1. Why is it a "SHOULD NOT"? I mean what is the exception for? Wouldn't a "MUST NOT" be better?
27. "Funny" line breaks in section 10.1
28. The last page seems to be blank.
I understand quite a few of these might look as knit-picking, but I would like to make sure that the document will be easy to consume for the beginners as well.
Thank You.
Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566
>-----Original Message-----
>From: ext Eric Burger [mailto:eburger at bea.com]
>Sent: 22 March, 2007 01:54
>To: lemonade at ietf.org
>Subject: [lemonade] WGLC IMAP URL - update
>
>http://www.ietf.org/internet-drafts/draft-ietf-lemonade-rfc2192
>bis-04.txt
>
>Work Group Last Call ends April 15.
>
>_______________________________________________________________________
>Notice: This email message, together with any attachments,
>may contain information of BEA Systems, Inc., its
>subsidiaries and affiliated entities, that may be
>confidential, proprietary, copyrighted and/or legally
>privileged, and is intended solely for the use of the
>individual or entity named in this message. If you are not the
>intended recipient, and have received this message in error,
>please immediately return this by email and then delete it.
>
>_______________________________________________
>lemonade mailing list
>lemonade at ietf.org
>https://www1.ietf.org/mailman/listinfo/lemonade
>Supplemental Web Site:
>http://www.standardstrack.com/ietf/lemonade
>
_______________________________________________
lemonade mailing list
lemonade at ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade