![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changes between Initial Version and Version 1 of Ticket #510
- Timestamp:
- 30/10/13 13:11:33 (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #510 – Description
initial v1 7 7 comments just like any other last call comments. 8 8 9 ---- 10 9 11 The document obsoletes RFC 2616 and updates 2617. It says that it 10 12 “defines HTTP/1.1 access control and authentication.” I have not been … … 12 14 generating this doc, so my review is unbiased by that context. 13 15 16 ---- 17 14 18 I see that “ought” is used in two places on page 6, but not in uppercase 15 19 as per RFC 6919. The authors should revisit the use of this term here. 20 21 ---- 16 22 17 23 Also on page 6 it appears that the phrase “receipt of” was omitted in … … 22 28 Likewise, upon *<>* a request that requires authentication by proxies 23 29 30 ---- 31 24 32 Later on page 6 the text says: 25 33 26 The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.34 The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification. 27 35 28 36 Encryption is not, per se, an authentication mechanism. Please revise 29 37 this text. 38 39 ---- 30 40 31 41 In Section 2.2 the text says: … … 37 47 later requests, not a user. 38 48 49 ---- 50 39 51 The end of Section 2.2 includes the word “might” but not uppercase, as 40 52 per RFC 6919. I again suggest that the authors reconsider using this 41 53 term in this context. 54 55 ---- 42 56 43 57 In Section 4.3, the text says: … … 48 62 request, then isn’t this a MUST vs. a MAY? 49 63 64 ---- 65 50 66 In Section 4.4 the text says: 51 67 … … 55 71 ambiguous construct ever take on both meanings simultaneously? 56 72 73 ---- 74 57 75 Section 5.1.2 uses “ought” when discussing definitions for new 58 76 authentication schemes. See comments above re use of this term.The same 59 77 section also uses the phrase “need to” twice, where MUST seems appropriate. 78 79 ---- 60 80 61 81 The Security Considerations section (6) is about one page in length. It
