|
1.
|
Clear description of the referenced document:
|
|
|
|
|
2.
|
Status of approval:
|
|
|
Standards track RFC - Proposed Standard published June 2022
|
|
3.
|
Justification for the specific reference:
|
|
|
For session-based JPIP communication, the new v3 edition of Rec. ITU-T T.808 introduces the "h3” and "h3s” transports, which are identified in the text as H3 and H3S, respectively. These transports are based on HTTP/3, defined in IETF RFC 9114, which provides a reliable encrypted connection, itself based on UDP datagrams, over which data is communicated via QUIC streams, as defined in IETF RFC 9000.
|
|
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/?draft=&rfc=9000&doctitle=&group=&holder=&iprtitle=&patent=&submit=rfc
|
|
5.
|
Other useful information describing the "Quality" of the document:
|
|
|
RFC 9114 was published in June 2022 and is a standards track RFC. HTTP semantics ([HTTP]) are used for a broad range of services on the Internet. These semantics have most commonly been used with HTTP/1.1 and HTTP/2. HTTP/1.1 has been used over a variety of transport and session layers, while HTTP/2 has been used primarily with TLS over TCP. HTTP/3 supports the same semantics over the QUIC transport protocol.
QUIC is widely used for data transport and multimedia delivery services. The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. RFC 9114 describes a mapping of HTTP semantics over QUIC. It also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3.
|
|
6.
|
The degree of stability or maturity of the document:
|
|
|
The concepts in this document is sufficiently stable for our use.
|
|
7.
|
Relationship with other existing or emerging documents:
|
|
|
None
|
|
8.
|
Any explicit references within that referenced document should also be listed:
|
|
|
Normative references:/
[ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP/
Alternative Services", RFC 7838, DOI 10.17487/RFC7838,/
April 2016, ./
/
[COOKIES] Barth, A., "HTTP State Management Mechanism", RFC 6265,/
DOI 10.17487/RFC6265, April 2011,/
./
/
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,/
Ed., "HTTP Semantics", STD 97, RFC 9110,/
DOI 10.17487/RFC9110, June 2022,/
./
/
[HTTP-CACHING]/
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,/
Ed., "HTTP Caching", STD 98, RFC 9111,/
DOI 10.17487/RFC9111, June 2022,/
./
/
[HTTP-REPLAY]/
Thomson, M., Nottingham, M., and W. Tarreau, "Using Early/
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September/
2018, ./
/
[QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK:/
Field Compression for HTTP/3", RFC 9204,/
DOI 10.17487/RFC9204, June 2022,/
./
/
[QUIC-TRANSPORT]/
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based/
Multiplexed and Secure Transport", RFC 9000,/
DOI 10.17487/RFC9000, May 2021,/
./
/
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,/
RFC 793, DOI 10.17487/RFC0793, September 1981,/
./
/
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate/
Requirement Levels", BCP 14, RFC 2119,/
DOI 10.17487/RFC2119, March 1997,/
./
/
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)/
Extensions: Extension Definitions", RFC 6066,/
DOI 10.17487/RFC6066, January 2011,/
./
/
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,/
"Transport Layer Security (TLS) Application-Layer Protocol/
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,/
July 2014, ./
/
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for/
Writing an IANA Considerations Section in RFCs", BCP 26,/
RFC 8126, DOI 10.17487/RFC8126, June 2017,/
./
/
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC/
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,/
May 2017, ./
/
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform/
Resource Identifier (URI): Generic Syntax", STD 66,/
RFC 3986, DOI 10.17487/RFC3986, January 2005,/
.
|
|
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):
|
|
|
None.
|
|
