Subject: RE: [lemonade] WGLC IMAP URL - update; comments (2192bis)

From: <[email-masked]>
Date: Fri, 4 May 2007 15:39:40 +0300

>>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."
>
>"Reveal to the server" part is important. The replacement 
>sentence doesn't have it. I understand that the sentence might 
>be difficult to understand, but it is correct. What is the 
>exact problem with the existing sentence?

There is no problem, just an attempt to improve readability. I accept
Your justification, so leave it as it is.

>>24. Re-location proposal for section 6.1.2 last paragraph: 
>shouldn't this be in section 6.1.1.5?
>
>I would rather not do that. Section 6.1.1.5 provides 
>definition. The last paragraph of section 6.1.2 mostly talks 
>about encoding.

If You insist :-)

Thanks for the replies.

_______________________________________________
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: Fri, 4 May 2007 16:05:52 +0300

>-----Original Message-----
>From: ext Alexey Melnikov [mailto:[email-masked]] 
>Sent: 18 April, 2007 02:41
>To: Ordogh Zoltan (Nokia-TP-MSW/Tampere)
>Cc: [email-masked]
>Subject: Re: [lemonade] WGLC IMAP URL - update; comments (2192bis)
>
>[email-masked] wrote:
>
>>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.
>>  
>>
>The previous paragraph starts with:
>  The URLAUTH takes the form ";URLAUTH=<access>:<mech>:<token>", and
>  MUST be at the end of the URL.
>
>So the sentence like the following:
>  The "submit+" access identifier prefix, followed by a userid,
>  indicates that only a userid authorized as a message submission
>  entity on behalf of the specified userid is permitted to use this
>  URL.
>really means:
>
>  The "submit+" <access> identifier prefix, followed by a userid,
>  indicates that only a userid authorized as a message submission
>  entity on behalf of the specified userid is permitted to use this
>  URL.
>
>Would it be clearer if I include <> around "access"?
>
>

Yes, what would help, thank You.

---

From: <[email-masked]>
Date: Fri, 4 May 2007 16:12:33 +0300

>Sent: 28 April, 2007 20:14
>>9. Clarification needed in section 3.2 paragraph 3: Shouldn't 
>this be moved in from 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.
>>
>The 3rd paragraph used to be a part of the 2nd paragraph in RFC 2192.
>As it summarizes what is described in subsequent paragraphs, I 
>think the best thing is just to delete it. Otherwise it might 
>be interpreted as conflicting with some of them.

Anyone having a problem with deleting it?

>>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?
>>
>This might be impossible to code, but the text is correct.
>I would not trust my mother to understand the difference 
>between "[email-masked]" and "[email-masked]".
>
>>I thought bullet (3) would cover the user's mistakes.
>>  
>>
>People automatically hit Ok button way too often, so explicit 
>confirmation might help, but might not completely address the issue.
>
> [...]

Well, I still don't like it, but I guess I am going to have to accept
this fact.

>>17. Section 3.2 paragraph 10.
>>
>>I do not think that such authentication should be allowed. 
>Why not force anonymous instead?
>>
>This is explained in the following text describing ;AUTH=*:
>
>     If no user name is specified and no appropriate 
>authentication mechanisms
>     are available, the client SHOULD fall back to anonymous 
>login as described
>     above.  This allows a URL which grants read-write access 
>to authorized
>     users, and read-only anonymous access to other users.
>
>>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.
>>
>Unless there is strong consensus from the WG to change the 
>behavior described in RFC 2192, I would leave this text as is.

It seems noone in the WG raised the issue, so I guess we can leave it as
it is.

Thanks for the fixes and replies.

---

From: <[email-masked]>
Date: Fri, 4 May 2007 16:14:02 +0300

>Sent: 28 April, 2007 19:13
>Actually they are:
>  access          = ("submit+" enc-user) / ("user+" enc-user) /
>                    "authuser" / "anonymous"
>
>I've changed "access" to "<access>" in several places to make 
>this clearer.
>
> [...]

Adding the <> was definiately needed. It's OK now.
Thanks.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 06 May 2007 15:46:18 +0100

Hi Zoltan,

>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?
>
I've added syntax of various components to sections that mention them 
for the first time. This will appear in version -06 of the draft.
Let me know if -06 is sufficiently clear.