|
1.
|
Clear description of the referenced document:
|
|
|
|
|
2.
|
Status of approval:
|
|
|
Approved as standards track document (Proposed Standard).
|
|
3.
|
Justification for the specific reference:
|
|
|
This reference defines the HTTP Authentication framework.
|
|
4.
|
Current information, if any, about IPR issues:
|
|
|
Information on IPR issues regarding RFCs is available at: https://datatracker.ietf.org/ipr/search/. Specifically: https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=4103
|
|
5.
|
Other useful information describing the "Quality" of the document:
|
|
|
RFC 7235 was published in June 2014 and is a standards track RFC. This document defines the HTTP Authentication framework.
|
|
6.
|
The degree of stability or maturity of the document:
|
|
|
Proposed standard
|
|
7.
|
Relationship with other existing or emerging documents:
|
|
|
N/A
|
|
8.
|
Any explicit references within that referenced document should also be listed:
|
|
|
Normative references:/
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate/
Requirement Levels", BCP 14, RFC 2119, March 1997./
/
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax/
Specifications: ABNF", STD 68, RFC 5234, January 2008./
/
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014./
/
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014./
/
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 2014./
/
Informative references:/
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration/
Procedures for Message Header Fields", BCP 90, RFC 3864,/
September 2004./
/
[OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web/
Applications and Web Services", The Open Web Application/
Security Project (OWASP) 2.0.1, July 2005,/
https://www.owasp.org/./
/
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,/
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext/
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999./
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,/
Leach, P., Luotonen, A., and L. Stewart, "HTTP/
Authentication: Basic and Digest Access Authentication",/
RFC 2617, June 1999./
/
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform/
Resource Identifier (URI): Generic Syntax", STD 66,/
RFC 3986, January 2005./
/
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data/
Encodings", RFC 4648, October 2006./
/
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an/
IANA Considerations Section in RFCs", BCP 26, RFC 5226,/
May 2008./
/
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security/
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
|
|
9.
|
Qualification of
ISOC/IETF:
|
|
|
9.1-9.6 Decisions of ITU Council to admit ISOC to participate in the work of the Sector (June 1995 and June 1996).
9.7 The Internet Engineering Steering Group (IESG) is responsible for ongoing maintenance of the RFCs when the need arises. Comments on RFCs and corresponding changes are accommodated through the existing standardization process.
9.8 Each revision of a given RFC has a different RFC number, so no confusion is possible. All RFCs always remain available on-line. An index of RFCs and their status may be found in the IETF archives at http://www.rfc-editor.org/rfc.html.
|
|
10.
|
Other (for any supplementary information):
|
|
|
References should always be made to RFC numbers (and not by other designations such as STD, BCP, etc.). References not to be made to documents referred to as "Internet Drafts" or RFCs categorized as "Historic". Normative references should not be made to RFCs that are not standards, for example, "Informational" and "Experimental" RFCs.
|
|
