[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lemonade] WGLC IMAP URL - update; comments
Zoltan.Ordogh at nokia.com wrote:
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.
here are some comments for -04:
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.
[...]
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?
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.
[...]
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."
I will change this to "the entire content ..." instead.
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?
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()
22. Question for section 6.1.1.2 and 6.1.1.5.
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.
_______________________________________________
lemonade mailing list
lemonade at ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade