Subject: [lemonade] WGLC IMAP URL - update

From: Eric Burger <[email-masked]>
Date: Thu, 22 Mar 2007 00:53:33 +0100

http://www.ietf.org/internet-drafts/draft-ietf-lemonade-rfc2192bis-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
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: <[email-masked]>
Date: Tue, 27 Mar 2007 15:18:59 +0300

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:[email-masked]] 
>Sent: 22 March, 2007 01:54
>To: [email-masked]
>Subject: [lemonade] WGLC IMAP URL - update
>
>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.
>

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 30 Mar 2007 09:49:55 +0100

>Hi all,  
Hi Zoltan,
Thank you for the comments!

I've addressed/replied to some of your comments, see below. I will deal 
with the rest of your comments later.

>1. Possible typo in "3. IMAP userinfo component" -> iuserinfo? Or, does it mean userinfo of [URI-GEN]?  
The section title should read:
  IMAP userinfo component (iuserinfo)
 [...]

>4. Typo in section 3.2 first paragraph: "may contains" -> "may contain"  
Fixed, thanks.

>5. Caps use in section 3.2 first paragraph: "an IMAP user Name"
I lowercased Name.
 [...]

>What exactly does "They" refer to? 
I've changed "They" to "The IMAP user name and the authentication 
mechanism".
 [...]

>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?
I think the "Since URLs can easily come from untrusted sources" part 
provides important background. I can move it till after the "Care must 
be taken ...". Would this be any better?
 [...]

>15. Typo in section 3.2 paragraph 9: "SASL mechaninism" -> "SASL mechanism"  
Fixed.

 [...]

>"If it is not present, all contents of the mailbox SHOULD be presented by the program interpreting the URL."
I will change this to "the entire content ..." instead.

>How can I verify that the random string that I have generated in unpredictable?  
In general case you can't ;-).

This requirement can't be externally verified, but it is needed to make 
sure that implementations don't use bad sources of randomness, such as 
rand()

>Can these strings include spaces and other "fun stuff"
>
Yes.

>that might break an IMAP URI?
>
... but they wouldn't break IMAP URIs. Mailbox access key is never a 
part of an IMAP URI, so weird characters there don't matter.
The URLAUTH token is always hex encoded.

>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.
>
The text describing URLAUTH was taken from [URLAUTH], so there should be 
no differences. 2192bis should be self sufficient for understanding 
URLAUTH part of IMAP URLs. Let me know if it isn't.
 [...]

>27. "Funny" line breaks in section 10.1  
Chris Newman has already reported this and I've fixed this in my copy.

---

From: <[email-masked]>
Date: Sat, 31 Mar 2007 13:26:05 +0300

Hi Alexei,
thank You for all fixes.
Here are some futher comments on the open ones:

>>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?
>>
>I think the "Since URLs can easily come from untrusted 
>sources" part provides important background. I can move it 
>till after the "Care must be taken ...". Would this be any better?
> [...]

The part I do not like is "Care must be taken" it does not sound right
to me, especially at the beginning of a sentence - however I can
understand what it means. Perhaps a native English speaker can respond
on this?

>This requirement can't be externally verified, but it is 
>needed to make sure that implementations don't use bad sources 
>of randomness, such as
>rand()

Wouldn't it be better to describe this (instead of requiring something
that cannot be verified)?

Thank You.