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

From: Alexey Melnikov <[email-masked]>
Date: Wed, 18 Apr 2007 00:28:15 +0100

[email-masked] wrote:

>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?

>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.

Any other opinions?

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 18 Apr 2007 00:41:09 +0100

[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"?

---

From: "Eric Burger" <[email-masked]>
Date: Mon, 23 Apr 2007 16:39:24 -0700

The use of passive voice, or the construction <form of to Be> <imperfect
past-tense verb>, is poor English when writing for technical topics.

Consider the example below:
"Care must be taken when doing foo."
           ^^^^^^^^
The question is, WHO must take care?

Likewise, consider this example:
"Clean-up must be done before exiting."
Again, WHO must do clean-up?

It is rather easy to make passive voice into active voice.  Take <form
of to be> <imperfect past-tense verb> and rearrange it to be <actor>
<active verb> <object>.  For example, to correct the two examples above,
we have:

The server must take care when doing foo.
                ^^^^

The client must do clean-up before exiting.
                ^^
Altnernately, most of the time for the latter construction, when dealing
with a form of "to do," one can drop the "do," as the real action verb
is all that is necessary:
The client must clean-up before exiting.

Note that exactly specifying who does an action is (1) explicit, leaving
no room for error and (2) concise, as it often is the same number of
words or less.  Even if you have one or two more words in your sentence
from specifying the actors exactly, the removal of any ambiguity is
worth the extra words.

When should one use passive voice?  Well, the last sentence is often a
candidate, when one writes, "When can passive voice be used?"  True, the
latter version is one word shorter.  Moreover, in the context of this
e-mail, it should be obvious to whom I am addressing.  However, as
standards are often quoted out of context, it is a good practice to
always use active voice, explicitly labeling the subject.  For example,
mystery writers often use passive voice, as part of the point is to not
know who the active killer is.

Most word processors, including Microsoft Word for Mac and Windows, will
check for passive voice in their grammar checkers.  Many people turn
them off for creative writing.  I would offer one turns them on for
standards work.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, March 31, 2007 6:26 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [lemonade] WGLC IMAP URL - update; comments

[snip]
>>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?
[snip]

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, 27 Apr 2007 09:16:18 +0100

>The question is, WHO must take care?
Ok, this is a good argument.
I rewrote the sentence without passive voice. ("Clients must take care ...")

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 28 Apr 2007 17:12:48 +0100

>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…
Actually they are:
  access          = ("submit+" enc-user) / ("user+" enc-user) /
                    "authuser" / "anonymous"

>Same question for "user+", "authuser" in the following paragraphs.
I've changed "access" to "<access>" in several places to make this clearer.

 [...]

>25. General comment to section 6: an example or two would be nice.
>
Added.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 28 Apr 2007 18:14:19 +0100

[email-masked] wrote:

>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.

>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."
>
>Is 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.
>
After talking to Chris, I've decided to change the last SHOULD to a 
MUST. You are right, a username must always be available. Either from 
the mechanism (for SASL EXTERNAL, GSSAPI or ANONYMOUS), or from 
user/configuration.

[...]

>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.

 [...]

>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.