Matt: Many thanks for your detailed review. Much appreciated. Authors, can you take these notes into account?
Jari On 01 Sep 2016, at 05:15, Matt Miller <mamil...@cisco.com> wrote: > * There is at least a couple of mentions of the > "Authentication-Info" header, but no reference to RFC 7615 in which > it is defined. I think an informational reference is warranted > here. > > * Just reading sections 4.5. "Location-when-logout parameter" and > 4.6. "Logout-timeout parameter", it is unclear how these are meant > to interact to inform a client the user's authentication session. > Frankly, I think the text in section 4.5 is too vague about how > a client can detect termination of a user's authenticated session, > and could use more of a hint on how "logout-timeout" is involved > to accomplish it. At the least, I think both sections 4.5. and > 4.6. need pointers to section 5. to help readers get a > sense of how to apply them. > > * In section 4.7. "Username parameter", I think there should be > an explicit pointer to the Security Considerations to warn about > potential issues this parameter presents. I also recommend > separating that portion of the Security Considerations about > "username" into its own subsection to make such a callout > better. > > * Since this document is acknowledging that cookies are used for > authentication, and > > Nits/editorial comments: > > * In section 2.1. "Terms for describing authentication protocol > flow", the word "distinguishable" should instead be "distinguished" > in the phrase "it can't be distinguishable from a non-authenticated > response." > > * In section 3. "Optional Authentication", the word "be" is missing > in "Optional-WWW-Authenticate header MUST NOT sent on 401 > responses". > > * In section 3.1. "Note on Optional-WWW-Authenticate and use of > WWW-Authenticate header with non-401 status", the word "is" should > be replaced with "are" in the phrase "clients which is unaware of > this extension will ignore the header". > > * Also in section 3.1., the word "authentications" should be > "authentication" in the phrase "secondary fallback method of > authentications". > > * Also in section 3.1., the word "ignores" should be "ignore" in > the phrase "just ignores the WWW-Authenticate headers". > > * Also in section 3.1., all instances of the word "implementer" > should be replaced with "implementers" in the phrase "the authors > propose implementer of the standard HTTP/1.1 specification > (especially implementer of this extension)". > > * In section 4. "Authentication-Control header", the word "an" > should be "a" in the phrase "and MUST be sent in an plain". > > * In section 4.1. "Non-ASCII extended header parameters", the > interoperability note as a number of grammatical challenges. > I believe the following addresses the grammar issues while > retaining its meaning: > > """ > Interoperability note: [RFC7235], Section 2.2, defines the "realm" > authentication parameter which cannot be replaced by the "realm*" > extend parameter. It means that the use of non-ASCII values for an > authentication realm is not the defined behavior in HTTP. > Unfortunately, some people currently use a non-ASCII realm parameter > in reality, but even its encoding scheme is not well-defined. > Given this background, this document does not specify how to handle > a non-ASCII "realm" parameter in the extended header fields. If > needed, the authors propose to use a non-extended "realm" parameter > form, with a wish for maximum interoperability. > """ > > * In section 4.2. "Auth-style parameter", the word "preferences" > should be replaced with "preference" in the phrase "server's > preferences for user interface behavior". > > * In section .4.4. "No-auth parameter", the word "authentications" > should be replaced with "authentication" in the phrase "content is > desired before authentications". > > * In section 4.6. "Logout-timeout parameter", the word "from" should > be removed in the phrase "has passed since from the time this header > was received". > > * In section 5.3. "When to use Cookies", the first sentence has some > grammatical challenges, which I believe the following text addresses: > > """ > In current Web sites using form-based authentication, Cookies > [RFC6265] are used for managing both authorization and > application sessions. > """ > > * In section 5.4. "Parallel deployment with Form/Cookie > authentications", the META tag example should be "<META > http-equiv="refresh" ...>" instead of ">META http-equiv="refresh" > ...<". > > * In section 7. "IANA Considerations", the word "documents" should > be "document" in the phrase "a publicly-accessible documents".
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
