avtcore payload bfcpbis calext capport cellar cbor core cdni clue dispatch dcrup doh dmarc extra ecrit httpbis ice insipid netvc codec jmap modern xrblock mmusic perc rtcweb regext stir slim sipcore sipbrandy uta mtgvenue dmm dprive dhc dnssd homenet hip intarea ipwave 6man lpwan 6lo 6tisch lwig ntp softwire savi sunset4 tictoc anima bmwg dime dnsop grow v6ops l2sm lmap lime mboned netconf netmod opsec opsawg radext sidrops babel bess bfd bier ccamp detnet idr i2rs isis l2tpext lisp manet mpls nvo3 ospf pce pim pals rtgwg roll sidr sfc spring teas trill ace acme kitten curdle dots i2nsf ipsecme lamps mile trans sacm secevent suit tokbind tls oauth alto dtn ippm mptcp nfsv4 quic rmcat tcpinc tcpm tsvwg taps tram Audio/Video Transport Core Maintenance (avtcore) ------------------------------------------------ Charter Last Modified: 2017-03-07 Current Status: Active Chairs: Jonathan Lennox Rachel Huang Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Ben Campbell Mailing Lists: General Discussion: avt@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/avt Archive: https://mailarchive.ietf.org/arch/browse/avt/ Description of Working Group: The Real-time Transport Protocol (RTP) along with its associated profiles and payload formats provides for real-time transmission of audio and video over unicast and multicast transports. RTP is widely implemented, and deployed for a wide range of applications, ranging from telephony to television over IP. RTP itself has been shepherded to Full Standard. Its associated profiles, extensions, and payload formats are currently at various levels of standards maturity. As new applications have emerged, the need for guidelines for the use of the RTP/RTCP protocols and extensions specific to those applications has been identified. The AVTCORE working group is chartered to maintain the core RTP/RTCP specifications and the AVP, SAVP, AVPF, and SAVPF profiles. The group will provide architectural guidance for extending the protocols and guidelines for their proper use. While other working groups are chartered to work on RTCP Extended Report Extensions (XRBLOCK) and RTP Payload Formats (PAYLOAD), extensions that are generally applicable will be developed in AVTCORE. The AVTCORE working group is also chartered to develop application-specific guidelines for the use of RTP/RTCP protocols with the AVP, SAVP, AVPF, and SAVPF profiles, and extensions to those protocols that are driven by application-specific needs. The AVTCORE working group will coordinate closely with the Security Area while working on maintenance and enhancements to the SRTP Profile (SAVP). Goals and Milestones: Done - Submit update for A General Mechanism for RTP Header Extensions (RFC5285) for publication as proposed standard Nov 2016 - Submit Guidelines for using the Multiplexing Features of RTP for Informational Nov 2016 - Submit Multipath RTP as experimental RFC Done - Submit Mechanism for Layer Refresh Request for Proposed Standard Jul 2017 - Submit RTP Header Extension for Video Frame Information for Proposed Standard Apr 2018 - Submit Feedback Mechanism for RTP Congestion Control for Proposed Standard Internet-Drafts: - Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows [draft-ietf-avt-app-rtp-keepalive-10] (12 pages) - Explicit Congestion Notification (ECN) for RTP over UDP [draft-ietf-avt-ecn-for-rtp-03] (44 pages) - Forward-Shifted RTP Redundancy Payload Support [draft-ietf-avt-forward-shifted-red-08] (13 pages) - Port Mapping Between Unicast and Multicast RTP Sessions [draft-ietf-avt-ports-for-ucast-mcast-rtp-11] (35 pages) - AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) [draft-ietf-avt-srtp-aes-gcm-02] (19 pages) - Encrypted Key Transport for Secure RTP [draft-ietf-avt-srtp-ekt-03] (53 pages) - Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution [draft-ietf-avt-srtp-not-mandatory-16] (10 pages) - Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing [draft-ietf-avtcore-5761-update-06] (7 pages) - Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) [draft-ietf-avtcore-6222bis-06] (10 pages) - The Addition of SRTP crypto suites based on the ARIA algorithms to the SDP Security Descriptions [draft-ietf-avtcore-aria-sdes-02] (9 pages) - The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP) [draft-ietf-avtcore-aria-srtp-11] (19 pages) - Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) [draft-ietf-avtcore-avp-codecs-03] (4 pages) - RTP Control Protocol (RTCP) Feedback for Congestion Control [draft-ietf-avtcore-cc-feedback-message-00] (10 pages) - RTP Clock Source Signalling [draft-ietf-avtcore-clksrc-11] (30 pages) - Explicit Congestion Notification (ECN) for RTP over UDP [draft-ietf-avtcore-ecn-for-rtp-08] (58 pages) - RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report [draft-ietf-avtcore-feedback-supression-rtp-17] (13 pages) - Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP) [draft-ietf-avtcore-idms-13] (23 pages) - RTP and Leap Seconds [draft-ietf-avtcore-leap-second-08] (9 pages) - Guidelines for Use of the RTP Monitoring Framework [draft-ietf-avtcore-monarch-22] (17 pages) - Multipath RTP (MPRTP) [draft-ietf-avtcore-mprtp-03] (41 pages) - Sending Multiple Types of Media in a Single RTP Session [draft-ietf-avtcore-multi-media-rtp-session-13] (16 pages) - Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams [draft-ietf-avtcore-multiplex-guidelines-05] (43 pages) - Port Mapping between Unicast and Multicast RTP Sessions [draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02] (30 pages) - A General Mechanism for RTP Header Extensions [draft-ietf-avtcore-rfc5285-bis-14] (25 pages) - Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS) [draft-ietf-avtcore-rfc5764-mux-fixes-11] (13 pages) - Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions [draft-ietf-avtcore-rtp-circuit-breakers-18] (25 pages) - Sending Multiple RTP Streams in a Single RTP Session [draft-ietf-avtcore-rtp-multi-stream-11] (29 pages) - Sending Multiple RTP Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback [draft-ietf-avtcore-rtp-multi-stream-optimisation-12] (18 pages) - Options for Securing RTP Sessions [draft-ietf-avtcore-rtp-security-options-10] (37 pages) - RTP Topologies [draft-ietf-avtcore-rtp-topologies-update-10] (48 pages) - AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP) [draft-ietf-avtcore-srtp-aes-gcm-17] (48 pages) - Encrypted Key Transport for Secure RTP [draft-ietf-avtcore-srtp-ekt-03] (45 pages) - Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP) [draft-ietf-avtcore-srtp-encrypted-header-ext-05] (15 pages) - Guidelines for the Use of Variable Bit Rate Audio with Secure RTP [draft-ietf-avtcore-srtp-vbr-audio-04] (6 pages) - Frame Marking RTP Header Extension [draft-ietf-avtext-framemarking-06] (11 pages) - RTP Congestion Control: Circuit Breakers for Unicast Sessions [draft-perkins-avtcore-rtp-circuit-breakers-01] (15 pages) - Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) [draft-rescorla-avtcore-6222bis-00] (10 pages) Requests for Comments: RFC6263: Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows (12 pages) RFC6284: Port Mapping between Unicast and Multicast RTP Sessions (30 pages) RFC6354: Forward-Shifted RTP Redundancy Payload Support (13 pages) * Updates RFC2198 * Updates RFC4102 RFC6562: Guidelines for the Use of Variable Bit Rate Audio with Secure RTP (6 pages) RFC6642: RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report (13 pages) RFC6679: Explicit Congestion Notification (ECN) for RTP over UDP (58 pages) * Updates RFC8311 RFC6792: Guidelines for Use of the RTP Monitoring Framework (17 pages) RFC6904: Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP) (15 pages) * Updates RFC3711 RFC7007: Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) (4 pages) * Updates RFC3551 RFC7022: Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) (10 pages) * Obsoletes RFC6222 * Updates RFC3550 RFC7164: RTP and Leap Seconds (9 pages) * Updates RFC3550 RFC7201: Options for Securing RTP Sessions (37 pages) RFC7202: Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution (10 pages) RFC7272: Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP) (23 pages) RFC7273: RTP Clock Source Signalling (30 pages) RFC7667: RTP Topologies (48 pages) * Obsoletes RFC5117 RFC7714: AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP) (48 pages) RFC7983: Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS) (13 pages) * Updates RFC5764 RFC8035: Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing (7 pages) * Updates RFC5761 RFC8083: Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions (25 pages) * Updates RFC3550 RFC8108: Sending Multiple RTP Streams in a Single RTP Session (29 pages) * Updates RFC3550 * Updates RFC4585 RFC8269: The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP) (19 pages) RFC8285: A General Mechanism for RTP Header Extensions (25 pages) * Obsoletes RFC5285 Audio/Video Transport Payloads (payload) ---------------------------------------- Charter Last Modified: 2015-06-15 Current Status: Active Chairs: Ali C. Begen Roni Even Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Ben Campbell Mailing Lists: General Discussion: payload@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/payload Archive: https://mailarchive.ietf.org/arch/browse/payload/ Description of Working Group: The PAYLOAD working group is tasked with the specification and maintenance of payload formats for use with the Real-Time Transport Protocol, RTP [RFC3550]. The group will follow the guidelines established in "Guidelines for Writers of RTP Payload Format Specifications" [BCP 36], the "How to Write an RTP Payload Format" (under development) and is responsible for maintaining those guidelines. This working group will develop RTP payload formats for new media codecs, review and revise existing payload formats to advance those which are useful to Draft Standard or Standard, and declare others Historic. Goals and Milestones: Done - Submit RTP Payload Format for MIDI for Proposed Standard Done - Submit RTP Payload Format for MPEG-4 Audio/Visual Streams for Proposed Standard Done - Submit RTP Payload Format for DV (IEC 61834) Video for Proposed Standard Done - Submit RTP Payload Format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) for Proposed Standard Done - Submit RTP profile for the carriage of SMPTE 336M data for Proposed Standard Done - Submit How to Write an RTP Payload Format for Informational Done - Submit RTP Payload Format for VP8 Video for Proposed Standard Done - Submit RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs for Proposed Standard Done - Submit RTP Payload Format for G.711.0 for Proposed Standard Done - Submit RTP Payload Format for High Efficiency Video Coding for Proposed Standard. Done - Submit RTP Payload Format for Opus Speech and Audio Codec as proposed standard Done - Submit RTP Payload Format for SMPTE ST 291 Ancillary Data for Proposed Standard Done - submit RTP Payload Format for MELPe Codec Mar 2017 - Submit RTP Payload Format for Non-Interleaved and Interleaved Parity FEC Mar 2017 - Submit RTP Payload Format for VP9 Video for Proposed Standard May 2017 - submit RTP Payload Format for VC-2 HQ Profile Video Internet-Drafts: - RTP Payload Format for MPEG-4 Audio/Visual Streams [draft-ietf-avt-rfc3016bis-02] (32 pages) - RTP Payload Format for DV (IEC 61834) Video [draft-ietf-avt-rfc3189bis-04] (19 pages) - RTP Payload Format for MIDI [draft-ietf-avt-rfc4695-bis-10] (171 pages) - RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) [draft-ietf-avt-rtp-evrc-nw-10] (21 pages) - RTP Payload Format for G.718 Speech/Audio [draft-ietf-avt-rtp-g718-05] (27 pages) - RTP Payload Format for IP-MR Speech Codec [draft-ietf-avt-rtp-ipmr-15] (19 pages) - RTP Payload Format for the iSAC Codec [draft-ietf-avt-rtp-isac-04] (16 pages) - RTP Payload Format for SMPTE 336M Encoded Data [draft-ietf-avt-rtp-klv-02] (12 pages) - RTP Payload Format for MVC Video [draft-ietf-avt-rtp-mvc-01] (25 pages) - RTP Payload Format for Bluetooth's SBC audio codec [draft-ietf-avt-rtp-sbc-01] (23 pages) - RTP Payload Format for Scalable Video Coding [draft-ietf-avt-rtp-svc-27] (100 pages) - RTP Payload Format for Flexible Forward Error Correction (FEC) [draft-ietf-payload-flexible-fec-scheme-05] (38 pages) - RTP Payload Format for G.711.0 [draft-ietf-payload-g7110-06] (32 pages) - RTP Payload Format for the Mixed Excitation Linear Prediction Enhanced (MELPe) Codec [draft-ietf-payload-melpe-06] (30 pages) - RTP Payload Format for MPEG-4 Audio/Visual Streams [draft-ietf-payload-rfc3016bis-03] (35 pages) - RTP Payload Format for DV (IEC 61834) Video [draft-ietf-payload-rfc3189bis-03] (18 pages) - RTP Payload Format for MIDI [draft-ietf-payload-rfc4695-bis-02] (171 pages) - RTP Payload for SMPTE ST 291-1 Ancillary Data [draft-ietf-payload-rtp-ancillary-14] (19 pages) - RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs [draft-ietf-payload-rtp-aptx-05] (16 pages) - RTP Payload Format for G.718 Speech/Audio [draft-ietf-payload-rtp-g718-03] (27 pages) - RTP Payload Format for High Efficiency Video Coding (HEVC) [draft-ietf-payload-rtp-h265-15] (86 pages) - How to Write an RTP Payload Format [draft-ietf-payload-rtp-howto-14] (65 pages) - RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data [draft-ietf-payload-rtp-klv-04] (13 pages) - RTP Payload Format for MVC Video [draft-ietf-payload-rtp-mvc-02] (30 pages) - RTP Payload Format for the Opus Speech and Audio Codec [draft-ietf-payload-rtp-opus-11] (18 pages) - RTP Payload Format for Bluetooth's SBC Audio Codec [draft-ietf-payload-rtp-sbc-07] (23 pages) - RTP Payload Format for VC-2 HQ Profile Video [draft-ietf-payload-rtp-vc2hq-04] (21 pages) - RTP Payload Format for VP8 Video [draft-ietf-payload-vp8-17] (27 pages) - RTP Payload Format for VP9 Video [draft-ietf-payload-vp9-04] (22 pages) Requests for Comments: RFC6190: RTP Payload Format for Scalable Video Coding (100 pages) RFC6262: RTP Payload Format for IP-MR Speech Codec (19 pages) RFC6295: RTP Payload Format for MIDI (171 pages) * Obsoletes RFC4695 RFC6416: RTP Payload Format for MPEG-4 Audio/Visual Streams (35 pages) * Obsoletes RFC3016 RFC6469: RTP Payload Format for DV (IEC 61834) Video (18 pages) * Obsoletes RFC3189 RFC6597: RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data (13 pages) RFC6884: RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) (21 pages) RFC7310: RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs (16 pages) RFC7587: RTP Payload Format for the Opus Speech and Audio Codec (18 pages) RFC7655: RTP Payload Format for G.711.0 (32 pages) RFC7741: RTP Payload Format for VP8 Video (27 pages) RFC7798: RTP Payload Format for High Efficiency Video Coding (HEVC) (86 pages) RFC8088: How to Write an RTP Payload Format (65 pages) * Updates RFC2736 RFC8130: RTP Payload Format for the Mixed Excitation Linear Prediction Enhanced (MELPe) Codec (30 pages) Binary Floor Control Protocol Bis (bfcpbis) ------------------------------------------- Charter Last Modified: 2017-08-01 Current Status: Active Chairs: Charles Eckel Keith Drage Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Adam Roach Mailing Lists: General Discussion: bfcpbis@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/bfcpbis Archive: https://mailarchive.ietf.org/arch/browse/bfcpbis/ Description of Working Group: The BFCPBIS working group is chartered to specify a revision of BFCP (RFC 4582) to support using both TCP and UDP as transports. The current version of BFCP only supports TCP, which when both endpoints are behind NATs or firewalls, has a lower success rate than using the ICE techniques with a UDP based transport for BFCP. The need for video endpoints to work in these types of environments is driving a strong need to support a UDP based transport as well as TCP. This WG will create a revision of RFC 4582 which adds optional support for UDP to BFCP. The security when using UDP will be based on DTLS. The updated protocol will use an existing approach (e.g., stop and wait with a single outstanding transaction) to provide a reliable, congestion safe, and TCP friendly transport. In addition to providing a way for dealing with the reliable delivery of client-initiated transactions, the updated protocol will also be able to deliver server-initiated transactions reliably when needed. The WG will research the size of messages used and decide if fragmenting a request or response over multiple UDP packets is required. The new protocol will be backwards compatible with RFC 4582 when used in TCP mode. The BFCPBIS WG will coordinate closely with the MMUSIC WG to create a revision of RFC 4583 specifying how BFCP is signaled in SDP so that it supports UDP as well as TCP transports. This WG would ask the MMUSIC WG to add a milestone to create a revisions of RFC 4583 to address signaling the use of UDP in SDP. The WG will coordinate with International Multimedia Telecommunications Consortium (IMTC) and other industry fora. Goals and Milestones: Done - Draft revision of RFC 4582 to IESG as Proposed Standard Nov 2016 - Draft revision of RFC 4583 to IESG as Proposed Standard Done - Draft for BFCP over WebSocket to IESG as Proposed Standard Done - Draft for SDP WebSocket Connection URI Attribute to IESG as Proposed Standard C Internet-Drafts: - The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP) [draft-ietf-bfcpbis-bfcp-websocket-15] (14 pages) - The Binary Floor Control Protocol (BFCP) [draft-ietf-bfcpbis-rfc4582bis-16] (90 pages) - Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams [draft-ietf-bfcpbis-rfc4583bis-18] (23 pages) - The Session Description Protocol (SDP) WebSocket Connection URI Attribute [draft-ietf-bfcpbis-sdp-ws-uri-09] (12 pages) Requests for Comments: RFC8124: The Session Description Protocol (SDP) WebSocket Connection URI Attribute (12 pages) Calendaring Extensions (calext) ------------------------------- Charter Last Modified: 2016-05-06 Current Status: Active Chairs: Daniel Migault Donald E. Eastlake 3rd Philipp Kewisch Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Alexey Melnikov Mailing Lists: General Discussion: calsify@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/calsify Archive: https://mailarchive.ietf.org/arch/browse/calsify/ Description of Working Group: The Calendaring Extensions working group is chartered to develop extensions to the iCalendar (RFC 5545), iTIP (RFC 5546), and CalDAV (RFC 4791) standards. This working group will do the following: - Develop an extension to iCalendar to support non-Gregorian recurrence rules, without the need to support new calendar scale values in iCalendar as a whole. This will allow for easy implementation of the primary use case for non-Gregorian support in calendar systems, without the need for significant changes to the iCalendar format. The non-Gregorian calendar system should be based on the International Components for Unicode work by the Unicode Consortium (http://site.icu-project.org). - Develop an extension to iCalendar to support a new component type that allows users to express arbitrary, possibly repeating, periods of "available" time. The primary use case for this is for users to express their "office hours" (e.g., Monday-Friday, 9am-5pm) in a standard way to ensure free busy lookups show the correct periods of availability. - Define a set of new iCalendar properties and parameters to standardise some existing experimental X- properties in common use, based on a survey of existing implementations. - Define a set of new iCalendar properties and parameters to cover key uses cases that implementers have identified, including, but not limited to, a new "IMAGE" property (to allow embedding/linking of images tied to a specific event), and a "CONFERENCE" property (to allow embedding information about dial-in numbers and similar multi-party communication options for an event). The working group will work under the following parameters: - The extensions developed are expected to be backwards-compatible with the existing calendar standards. Incompatibilities must be identified, minimized, and justified. - For each set of extensions, examine their impact on the iTIP protocol (RFC 5546), and define any necessary extensions to iTIP to accommodate such impact. - For each set of extensions, examine their impact on the CalDAV protocol (RFC 4791), and define any necessary extensions to CalDAV to accommodate such impact. Interface with the httpbis working group to ensure that any CalDAV changes are consistent with good http practices. The working group will use the following drafts as initial input for its work: draft-daboo-icalendar-rscale-03 draft-daboo-calendar-availability-05 draft-daboo-icalendar-extensions-08 The following are out of scope for the working group: - Any change that impacts backwards compatibility with existing deployed iCalendar/iTIP/CalDAV clients and servers will be discussed by the working group with a view to minimizing disruption to deployed implementations without compromising desirable new function. - Any attempt to develop non-Gregorian calendar systems/calculations. Goals and Milestones: Done - Submit non-Gregorian recurrence rule draft to IESG for publication Done - WG adoption of an availability draft Done - WG adoption of an extensions draft Done - Submit availability draft to IESG for publication Done - Submit extensions draft to IESG for publication May 2017 - Send attachment dratf to IESG Jun 2017 - Send Event Publication draft to IESG Jul 2017 - Send iCal relation draft to IESG Internet-Drafts: - Calendar Availability [draft-daboo-calendar-availability-05] (22 pages) - New Properties for iCalendar [draft-daboo-icalendar-extensions-09] (21 pages) - Non-Gregorian Recurrence Rules in iCalendar [draft-daboo-icalendar-rscale-04] (15 pages) - Calendar Availability [draft-ietf-calext-availability-04] (24 pages) - CalDAV Managed Attachments [draft-ietf-calext-caldav-attachments-03] (36 pages) - Event Publishing Extensions to iCalendar [draft-ietf-calext-eventpub-extensions-05] (31 pages) - New Properties for iCalendar [draft-ietf-calext-extensions-05] (23 pages) - Support for iCalendar Relationships [draft-ietf-calext-ical-relations-03] (19 pages) - JSCalendar: A JSON representation of calendar data [draft-ietf-calext-jscalendar-00] (51 pages) - Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar) [draft-ietf-calext-rscale-04] (21 pages) - JSCalendar: A JSON representation of calendar data [draft-jenkins-jscalendar-05] (51 pages) Requests for Comments: RFC7529: Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar) (21 pages) * Updates RFC5545 * Updates RFC6321 * Updates RFC7265 RFC7953: Calendar Availability (24 pages) * Updates RFC4791 * Updates RFC5545 * Updates RFC6638 RFC7986: New Properties for iCalendar (23 pages) * Updates RFC5545 Captive Portal Interaction (capport) ------------------------------------ Charter Last Modified: 2017-07-10 Current Status: Active Chairs: Erik Kline Martin Thomson Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Adam Roach Mailing Lists: General Discussion: captive-portals@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/captive-portals Archive: https://mailarchive.ietf.org/arch/search/?email_list=captive-portals Description of Working Group: Some networks require interaction from users prior to authorizing network access. Before that authorization is granted, network access might be limited in some fashion. Frequently, this authorization process requires human interaction to arrange for payment or to accept some legal terms. Currently, network providers use a number of interception techniques to reach a human user (such as intercepting cleartext HTTP to force a redirect to a web page of their choice), and these interceptions are indistinguishable from man-in-the-middle attacks. As endpoints become inherently more secure, existing interception techniques will become less effective or will fail entirely. This will result in a poor user experience as well as a lower rate of success for the Captive Portal operator. The CAPPORT Working Group will define secure mechanisms and protocols to - allow endpoints to discover that they are in this sort of limited environment, - provide a URL to interact with the Captive Portal, - allow endpoints to learn about the parameters of their confinement, - interact with the Captive Portal to obtain information such as status and remaining access time, and - optionally, advertise a service whereby devices can enable or disable access to the Internet without human interaction. (RFC 7710 may be a full or partial solution to the first two bullets) The working group may produce working documents to define taxonomy and to survey existing portals and solutions. These might or might not be published as RFCs, and might or might not be combined in some way. Out of scope are "roaming" (federation of credentials), network selection, or the on-boarding/provisioning of clients onto secure (or any alternate) networks. These are not really captive portals, and have largely been solved in other ways. Initially, the working group will focus on simplifying captive portal interactions where a user is present. A secondary goal is to look at the problem posed to or by devices that have little or no recourse to human interaction. Goals and Milestones: Aug 2018 - Protocol to discover and interact with a Captive Portal Aug 2018 - API for Captive Portal Interaction Internet-Drafts: - Captive Portal API [draft-ietf-capport-api-00] (6 pages) - CAPPORT Architecture [draft-ietf-capport-architecture-00] (14 pages) No Requests for Comments Codec Encoding for LossLess Archiving and Realtime transmission (cellar) ------------------------------------------------------------------------ Charter Last Modified: 2015-11-20 Current Status: Active Chairs: Tessa Fallon Tim Terriberry Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Ben Campbell Mailing Lists: General Discussion: cellar@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cellar Archive: https://mailarchive.ietf.org/arch/browse/cellar/ Description of Working Group: The preservation of audiovisual materials faces challenges from technological obsolescence, analog media deterioration, and the use of proprietary formats that lack formal open standards. While obsolescence and material degradation are widely addressed, the standardization of open, transparent, self-descriptive, lossless formats remains an important mission to be undertaken by the open source community. FFV1 is a lossless video codec and Matroska is an extensible media container based on EBML (Extensible Binary Meta Language), a binary XML format. There are open source implementations of both formats, and an increasing interest in and support for use of FFV1 and Matroska. However, there are concerns about the sustainability and credibility of existing specifications for the long-term use of these formats. These existing specifications require broader review and formalization in order to encourage widespread adoption. There is also a need for a lossless audio format to complement the lossless video codec and container format. FLAC is a lossless audio codec that has seen widespread adoption in a number of different applications including archival applications. While there are open source implementations of the codec, no formal standards for either the codec itself or its use in container formats currently exist. Review and formalization of the FLAC codec standard and its use in Matroska container formats is needed for wider adoption. Using existing work done by the development communities of Matroska, FFV1, and FLAC, the Working Group will formalize specifications for these open and lossless formats. In order to provide authoritative, standardized specifications for users and developers, the Working Group will seek consensus throughout the process of refining and formalizing these standards. Initial specifications can be accessed here: Specifications: - FFV1: https://mediaarea.net/temp/ffv1.html - Matroska: http://matroska.org/technical/specs/index.html - EBML: http://matroska-org.github.io/libebml/specs.html - FLAC: https://xiph.org/flac/format.html Development Versions: - FFV1: https://github.com/ffmpeg/ffv1 - Matroska: https://github.com/Matroska-Org/foundation-source/blob/master/spectool/specdata.xml - EBML: https://github.com/Matroska-Org/ebml-specification The Working Group will seek consensus and refinements for specifications for both FFV1 and Matroska in order to provide authoritative, standardized specifications for users and developers. Backward compatibility with existing versions 0-3 of the FFV1 and Matroska specifications will be an important goal, while also reviewing and refining the current version 4 under active development. Although not encouraged, non-backwards-compatible changes to the input specifications will be acceptable if the Working Group determines that the modifications are required to meet the group's technical objectives, provided that the reasons for these changes are clearly documented. Deliverables: - Informational specification for Matroska container format versions 1, 2 and 3 to IESG for publication - Standards Track specification for Matroska container format version 4 to IESG for publication - Informational specification for FFV1 video codec versions 0, 1 and 3 to IESG for publication - Standards Track specification for FFV1 video codec version 4 to IESG for publication - Standards Track specification for FLAC audio codec to IESG for publication Goals and Milestones: Apr 2017 - Submit informational specification for FFV1 video codec versions 0, 1 and 3 to IESG for publication Apr 2017 - Submit specification for EBML to IESG (Standards Track) Jul 2017 - Submit informational specification for Matroska container format versions 1, 2 and 3 to IESG for publication Jul 2017 - Submit specification for FFV1 video codec version 4 to IESG (Standards Track) Sep 2017 - Submit specification for Matroska container format version 4 to IESG (Standards Track) Dec 2017 - Submit specification for FLAC audio codec to IESG (Standards Track) Internet-Drafts: - Extensible Binary Meta Language [draft-ietf-cellar-ebml-04] (38 pages) - FF Video Codec 1 [draft-ietf-cellar-ffv1-01] (40 pages) - FF Video Codec 1 [draft-niedermayer-cellar-ffv1-02] (36 pages) No Requests for Comments Concise Binary Object Representation Maintenance and Extensions (cbor) ---------------------------------------------------------------------- Charter Last Modified: 2017-01-09 Current Status: Active Chairs: Francesca Palombini Joe Hildebrand Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Alexey Melnikov Mailing Lists: General Discussion: cbor@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cbor Archive: https://www.ietf.org/mail-archive/web/cbor/current/maillist.html Description of Working Group: Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript Object Notation (JSON, RFC 7159) data interchange format to include binary data and an extensibility model, using a binary representation format that is easy to parse correctly. It has been picked up by a number of IETF efforts (e.g., CORE, ANIMA GRASP) as a message format. The CBOR working group will update RFC 7049 to fix verified errata. Security issues and clarifications may be addressed, but changes to the document will ensure backward compatibility for popular deployed codebases. The resulting document will be targeted at becoming an Internet Standard. Similar to the way ABNF (RFC 5234/7405) can be used to describe the set of valid messages in a text representation, it would be useful if protocol specifications could use a description format for the data in CBOR-encoded messages. The CBOR data definition language (CDDL, based on draft-greevenbosch-appsawg-cbor-cddl) is a proposal for such a description technique that has already been used in CORE, ANIMA, CDNI, and efforts outside the IETF. The CBOR WG will complete the development of this specification by creating an Informational or Standards Track RFC. The document should specify its applicability statement in relationship to YANG data modelling language. In parallel to the work on CDDL, the WG will examine the CBOR extension for tagging of Typed Arrays (based on draft-jroatch-cbor-tags) and the CBOR extension for tagging of Object Identifiers and UUIDs (based on draft-bormann-cbor-tags-oid) that use CBOR's extensibility mechanisms to provide additional data types as used in certain applications. Where these proposals are deemed useful and do not require significant new development, the CBOR WG will complete these specifications as well. The WG will recharter before working on any further CBOR extensions. Goals and Milestones: May 2017 - Submit rfc7049bis to IESG as a Proposed Standard Oct 2017 - Submit CDDL to IESG as an Informational or Proposed Standard RFC Internet-Drafts: - Concise Binary Object Representation (CBOR) [draft-ietf-cbor-7049bis-01] (57 pages) - Concise data definition language (CDDL): a notational convention to express CBOR data structures [draft-ietf-cbor-cddl-01] (55 pages) No Requests for Comments Constrained RESTful Environments (core) --------------------------------------- Charter Last Modified: 2017-04-21 Current Status: Active Chairs: Carsten Bormann Jaime Jimenez Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Alexey Melnikov Mailing Lists: General Discussion: core@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/core Archive: https://mailarchive.ietf.org/arch/browse/core/ Description of Working Group: CoRE provides a framework for resource-oriented applications intended to run on constrained IP networks. A constrained IP network has limited packet sizes, may exhibit a high degree of packet loss, and may have a substantial number of devices that may be powered off at any point in time but periodically "wake up" for brief periods of time. These networks and the nodes within them are characterized by severe limits on throughput, available power, and particularly on the complexity that can be supported with limited code size and limited RAM per node [RFC 7228]. More generally, we speak of constrained node networks whenever at least some of the nodes and networks involved exhibit these characteristics. Low-Power Wireless Personal Area Networks (LoWPANs) are an example of this type of network. Constrained networks can occur as part of home and building automation, energy management, and the Internet of Things. The CoRE working group will define a framework for a limited class of applications: those that deal with the manipulation of simple resources on constrained networks. This includes applications to monitor simple sensors (e.g. temperature sensors, light switches, and power meters), to control actuators (e.g. light switches, heating controllers, and door locks), and to manage devices. The general architecture consists of nodes on the constrained network, called Devices, that are responsible for one or more Resources that may represent sensors, actuators, combinations of values, and/or other information. Devices send messages to change and query resources on other Devices. Devices can send notifications about changed resource values to Devices that have expressed their interest to receive notification about changes. A Device can also publish or be queried about its resources. (Typically a single physical host on the network would have just one Device but a host might represent multiple logical Devices. The specific terminology to be used here is to be decided by the working group.) As part of the framework for building these applications, the working group has defined a Constrained Application Protocol (CoAP) for the manipulation of Resources on a Device. CoAP is designed for use between Devices on the same constrained network, between Devices and general nodes on the Internet, and between Devices on different constrained networks both joined by an internet. (CoAP is also being used via other mechanisms, such as SMS on mobile communication networks.) CoAP targets the type of operating environments defined in the ROLL and 6Lo working groups which have additional constraints compared to normal IP networks, but the CoAP protocol also operates over traditional IP networks. There also may be proxies that interconnect between other Internet protocols and the Devices using the CoAP protocol. It is worth noting that proxy does not have to occur at the boundary between the constrained network and the more general network, but can be deployed at various locations in the less-constrained network. CoAP supports various forms of "caching". Beyond the benefits of caching already well known from REST, caching can be used to increase energy savings of low-power nodes by allowing them to be normally-off [RFC 7228]. For example, a temperature sensor might wake up every five minutes and send the current temperature to a proxy that has expressed interest in notifications; when the proxy receives a request over CoAP or HTTP for that temperature resource, it can respond with the last notified value (instead of trying to query the Device which may not be reachable at this time). The working group will continue to evolve this model to increase its practical applicability. The working group will perform maintenance on its first four standards-track specifications: - RFC 6690 - RFC 7252 - RFC 7641 - draft-ietf-core-block and will continue to evolve the experimental group communications support (RFC 7390). The working group will not develop a reliable multicast solution. CoAP today works over UDP and DTLS. The working group will define transport mappings for alternative transports as required, both IP (starting with TCP and a secure version over TLS) and non-IP (e.g., SMS, working with the security area on potentially addressing the security gap); this includes defining appropriate URI schemes. Continued compatibility with CoAP over SMS as defined in OMA LWM2M will be considered. CoRE will continue and complete its work on draft-ietf-core-resource-directory, as already partially adopted by OMA LWM2M. Interoperability with DNS-SD (and the work of the dnssd working group) will be a primary consideration. The working group will also work on a specification enabling broker-based publish-subscribe-style communication over CoAP. CoRE will work on related data formats, such as alternative representations of RFC 6690 link format and RFC 7390 group communication information. The working group will complete the SenML specification, again with consideration to its adoption in OMA LWM2M. RFC 7252 defines a basic HTTP mapping for CoAP, with further discussion in draft-ietf-core-http-mapping. This mapping will be evolved and supported by further documents. Besides continuing to examine operational and manageability aspects of the CoAP protocol itself, CoRE will also develop a way to make RESTCONF-style management functions available via CoAP that is appropriate for constrained node networks. This will require very close coordination with NETCONF and other operations and management working groups. YANG data models will be used for manageability. Note that the YANG modeling language is not a target for change in this process, though additional mechanisms that support YANG modules may be employed in specific cases where significant performance gains are both attainable and required. The working group will continue to consider the OMA LWM2M management functions as a well-accepted alternative form of management and provide support at the CoAP protocol level where required. The working group has selected DTLS as the basis for the communications security in CoAP. CoRE will work with the TLS working group on the efficiency of this solution. The preferred cipher suites will evolve in cooperation with the TLS working group and CFRG. The ACE working group is expected to provide solutions to authorization that may need complementary elements on the CoRE side. Object security as defined in JOSE and being adapted to the constrained node network requirements in COSE also may need additions on the CoRE side. The working group will coordinate on requirements from many organizations and SDO. The working group will closely coordinate with other IETF working groups, particularly of the constrained node networks cluster (6Lo, 6TiSCH, LWIG, ROLL, ACE, COSE), and appropriate groups in the IETF OPS and Security areas. Work on these subjects, as well as on interaction models and design patterns (including follow-up work around the CoRE Interfaces draft) may benefit from close cooperation with the proposed Thing-to-Thing Research Group. Goals and Milestones: Done - Blockwise transfers in CoAP submitted to IESG Done - Best Practices for HTTP-CoAP Mapping Implementation submitted to IESG Done - Representing CoRE Link Collections in JSON submitted to IESG Done - Patch and Fetch Methods for CoAP submitted to IESG for PS Done - WG adoption for Management over CoAP Done - CoAP over TCP, TLS, and WebSockets submitted to IESG for PS Dec 2017 - Media Types for Sensor Measurement Lists (SenML) submitted to IESG for PS Dec 2017 - CBOR Encoding of Data Modeled with YANG submitted to IESG for PS Dec 2017 - Object Security for Constrained RESTful Environments (OSCORE) Jan 2018 - Management over CoAP submitted to IESG for PS Mar 2018 - CoRE Resource Directory submitted to IESG for PS Dec 2099 - CoRE Interfaces submitted to IESG Internet-Drafts: - Block-Wise Transfers in the Constrained Application Protocol (CoAP) [draft-ietf-core-block-21] (37 pages) - The Constrained Application Protocol (CoAP) [draft-ietf-core-coap-18] (112 pages) - Publish-Subscribe Broker for the Constrained Application Protocol (CoAP) [draft-ietf-core-coap-pubsub-02] (23 pages) - CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets [draft-ietf-core-coap-tcp-tls-11] (51 pages) - CoAP Simple Congestion Control/Advanced [draft-ietf-core-cocoa-02] (17 pages) - CoAP Management Interface [draft-ietf-core-comi-02] (56 pages) - Dynamic Resource Linking for Constrained RESTful Environments [draft-ietf-core-dynlink-04] (16 pages) - Echo and Request-Tag [draft-ietf-core-echo-request-tag-00] (17 pages) - PATCH and FETCH Methods for the Constrained Application Protocol (CoAP) [draft-ietf-core-etch-04] (21 pages) - Group Communication for the Constrained Application Protocol (CoAP) [draft-ietf-core-groupcomm-25] (46 pages) - Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP) [draft-ietf-core-http-mapping-17] (40 pages) - Reusable Interface Definitions for Constrained RESTful Environments [draft-ietf-core-interfaces-10] (27 pages) - Constrained RESTful Environments (CoRE) Link Format [draft-ietf-core-link-format-14] (22 pages) - Representing Constrained RESTful Environments (CoRE) Link Format in JSON and CBOR [draft-ietf-core-links-json-09] (19 pages) - Object Security for Constrained RESTful Environments (OSCORE) [draft-ietf-core-object-security-08] (59 pages) - Observing Resources in the Constrained Application Protocol (CoAP) [draft-ietf-core-observe-16] (30 pages) - CoRE Resource Directory: DNS-SD mapping [draft-ietf-core-rd-dns-sd-00] (10 pages) - CoRE Resource Directory [draft-ietf-core-resource-directory-12] (64 pages) - Media Types for Sensor Measurement Lists (SenML) [draft-ietf-core-senml-12] (46 pages) - YANG Schema Item iDentifier (SID) [draft-ietf-core-sid-03] (25 pages) - CBOR Encoding of Data Modeled with YANG [draft-ietf-core-yang-cbor-05] (32 pages) Requests for Comments: RFC6690: Constrained RESTful Environments (CoRE) Link Format (22 pages) RFC7252: The Constrained Application Protocol (CoAP) (112 pages) * Updates RFC7959 RFC7390: Group Communication for the Constrained Application Protocol (CoAP) (46 pages) RFC7641: Observing Resources in the Constrained Application Protocol (CoAP) (30 pages) RFC7959: Block-Wise Transfers in the Constrained Application Protocol (CoAP) (37 pages) * Updates RFC7252 RFC8075: Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP) (40 pages) RFC8132: PATCH and FETCH Methods for the Constrained Application Protocol (CoAP) (21 pages) Content Delivery Networks Interconnection (cdni) ------------------------------------------------ Charter Last Modified: 2017-11-21 Current Status: Active Chairs: Francois Le Faucheur Kevin J. Ma Phil Sorber Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Alexey Melnikov Mailing Lists: General Discussion: cdni@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cdni Archive: https://mailarchive.ietf.org/arch/browse/cdni/ Description of Working Group: A Content Delivery Network (CDN) is an infrastructure of network elements operating at layer 4 through layer 7, arranged for the efficient distribution and delivery of digital content. Such content includes, but is not limited to, web pages and images delivered via HTTP, and streaming of continuous media delivered via HTTP, RTSP, RTMP, etc. CDNs typically provide services to multiple Content Service Providers (CSPs). CDNs provide numerous benefits: a shared platform for multi-service content delivery, reduced transmission costs for cacheable content, improved quality of experience for end users and increased robustness of delivery. For these reasons they are frequently used for large-scale content delivery. As a result of the significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure and many Network Service Providers and Enterprise Service Providers are deploying their own CDNs. Subject to the policy of the CSP, it is generally desirable that a given item of content can be delivered to an end user regardless of that end user's location or attachment network. This creates a need for interconnecting (previously) standalone CDNs so they can interoperate and collectively behave as a single delivery infrastructure. The goal of the CDNI Working Group is to allow the interconnection of separately administered CDNs in support of the end-to-end delivery of content from CSPs through multiple CDNs and ultimately to end users (via their respective User Agents). The CDNI WG aims at delivering a targeted, deployable solution in a short timeframe as needed by the industry. It is expected that the CDNI interfaces will be realized using existing IETF protocols for transport and message exchange, and using existing object notation grammars/languages for the definition of CDNI objects and semantics. In the event that protocol extensions or new protocols are deemed necessary by the WG, the WG will recharter. The working group will focus on the following items: - A "requirements" document. This document lists the requirements for the CDNI architecture and the CDNI interfaces. In particular, this document will focus on identifying a reasonable set of more urgent and important requirements that will be addressed in the initial set of CDNI protocols and solutions produced by the working group. This document will list the requirements stemming from the threat analysis and to be met by each of the CDNI interfaces. - A "framework" document providing a description of the different components of the CDNI architecture and how they interact with one another. This document will also include a "threat analysis" discussing the security concerns and threats, the trust model and privacy issues specific to CDNI. - A specification of the "CDNI Request Routing Redirection interface". This interface will allow an upstream CDN Request Routing system to obtain from the downstream CDN the information necessary to perform request redirection. It is actually a logical bundling of two separate but related interfaces: * Footprint & Capability Advertisement interface: Asynchronous operations to exchange routing information (e.g., the network footprint and capabilities served by a given CDN) that enables CDN selection for subsequent user requests; and * Request Routing Redirection interface: Synchronous operations to select a delivery CDN (surrogate) for a given user request. - A specification of the "CDNI Metadata interface". This interface will allow the CDNs to exchange content distribution metadata of inter-CDN scope. Content distribution metadata refers to the subset of content metadata that is relevant to the distribution of the content and therefore is to be processed by CDNs (for example, this may include information enabling: content acquisition, geo-blocking, enforcement of availability windows or access control). - A specification of the "CDNI Logging interface". This interface will allow CDN logging systems to exchange logging information associated with actions that are relevant across CDNs (such as content distribution, content delivery and content routing actions) for purposes of accounting, analytics, monitoring, etc. - A specification of the "CDNI Control interface". In particular, this interface will allow an upstream CDN to remove or invalidate content in a downstream CDN. - A specification for "CDNI URI Signing". This document will specify a mechanism that allows interconnected CDNs to support access control by signing content URIs. This may involve extensions to the CDNI interfaces (e.g. CDNI Metadata interface, CDNI Logging interface). The WG will discuss and address the security, management and operational issues specific to CDNI, inside the above documents and specifications. The working group will only define solutions for aspects of the CDN Interconnection problem space that require direct communication or interoperation between CDNs. In particular, the WG will not define: - New session, transport or network protocols. - New protocols for delivering content from a CDN to an End User/User Agent. - New protocols for ingestion of content or metadata between a CSP and a CDN. - New protocols for acquiring content across CDNs. - Protocols and algorithms for intra-CDN operations. - Support for Transparent Caching across CDNs. - New applications consuming CDNI logs. - Digital Right Management (DRM) mechanisms. The CDNI WG will work with other IETF WGs to assess, and where appropriate, leverage protocols developed by those WGs, in order to realize the CDNI requirements and CDNI interfaces. For example, the WG may assess the suitability of the ALTO protocol as a protocol to enable downstream CDNs to exchange information which may aid an upstream CDN with making CDNI request routing decisions. The CDNI WG will also coordinate with relevant groups outside the IETF, if and where appropriate. Goals and Milestones: Done - Submit CDNI problem statement to IESG as Informational Done - Submit CDNI use cases to IESG as Informational Done - Submit CDNI requirements to IESG as Informational Done - Submit CDNI framework to IESG as Informational Done - Submit specification of the CDNI Logging interface to IESG as Proposed Standard Done - Submit specification of the CDNI Control interface to IESG as proposed Standard Done - Submit specification of the CDNI Request Routing Redirection interface to IESG as Proposed Standard Done - Submit specification of the CDNI Metadata interface to IESG as Proposed Standard Done - Submit specification of the CDNI Footprint & Capabilities Advertisement interface to IESG as Proposed Standard Jun 2018 - Recharter or dissolve Jun 2018 - Submit specification of URI Signing for CDNI to IESG as Proposed Standard Internet-Drafts: - Content Delivery Network Interconnection (CDNI) Control Interface / Triggers [draft-ietf-cdni-control-triggers-15] (49 pages) - Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics [draft-ietf-cdni-footprint-capabilities-semantics-20] (31 pages) - Framework for Content Distribution Network Interconnection (CDNI) [draft-ietf-cdni-framework-14] (58 pages) - Content Distribution Network Interconnection (CDNI) Logging Interface [draft-ietf-cdni-logging-27] (63 pages) - Content Delivery Network Interconnection (CDNI) Media Type Registration [draft-ietf-cdni-media-type-06] (7 pages) - Content Delivery Network Interconnection (CDNI) Metadata [draft-ietf-cdni-metadata-21] (66 pages) - Content Distribution Network Interconnection (CDNI) Problem Statement [draft-ietf-cdni-problem-statement-08] (32 pages) - Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection [draft-ietf-cdni-redirection-20] (35 pages) - Content Distribution Network Interconnection (CDNI) Requirements [draft-ietf-cdni-requirements-17] (23 pages) - URI Signing for CDN Interconnection (CDNI) [draft-ietf-cdni-uri-signing-13] (36 pages) - Use Cases for Content Delivery Network Interconnection [draft-ietf-cdni-use-cases-10] (16 pages) Requests for Comments: RFC6707: Content Distribution Network Interconnection (CDNI) Problem Statement (32 pages) RFC6770: Use Cases for Content Delivery Network Interconnection (16 pages) * Obsoletes RFC3570 RFC7336: Framework for Content Distribution Network Interconnection (CDNI) (58 pages) * Obsoletes RFC3466 RFC7337: Content Distribution Network Interconnection (CDNI) Requirements (23 pages) RFC7736: Content Delivery Network Interconnection (CDNI) Media Type Registration (7 pages) RFC7937: Content Distribution Network Interconnection (CDNI) Logging Interface (63 pages) RFC7975: Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection (35 pages) RFC8006: Content Delivery Network Interconnection (CDNI) Metadata (66 pages) RFC8007: Content Delivery Network Interconnection (CDNI) Control Interface / Triggers (49 pages) RFC8008: Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics (31 pages) ControLling mUltiple streams for tElepresence (clue) ---------------------------------------------------- Charter Last Modified: 2017-03-29 Current Status: Active Chairs: Paul Kyzivat Roni Even Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Adam Roach Mailing Lists: General Discussion: clue@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/clue Archive: https://mailarchive.ietf.org/arch/browse/clue/ Description of Working Group: In the context of this WG, the term telepresence is used in a general manner to describe systems that provide high definition, high quality audio/video enabling a "being-there" experience. One example is an immersive telepresence system using specially designed and special purpose rooms with multiple displays permitting life size image reproduction using multiple cameras, encoders, decoders, microphones and loudspeakers. Current telepresence systems are based on open standards such as RTP, SIP, H.264, the H.323 suite. However, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor to another. A major factor limiting the interoperability of telepresence systems is the lack of a standardized way to describe and negotiate the use of the multiple streams of audio and video comprising the media flows. The WG will create specifications for SIP-based conferencing systems to enable communication of information about media streams so that a sending system, receiving system, or intermediate system can make reasonable decisions about transmitting, selecting, and rendering media streams. This enables systems to make choices that optimize user experience. This working group is chartered to specify the following information about media streams from one entity to another entity: * Spatial relationships of cameras, displays, microphones, and loudspeakers - relative to each other and to likely positions of participants * Viewpoint, field of view/capture for camera/microphone/display/loudspeaker - so that senders and intermediate devices can understand how best to compose streams for receivers, and the receiver will know the characteristics of its received streams * Usage of the stream, for example whether the stream is presentation, or document camera output * Aspect ratio of cameras and displays * Which sources a receiver wants to receive. For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection) Information between sources and sinks about media stream capabilities will be exchanged. The working group will define the semantics, syntax, and transport mechanism for communicating the necessary information. It will consider whether existing protocols for signaling, messaging and transport are adequate or need to be extended. Any extensions to IETF protocols will be done in appropriate WGs, for example extensions to SDP in MMUSIC. The scope of the work includes describing relatively static relations between entities (participants and devices). It also includes handling more dynamic relationships, such as specifying the audio and video streams for defined speakers. Specifying the location of the current speakers relative to display microphones needs to be provided dynamically as speakers move. As part of the receiver telling the sender what it wants dynamically, explicit receiver notification to the sender of the desired video stream and video pause will be considered. The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics. The focus of this work is on multiple RTP audio and video streams. Other media types may be considered, however development of methodologies for them is not within the scope of this work. Interoperation with SIP and related standards for audio and video is required. However, backwards compatibility with existing non-standards compliant telepresence systems is not required. This working group is not currently chartered to work on issues of continuous conference control including: far end camera control, floor control, conference roster. The working group may identify interoperability obstacles in existing open standards. If so, the WG will develop requirements to be communicated to other IETF WGs or Standards Forums, or recharter as appropriate. Reuse of existing protocols and backwards compatibility with SIP-compliant audio/video endpoints are important factors for the working group to consider. The work will closely coordinate with the appropriate areas (e.g., OPS and SEC), and working groups including AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. Goals and Milestones: Done - Submit informational draft to IESG on use cases Done - Submit informational draft to IESG on requirements Done - Submit standards track draft to IESG on Framework Done - Submit standards track draft to IESG on Data Model Done - Submit standards track draft to IESG on CLUE Protocol Done - Submit standards track draft to IESG on CLUE Data Channel Done - Submit standards track draft to IESG on Usage of RTP Done - Submit standards track draft to IESG on Overall Signaling and usage of SDP Internet-Drafts: - CLUE Protocol Data Channel [draft-holmberg-clue-datachannel-04] (11 pages) - An XML Schema for the CLUE data model [draft-ietf-clue-data-model-schema-17] (77 pages) - CLUE Protocol data channel [draft-ietf-clue-datachannel-14] (14 pages) - Framework for Telepresence Multi-Streams [draft-ietf-clue-framework-25] (84 pages) - CLUE protocol [draft-ietf-clue-protocol-14] (62 pages) - Mapping RTP streams to CLUE Media Captures [draft-ietf-clue-rtp-mapping-14] (14 pages) - Session Signaling for Controlling Multiple Streams for Telepresence (CLUE) [draft-ietf-clue-signaling-13] (41 pages) - Requirements for Telepresence Multistreams [draft-ietf-clue-telepresence-requirements-07] (12 pages) - Use Cases for Telepresence Multistreams [draft-ietf-clue-telepresence-use-cases-09] (17 pages) - CLUE Signaling [draft-kyzivat-clue-signaling-08] (41 pages) Requests for Comments: RFC7205: Use Cases for Telepresence Multistreams (17 pages) RFC7262: Requirements for Telepresence Multistreams (12 pages) Dispatch (dispatch) ------------------- Charter Last Modified: 2015-11-01 Current Status: Active Chairs: Cullen Jennings Mary Barnes Murray Kucherawy Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Ben Campbell Mailing Lists: General Discussion: dispatch@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dispatch Archive: https://mailarchive.ietf.org/arch/browse/dispatch/ Description of Working Group: The Dispatch working group is chartered to consider proposals for new work in the ART area and identify, or help create, an appropriate venue for the work. Guiding principles for the proposed new work include: 1. Providing a clear problem statement, motivation and deliverables for the proposed new work. 2. Ensuring there has been adequate mailing list discussion reflecting sufficient interest, individuals have expressed a willingness to contribute and there is WG consensus before new work is dispatched. 3. Looking for and identifying commonalities and overlap amongst published or ongoing protocol work. Such commonalities may indicate the possibility of reusing existing protocols or elements thereof published by other WGs, or expanding and/or refactoring the scope of deliverables in an active WG. 4. Protecting the architectural integrity of IETF protocols and ensuring that new work has general applicability. 5. Ensuring that the new work considers and seeks to improve security and privacy. Options for handling new work include: - Directing the work to an existing WG. - Developing a proposal for a BOF. - Developing a charter for a new WG. - Making recommendations that documents be AD-sponsored (which ADs may or may not choose to follow). - By agreement with ART ADs, processing simple administrative documents. - Deferring the decision for the new work. - Rejecting the new work. If the group decides that a particular topic needs to be addressed by a new WG, the normal IETF chartering process will be followed, including, for instance, IETF-wide review of the proposed charter. Proposals for large work efforts SHOULD lead to a BOF where the topic can be discussed in front of the entire IETF community. The DISPATCH WG will not do any protocol work. Specifically, DISPATCH will always opt to find a location for technical work; the only work that DISPATCH is not required to delegate (or defer, or reject) is administrative work such as IANA actions. Documents progressed as AD-sponsored would typically include those that do not have general applicability to IETF protocols, but rather are only applicable to specific use cases and network deployments, for which the scope must be clearly specified. Proposed new work may be deferred in cases where the WG does not have enough information for the chairs to determine consensus. New work may be rejected in cases where there is not sufficient WG interest or the proposal has been considered and rejected in the past, unless a substantially revised proposal is put forth, including compelling new reasons for accepting the work. A major objective of the DISPATCH WG is to provide timely, clear dispositions of new efforts. Thus, where there is consensus to take on new work, the WG will strive to quickly find a home for it. While most new work in the ART area is expected to be considered in the DISPATCH working group, there may be times where that is not appropriate. At the discretion of the area directors, new efforts may follow other paths. For example work may go directly to BoFs, may be initiated in other working groups when it clearly belongs in that group, or may be directly AD sponsored. Goals and Milestones: Apr 2018 - EMCAscript Media Type Updates to IESG for publication as Informational Internet-Drafts: - ECMAScript Media Types Updates [draft-ietf-dispatch-javascript-mjs-01] (21 pages) No Requests for Comments DKIM Crypto Update (dcrup) -------------------------- Charter Last Modified: 2017-04-28 Current Status: Active Chairs: Murray Kucherawy Rich Salz Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Alexey Melnikov Tech Advisor: Eric Rescorla Mailing Lists: General Discussion: dcrup@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dcrup Archive: https://mailarchive.ietf.org/arch/browse/dcrup/ Description of Working Group: The DKIM Crypto Update (DCRUP) Working Group is chartered to update DomainKeys Identified Mail (DKIM, RFC 6376) to handle more modern cryptographic algorithms and key sizes. DKIM (RFC 6376) signatures include a tag that identifies the hash algorithm and signing algorithm used in the signature. The only current algorithm is RSA, with advice that signing keys should be between 1024 and 2048 bits. While 1024 bit signatures are common, longer signatures are not because bugs in DNS provisioning software prevent publishing longer keys as DNS TXT records. DKIM also currently supports use of SHA1 coupled with RSA. SHA1 has been formally deprecated due to weakness in numerous contexts. The community wishes to discourage its continued use in the DKIM context. DCRUP will consider four types of changes to DKIM: additional signing algorithms such as those based on elliptic curves; changes to key strength advice and requirements; deprecating the use of SHA1; and new public key forms, such as putting the public key in the signature and a hash of the key in the DNS to bypass bugs in DNS provisioning software that prevent publishing longer keys as DNS TXT records. Changes will be limited to existing implemented algorithms and key forms. Other changes to DKIM, such as new message canonicalization schemes, are out of scope. The WG will as far as possible avoid changes incompatible with deployed DKIM signers and verifiers. Goals and Milestones: Oct 2017 - Agree what algorithms and key formats to add or deprecate Dec 2017 - Submit WG draft to IESG as Proposed Standard Internet-Drafts: - A new cryptographic signature method for DKIM [draft-ietf-dcrup-dkim-crypto-08] (6 pages) - Defining Elliptic Curve Cryptography Algorithms for use with DKIM [draft-ietf-dcrup-dkim-ecc-01] (7 pages) - Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM) [draft-ietf-dcrup-dkim-usage-06] (5 pages) Requests for Comments: RFC8301: Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM) (5 pages) * Updates RFC6376 DNS Over HTTPS (doh) -------------------- Charter Last Modified: 2017-09-29 Current Status: Active Chairs: Benjamin M. Schwartz David C Lawrence Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Adam Roach Tech Advisor: Warren Kumari Mailing Lists: General Discussion: doh@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/doh Archive: https://mailarchive.ietf.org/arch/browse/doh/ Description of Working Group: This working group will standardize encodings for DNS queries and responses that are suitable for use in HTTPS. This will enable the domain name system to function over certain paths where existing DNS methods (UDP, TLS [RFC 7857], and DTLS [RFC 8094]) experience problems. The working group will re-use HTTPS methods, error codes, and other semantics to the greatest extent possible. The use of HTTPS and its existing PKI provides integrity and confidentiality, and it also allows interoperation with common HTTPS infrastructure and policy. The primary focus of this working group is to develop a mechanism that provides confidentiality and connectivity between DNS clients (e.g., operating system stub resolvers) and recursive resolvers. While access to DNS-over-HTTPS servers from JavaScript running in a typical web browser is not the primary use case for this work, precluding the ability to do so would require additional preventative design. The working group will not engage in such preventative design. The working group will analyze the security and privacy issues that could arise from accessing DNS over HTTPS. In particular, the working group will consider the interaction of DNS and HTTP caching. The working group will coordinate with the DNSOP and INTAREA working groups for input on DNS-over-HTTPS's impact on DNS operations and DNS semantics, respectvely. In particular, DNSOP will be consulted for guidance on the operational impacts that result from traditional host behaviors (i.e., stub-resolver to recursive-resolver interaction) being replaced with the specified mechanism. Specification of how DNS-formatted data may be used for use cases beyond normal DNS queries is out of scope for the working group. The working group may define mechanisms for discovery of DOH servers similar to existing mechanisms for discovering other DNS servers if the chairs determine that there is both sufficient interest and working group consensus. The working group will use draft-hoffman-dispatch-dns-over-https as input. Goals and Milestones: Apr 2018 - Submit specification for performing DNS queries over HTTPS to the IESG for publication as PS Internet-Drafts: - DNS Queries over HTTPS [draft-ietf-doh-dns-over-https-03] (16 pages) No Requests for Comments Domain-based Message Authentication, Reporting & Conformance (dmarc) -------------------------------------------------------------------- Charter Last Modified: 2016-05-05 Current Status: Active Chairs: Barry Leiba Ned Freed Tim Draegen Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Alexey Melnikov Mailing Lists: General Discussion: dmarc@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dmarc Archive: https://mailarchive.ietf.org/arch/browse/dmarc/ Description of Working Group: Domain-based Message Authentication, Reporting & Conformance (DMARC) uses existing mail authentication technologies (SPF and DKIM) to extend validation to the RFC5322.From field. DMARC uses DNS records to add policy-related requests for receivers and defines a feedback mechanism from receivers back to domain owners. This allows a domain owner to advertise that mail can safely receive differential handling, such as rejection, when the use of the domain name in the From field is not authenticated. Existing deployment of DMARC has demonstrated utility at internet scale, in dealing with significant email abuse, and has permitted simplifying some mail handling processes. However, DMARC is problematic for mail that does not flow from operators having a relationship with the domain owner, directly to receivers operating the destination mailbox (for example, mailing lists, publish-to-friend functionality, mailbox forwarding via ".forward", and third-party services that send on behalf of clients). The working group will explore possible updates and extensions to the specifications in order to address limitations and/or add capabilities. It will also provide technical implementation guidance and review possible enhancements elsewhere in the mail handling sequence that could improve DMARC compatibility. The existing DMARC base specification has been submitted as an Independent Submission to become an Informational RFC. Specifications produced by the working group will ensure preservation of DMARC utility for detecting unauthorized use of domain names, while improving the identification of legitimate sources that do not currently conform to DMARC requirements. Issues based on operational experience and/or data aggregated from multiple sources will be given priority. The working group will seek to preserve interoperability with the installed base of DMARC systems, and provide detailed justification for any non-interoperability. As the working group develops solutions to deal with indirect mail flows, it will seek to maintain the end-to-end nature of existing identifier fields in mail, in particular avoiding solutions that require rewriting of originator fields. Working group activities will pursue three tracks: 1. Addressing the issues with indirect mail flows The working group will specify mechanisms for reducing or eliminating the DMARC's effects on indirect mail flows, including deployed behaviors of many different intermediaries, such as mailing list managers, automated mailbox forwarding services, and MTAs that perform enhanced message handling that results in message modification. Among the choices for addressing these issues are: - A form of DKIM signature that is better able to survive transit through intermediaries. - Collaborative or passive transitive mechanisms that enable an intermediary to participate in the trust sequence, propagating authentication directly or reporting its results. - Message modification by an intermediary, to avoid authentication failures, such as by using specified conventions for changing the aligned identity. Consideration also will be given to survivable authentication through sequences of multiple intermediaries. 2. Reviewing and improving the base DMARC specification The working group will not develop additional mail authentication technologies, but may document authentication requirements that are desirable. The base specification relies on the ability of an email receiver to determine the organizational domain responsible for sending mail. An organizational domain is the 'base' name that is allocated from a public registry; examples of registries include ".com" or ".co.uk". While the common practice is to use a "public suffix" list to determine organizational domain, it is widely recognized that this solution will not scale, and that the current list often is inaccurate. The task of defining a standard mechanism for identifying organizational domain is out of scope for this working group. However the working group can consider extending the base DMARC specification to accommodate such a standard, should it be developed during the life of this working group. Improvements in DMARC features (identifier alignment, reporting, policy preferences) will be considered, such as: - Enumeration of data elements required in "Failure" reports (specifically to address privacy issues) - Handling potential reporting abuse - Aggregate reporting to support additional reporting scenarios - Alternate reporting channels - Utility of arbitrary identifier alignment - Utility of a formalized policy exception mechanism 3. DMARC Usage The working group will document operational practices in terms of configuration, installation, monitoring, diagnosis and reporting. It will catalog currently prevailing guidelines as well as developing advice on practices that are not yet well-established but which are believed to be appropriate. The group will consider separating configuration and other deployment information that needs to be in the base spec, from information that should be in a separate guide. Among the topics anticipated to be included in the document are: - Identifier alignment configuration options - Implementation decisions regarding "pct" - Determining effective RUA sending frequency - Leveraging policy caching - Various options for integrating within an existing flow - Defining a useful, common set of options for the addresses to which feedback reports are to be sent - When and how to use local policy override options Work Items ---------- Phase I: Draft description of interoperability issues for indirect mail flows and plausible methods for reducing them. Phase II: Specification of DMARC improvements to support indirect mail flows Draft Guide on DMARC Usage Phase III: Review and refinement of the DMARC specification Completion of Guide on DMARC Usage References ---------- DMARC - http://dmarc.org SPF - RFC7208 Authentication-Results Header Field - RFC7001 DKIM - RFC6376 Internet Message Format - RFC5322 OAR / Original Authentication Results - draft-kucherawy-original-authres Using DMARC - draft-crocker-dmarc-bcp-03 Delegating DKIM Signing Authority - draft-kucherawy-dkim-delegate-00 DKIM Third-Party Authorization Label - draft-otis-dkim-tpa-label-03 Goals and Milestones: Done - Complete draft on DMARC interop issues + possible methods to address Oct 2016 - Complete Authenticated Received Chain (ARC) protocol spec Feb 2017 - Complete Authenticated Received Chain (ARC) usage recommendations Internet-Drafts: - Interoperability Issues Between DMARC and Indirect Email Flows [draft-dmarc-interoperability-00] (16 pages) - Using Multiple Signing Algorithms with the ARC (Authenticated Received Chain) Protocol [draft-ietf-dmarc-arc-multi-00] (8 pages) - Authenticated Received Chain (ARC) Protocol [draft-ietf-dmarc-arc-protocol-11] (54 pages) - Recommended Usage of the Authenticated Received Chain (ARC) [draft-ietf-dmarc-arc-usage-04] (16 pages) - Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows [draft-ietf-dmarc-interoperability-18] (27 pages) Requests for Comments: RFC7960: Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows (27 pages) Email mailstore and eXtensions To Revise or Amend (extra) --------------------------------------------------------- Charter Last Modified: 2017-11-14 Current Status: Active Chairs: Bron Gondwana Jiankang Yao Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Alexey Melnikov Mailing Lists: General Discussion: extra@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/extra Archive: https://mailarchive.ietf.org/arch/browse/extra/ Description of Working Group: The IETF maintains several key email related protocols that relate to message delivery to mailstores and mailstore access. These include the following: IMAP (RFC3501) SIEVE (RFC5228) ManageSieve (RFC5804) From time to time, there are bursts of work to do and the motivation and critical mass to do it. When such bursts coincide, it's important to give them a home. This working group provides such a venue. The WG will work on updates, extensions, and revisions to the above email protocols. Upon formation, the working group will consider any existing Internet Drafts that could be appropriate for its processing. While an interest poll for a new related idea is fine, the WG should avoid detailed discussion of work items lacking an Internet-Draft. The working group will start with processing the backlog of IMAP/Sieve extensions. Once this is done it will continue processing submitted IMAP/Sieve extensions, as well as work on a revision of IMAP (RFC 3501). Work on updating this RFC will include appropriate corrections, clarifications, or amplifications to reflect existing practice or to address problems that have been identified through experience with IMAP as currently specified. Also eligible for consideration is the incorporation of accumulated errata or consolidation with newer documents that have updated and/or extended the base specification. However, any new functionality is expected to be pursued via extensions rather than changes to the base protocol wherever possible. If there is interest in revising SIEVE (RFC5228) and ManageSieve (RFC5804), the WG will recharter. Expressly excluded from this charter is work on any protocol for which a dedicated working group already exists, such as DMARC, DCRUP or JMAP, as well as any work on POP3, SMTP/LMTP and email format/MIME. However, each working group should endeavor to remain aware of the activities of the other and collaborate as needed. Goals and Milestones: Sep 2017 - Submit "Sieve Email Filtering: Delivering to Special-Use Mailboxes" to IESG as a Proposed Standard Oct 2017 - Submit "IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST" to IESG as a Proposed Standard Dec 2017 - Submit "64bit body part and message sizes in IMAP4" to IESG as a Proposed Standard Internet-Drafts: - Internet Message Access Protocol (IMAP) - SAVEDATE Extension [draft-bosch-imap-savedate-00] (6 pages) - Internet Message Access Protocol (IMAP) - STATUS=SIZE Extension [draft-bosch-imap-status-size-00] (5 pages) - 64bit body part and message sizes in IMAP4 [draft-ietf-extra-imap-64bit-02] (7 pages) - IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST [draft-ietf-extra-imap-list-myrights-01] (6 pages) - Sieve Extension: File Carbon Copy (Fcc) [draft-ietf-extra-sieve-fcc-01] (8 pages) - Sieve Email Filtering: Delivering to Special-Use Mailboxes [draft-ietf-extra-sieve-special-use-01] (8 pages) No Requests for Comments Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- Charter Last Modified: 2017-03-29 Current Status: Active Chairs: Allison Mankin Roger Marshall Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Adam Roach Mailing Lists: General Discussion: ecrit@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ecrit Archive: https://mailarchive.ietf.org/arch/browse/ecrit/ Description of Working Group: In a number of areas, the public switched telephone network (PSTN) has been configured to recognize an explicitly specified number (usually one that is short and easily memorized) as a request for emergency services. These numbers (e.g., 911, 112) are related to an emergency service context and depend on a broad, regional configuration of service contact methods and a geographically-constrained approach for service delivery. These calls are intended to be delivered to special call centers equipped to manage emergency response. Successful delivery of an emergency service call within those systems requires an association of both the physical location of the originating device along with appropriate call routing to an emergency service center. Calls placed using Internet technologies do not use the same systems mentioned above to achieve those same goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting these goals even more challenging. There are, however, Internet technologies available to manage location and to perform call routing. This working group has described where and how these mechanisms may be used. The group specified how location data and call routing information are used to enable communication between a user and a relevant emergency response center [RFC6443,RFC6444]. Though the term "call routing" is used, it should be understood that some of the mechanisms described might be used to enable other types of media streams. Beyond human initiated emergency call request mechanisms, this group will develop new methods to enable non-human-initiated requests for emergency assistance, such as sensor initiated emergency requests. The working group will also address topics required for the operation of emergency calling systems, such as: authentication of location, management of the service URN namespace, augmented information that could assist emergency call takers or responders. Explicitly outside the scope of this group is the question of pre- emption or prioritization of emergency services traffic in the network. This group is considering emergency services calls which might be made by any user of the Internet, as opposed to government or military services that may impose very different authentication and routing requirements. While this group anticipates a close working relationship with groups such as NENA, EENA, 3GPP, and ETSI , any solution presented must be general enough to be potentially useful in or across multiple regions or jurisdictions, and it must be possible to use without requiring a single, central authority. Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, things such as call routing for specific emergency types, media types, language contents, etc., may be routed differently depending on established policies and availability. This working group will address privacy and security concerns within its documents. Goals and Milestones: Done - Informational RFC containing terminology definitions and the requirements Done - An Informational document describing the threats and security considerations Done - A Standards Track RFC describing how to identify a session set-up request is to an emergency response center Done - A Standards Track RFC describing how to route an emergency call based on location information Done - An Informational document describing the Mapping Protocol Architecture Done - Submit 'Location Hiding: Problem Statement and Requirements' to the IESG for consideration as an Informational RFC. Done - Submit 'Framework for Emergency Calling using Internet Multimedia' to the IESG for consideration as an Informational RFC. Done - Submit 'Best Current Practice for Communications Services in support of Emergency Calling' to the IESG for consideration as a BCP document Done - Submit 'LoST Extension for returning Boundary Information for Services' to the IESG for consideration as an Experimental RFC Done - Submit 'Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements' to the IESG for consideration as an Experimental RFC Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG for consideration as an Informational RFC Done - Submit 'Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices' to the IESG for consideration as a Standards Track RFC Done - Submit 'Trustworthy Location Information' to the IESG for consideration as an Informational RFC Done - Submit a draft 'URN For Country Specific Emergency Services' to the IESG for consideration as a Standards Track RFC Done - Submit 'Additional Data related to a Call for Emergency Call Purposes' to the IESG for consideration as a Standards Track RFC Done - Submit 'A Routing Request Extension for the HELD Protocol' to the IESG for consideration as a Standards Track RFC Done - Submit ‘Internet Protocol-based In-Vehicle Emergency Calls‘ to the IESG for consideration as an Informational RFC Done - Submit ‘Next-Generation Pan-European eCall‘ to the IESG for consideration as an Informational RFC Aug 2017 - Submit 'Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG for consideration as an Experimental RFC Aug 2017 - Submit ‘A LoST extension to return complete and similar location info‘ to the IESG for consideration as an Informational RFC Aug 2017 - Submit 'Validation of Locations Around a Planned Change' to the IESG for consideration as a Standards Track RFC Internet-Drafts: - Validation of Locations Around a Planned Change [draft-ecrit-lost-planned-changes-00] (10 pages) - Additional Data Related to an Emergency Call [draft-ietf-ecrit-additional-data-38] (113 pages) - Next-Generation Vehicle-Initiated Emergency Calls [draft-ietf-ecrit-car-crash-23] (40 pages) - URN for Country-Specific Emergency Services [draft-ietf-ecrit-country-emg-urn-03] (4 pages) - Data-Only Emergency Calls [draft-ietf-ecrit-data-only-ea-14] (22 pages) - Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP) [draft-ietf-ecrit-dhc-lost-discovery-03] (8 pages) - Next-Generation Pan-European eCall [draft-ietf-ecrit-ecall-27] (43 pages) - Framework for Emergency Calling Using Internet Multimedia [draft-ietf-ecrit-framework-13] (38 pages) - A Routing Request Extension for the HTTP-Enabled Location Delivery (HELD) Protocol [draft-ietf-ecrit-held-routing-05] (16 pages) - IANA Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications [draft-ietf-ecrit-local-emergency-rph-namespace-04] (8 pages) - Location Hiding: Problem Statement and Requirements [draft-ietf-ecrit-location-hiding-req-04] (9 pages) - LoST: A Location-to-Service Translation Protocol [draft-ietf-ecrit-lost-10] (69 pages) - Validation of Locations Around a Planned Change [draft-ietf-ecrit-lost-planned-changes-00] (10 pages) - Location-to-Service Translation (LoST) Service List Boundary Extension [draft-ietf-ecrit-lost-servicelistboundary-05] (15 pages) - Synchronizing Service Boundaries and Elements Based on the Location-to-Service Translation (LoST) Protocol [draft-ietf-ecrit-lost-sync-18] (25 pages) - Location-to-URL Mapping Architecture and Framework [draft-ietf-ecrit-mapping-arch-04] (17 pages) - Best Current Practice for Communications Services in Support of Emergency Calling [draft-ietf-ecrit-phonebcp-20] (28 pages) - Public Safety Answering Point (PSAP) Callback [draft-ietf-ecrit-psap-callback-13] (18 pages) - Requirements for Emergency Context Resolution with Internet Technologies [draft-ietf-ecrit-requirements-13] (23 pages) - Using Imprecise Location for Emergency Context Resolution [draft-ietf-ecrit-rough-loc-05] (19 pages) - Security Threats and Requirements for Emergency Call Marking and Mapping [draft-ietf-ecrit-security-threats-05] (12 pages) - A Uniform Resource Name (URN) for Emergency and Other Well-Known Services [draft-ietf-ecrit-service-urn-07] (14 pages) - Policy for defining new service-identifying labels [draft-ietf-ecrit-service-urn-policy-04] (4 pages) - A LoST extension to return complete and similar location info [draft-ietf-ecrit-similar-location-04] (17 pages) - Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries [draft-ietf-ecrit-specifying-holes-03] (11 pages) - Trustworthy Location [draft-ietf-ecrit-trustworthy-location-14] (31 pages) - Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices [draft-ietf-ecrit-unauthenticated-access-10] (25 pages) Requests for Comments: BCP181: Best Current Practice for Communications Services in Support of Emergency Calling (28 pages) RFC5012: Requirements for Emergency Context Resolution with Internet Technologies (23 pages) RFC5031: A Uniform Resource Name (URN) for Emergency and Other Well-Known Services (14 pages) * Updates RFC7163 RFC5069: Security Threats and Requirements for Emergency Call Marking and Mapping (12 pages) RFC5222: LoST: A Location-to-Service Translation Protocol (69 pages) * Updates RFC6848 RFC5223: Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP) (8 pages) RFC5582: Location-to-URL Mapping Architecture and Framework (17 pages) RFC5964: Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries (11 pages) RFC6197: Location-to-Service Translation (LoST) Service List Boundary Extension (15 pages) RFC6443: Framework for Emergency Calling Using Internet Multimedia (38 pages) * Updates RFC7852 RFC6444: Location Hiding: Problem Statement and Requirements (9 pages) RFC6739: Synchronizing Service Boundaries and Elements Based on the Location-to-Service Translation (LoST) Protocol (25 pages) RFC6881: Best Current Practice for Communications Services in Support of Emergency Calling (28 pages) * Updates RFC7840 * Updates RFC7852 RFC7090: Public Safety Answering Point (PSAP) Callback (18 pages) RFC7163: URN for Country-Specific Emergency Services (4 pages) * Updates RFC5031 RFC7378: Trustworthy Location (31 pages) RFC7406: Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices (25 pages) RFC7840: A Routing Request Extension for the HTTP-Enabled Location Delivery (HELD) Protocol (16 pages) * Updates RFC5985 * Updates RFC6881 RFC7852: Additional Data Related to an Emergency Call (113 pages) * Updates RFC6443 * Updates RFC6881 RFC8147: Next-Generation Pan-European eCall (43 pages) RFC8148: Next-Generation Vehicle-Initiated Emergency Calls (40 pages) Hypertext Transfer Protocol (httpbis) ------------------------------------- Charter Last Modified: 2017-02-06 Current Status: Active Chairs: Mark Nottingham Patrick McManus Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Alexey Melnikov Tech Advisor: Allison Mankin Mailing Lists: General Discussion: ietf-http-wg@w3.org To Subscribe: ietf-http-wg-request@w3.org Archive: http://lists.w3.org/Archives/Public/ietf-http-wg/ Description of Working Group: This Working Group is charged with maintaining and developing the "core" specifications for HTTP. The Working Group's specification deliverables are: * A document (or set of documents) that is suitable to supersede RFC 2616 as the definition of HTTP/1.1 and move RFC 2817 to Historic status * A document cataloguing the security properties of HTTP/1.1 * A document (or set of documents) that specifies HTTP/2.0, an improved binding of HTTP's semantics to an underlying transport. HTTP/1.1 -------- HTTP/1.1 is one of the most successful and widely-used protocols on the Internet today. However, its specification has several editorial issues. Additionally, after years of implementation and extension, several ambiguities have become evident, impairing interoperability and the ability to easily implement and use HTTP. The working group will refine RFC2616 to: * Incorporate errata and updates (e.g., references, IANA registries, ABNF) * Fix editorial problems which have led to misunderstandings of the specification * Clarify conformance requirements * Remove known ambiguities where they affect interoperability * Clarify existing methods of extensibility * Remove or deprecate those features that are not widely implemented and also unduly affect interoperability * Where necessary, add implementation advice * Document the security properties of HTTP and its associated mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications It will also incorporate the generic authentication framework from RFC 2617, without obsoleting or updating that specification's definition of the Basic and Digest schemes. Finally, it will incorporate relevant portions of RFC 2817 (in particular, the CONNECT method and advice on the use of Upgrade), so that that specification can be moved to Historic status. In doing so, it should consider: * Implementer experience * Demonstrated use of HTTP * Impact on existing implementations and deployments HTTP/2.0 -------- There is emerging implementation experience and interest in a protocol that retains the semantics of HTTP without the legacy of HTTP/1.x message framing and syntax, which have been identified as hampering performance and encouraging misuse of the underlying transport. The Working Group will produce a specification of a new expression of HTTP's current semantics in ordered, bi-directional streams. As with HTTP/1.x, the primary target transport is TCP, but it should be possible to use other transports. Work will begin using draft-mbelshe-httpbis-spdy-00 as a starting point; proposals are to be expressed in terms of changes to that document. Note that consensus is required both for changes to the document and anything that remains in the document. In particular, because something is in the initial document does not imply that there is consensus around the feature or how it is specified. The deliverable of the WG is HTTP/2.0, and there is no consideration of preserving backwards compatibility with the initial starting point. As part of the HTTP/2.0 work, the following issues are explicitly called out for consideration: * A negotiation mechanism that is capable of not only choosing between HTTP/1.x and HTTP/2.x, but also for bindings of HTTP URLs to other transports (for example). * Header compression (which may encompass header encoding or tokenisation) * Server push (which may encompass pull or other techniques) It is expected that HTTP/2.0 will: * Substantially and measurably improve end-user perceived latency in most cases, over HTTP/1.1 using TCP. * Address the "head of line blocking" problem in HTTP. * Not require multiple connections to a server to enable parallelism, thus improving its use of TCP, especially regarding congestion control. * Retain the semantics of HTTP/1.1, leveraging existing documentation (see above), including (but not limited to) HTTP methods, status codes, URIs, and where appropriate, header fields. * Clearly define how HTTP/2.0 interacts with HTTP/1.x, especially in intermediaries (both 2->1 and 1->2). * Clearly identify any new extensibility points and policy for their appropriate use. The resulting specification(s) are expected to meet these goals for common existing deployments of HTTP; in particular, Web browsing (desktop and mobile), non-browsers ("HTTP APIs"), Web serving (at a variety of scales), and intermediation (by proxies, corporate firewalls, "reverse" proxies and Content Delivery Networks). Likewise, current and future semantic extensions to HTTP/1.x (e.g., headers, methods, status codes, cache directives) should be supported in the new protocol. Note that this does not include uses of HTTP where non-specified behaviours are relied upon (e.g., connection state such as timeouts or client affinity, and "interception" proxies); these uses may or may not be enabled by the final product. Explicitly out-of-scope items include: * Specifying the use of alternate transport-layer protocols. Note that it is expected that the Working Group will work with the TLS working group to define how the protocol is used with the TLS Protocol; any revisions to RFC 2818 will be done in the TLS working group. * Specifying how the HTTP protocol is to be used or presented in a specific use case (e.g., in Web browsers). The Working Group will coordinate this item with: * The TLS Working Group, regarding use of TLS. * The Transport Area, regarding impact on and interaction with transport protocols. * The HYBI Working Group, regarding the possible future extension of HTTP/2.0 to carry WebSockets semantics. The Working Group will give priority to HTTP/1.1 work until that work is complete. Other HTTP-Related Work ----------------------- The Working Group may define additional extensions to HTTP as work items, provided that: * The Working Group Chairs judge that there is consensus to take on the item and believe that it will not interfere with the work described above, and * The Area Directors approve the addition and add corresponding milestones. Additionally, the Working Group will not start work on any extensions that are specific to HTTP/2.0 until the HTTP/2.0 work is completed. Goals and Milestones: Done - First HTTP/1.1 Revision Internet Draft Done - First HTTP Security Properties Internet Draft Done - Call for Proposals for HTTP/2.0 Done - Working Group Last Call for HTTP/1.1 Revision Done - First WG draft of HTTP/2.0, based upon draft-mbelshe-httpbis-spdy-00 Held / eliminated - Working Group Last Call for HTTP Security Properties Done - Submit HTTP/1.1 Revision to IESG for consideration as a Proposed Standard Done - Working Group Last call for HTTP/2.0 Done - Submit HTTP/2.0 to IESG for consideration as a Proposed Standard Done - Submit The Hypertext Transfer Protocol Status Code 308 to IESG for consideration as Internet Standard Done - Submit HTTP Client-Initiated Content-Encoding to IESG for consideration as Proposed Standard Done - Submit Tunnel Protocol for CONNECT to IESG for consideration as Proposed Standard Done - Submit HTTP Authentication-Info and Proxy-Authentication-Info to IESG for consideration as Proposed Standard Done - Submit HTTP Legally Restricted Status Code to IESG for consideration as a Proposed Standard Done - Submit Alternative Services to IESG for consideration as a Proposed Standard Done - Submit HTTP Opportunistic Security to IESG for consideration as Experimental Done - Submit Character Encoding and Language for Parameters to IESG for consideration as Internet Standard May 2016 - Submit the Key HTTP Response Header Field for consideration as a Proposed Standard Internet-Drafts: - Secondary Certificate Authentication in HTTP/2 [draft-bishop-httpbis-http2-additional-certs-05] (21 pages) - The Key HTTP Response Header Field [draft-fielding-http-key-03] (17 pages) - HTTP Client Hints [draft-grigorik-http-client-hints-03] (11 pages) - HTTP Alternative Services [draft-ietf-httpbis-alt-svc-14] (20 pages) - HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields [draft-ietf-httpbis-auth-info-05] (6 pages) - Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations [draft-ietf-httpbis-authscheme-registrations-10] (3 pages) - On the use of HTTP as a Substrate [draft-ietf-httpbis-bcp56bis-00] (17 pages) - Cache Digests for HTTP/2 [draft-ietf-httpbis-cache-digest-02] (13 pages) - Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding [draft-ietf-httpbis-cice-03] (7 pages) - HTTP Client Hints [draft-ietf-httpbis-client-hints-05] (14 pages) - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) [draft-ietf-httpbis-content-disp-09] (14 pages) - Deprecate modification of 'secure' cookies from non-secure origins [draft-ietf-httpbis-cookie-alone-01] (6 pages) - Cookie Prefixes [draft-ietf-httpbis-cookie-prefixes-00] (6 pages) - Same-Site Cookies [draft-ietf-httpbis-cookie-same-site-00] (14 pages) - An HTTP Status Code for Indicating Hints [draft-ietf-httpbis-early-hints-05] (7 pages) - Encrypted Content-Encoding for HTTP [draft-ietf-httpbis-encryption-encoding-09] (16 pages) - Expect-CT Extension for HTTP [draft-ietf-httpbis-expect-ct-02] (18 pages) - Bootstrapping WebSockets with HTTP/2 [draft-ietf-httpbis-h2-websockets-00] (7 pages) - HPACK: Header Compression for HTTP/2 [draft-ietf-httpbis-header-compression-12] (55 pages) - Structured Headers for HTTP [draft-ietf-httpbis-header-structure-03] (18 pages) - Hypertext Transfer Protocol Version 2 (HTTP/2) [draft-ietf-httpbis-http2-17] (96 pages) - Opportunistic Security for HTTP/2 [draft-ietf-httpbis-http2-encryption-11] (10 pages) - Secondary Certificate Authentication in HTTP/2 [draft-ietf-httpbis-http2-secondary-certs-00] (21 pages) - HTTP Immutable Responses [draft-ietf-httpbis-immutable-03] (6 pages) - A JSON Encoding for HTTP Header Field Values [draft-ietf-httpbis-jfv-02] (13 pages) - The Key HTTP Response Header Field [draft-ietf-httpbis-key-01] (17 pages) - An HTTP Status Code to Report Legal Obstacles [draft-ietf-httpbis-legally-restricted-status-04] (5 pages) - Initial Hypertext Transfer Protocol (HTTP) Method Registrations [draft-ietf-httpbis-method-registrations-15] (5 pages) - The ORIGIN HTTP/2 Frame [draft-ietf-httpbis-origin-frame-06] (10 pages) - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing [draft-ietf-httpbis-p1-messaging-26] (89 pages) - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content [draft-ietf-httpbis-p2-semantics-26] (101 pages) - HTTP/1.1, part 3: Message Payload and Content Negotiation [draft-ietf-httpbis-p3-payload-20] (3 pages) - Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests [draft-ietf-httpbis-p4-conditional-26] (28 pages) - Hypertext Transfer Protocol (HTTP/1.1): Range Requests [draft-ietf-httpbis-p5-range-26] (25 pages) - Hypertext Transfer Protocol (HTTP/1.1): Caching [draft-ietf-httpbis-p6-cache-26] (43 pages) - Hypertext Transfer Protocol (HTTP/1.1): Authentication [draft-ietf-httpbis-p7-auth-26] (19 pages) - HTTP Random Access and Live Content [draft-ietf-httpbis-rand-access-live-02] (10 pages) - Using Early Data in HTTP [draft-ietf-httpbis-replay-02] (11 pages) - Indicating Character Encoding and Language for HTTP Header Field Parameters [draft-ietf-httpbis-rfc5987bis-05] (13 pages) - Cookies: HTTP State Management Mechanism [draft-ietf-httpbis-rfc6265bis-02] (48 pages) - The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) [draft-ietf-httpbis-rfc7238bis-03] (6 pages) - Security Requirements for HTTP [draft-ietf-httpbis-security-properties-05] (14 pages) - The ALPN HTTP Header Field [draft-ietf-httpbis-tunnel-protocol-05] (7 pages) - Bootstrapping WebSockets with HTTP/2 [draft-mcmanus-httpbis-h2-websockets-02] (7 pages) - The ORIGIN HTTP/2 Frame [draft-nottingham-httpbis-origin-frame-01] (4 pages) - Reactive Certificate-Based Client Authentication in HTTP/2 [draft-thomson-http2-client-certs-02] (19 pages) - Same-site Cookies [draft-west-first-party-cookies-07] (14 pages) Requests for Comments: RFC6266: Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) (14 pages) * Updates RFC2616 RFC7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing (89 pages) * Updates RFC2818 * Updates RFC2817 * Obsoletes RFC2616 * Obsoletes RFC2145 RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content (101 pages) * Updates RFC2817 * Obsoletes RFC2616 RFC7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests (28 pages) * Obsoletes RFC2616 RFC7233: Hypertext Transfer Protocol (HTTP/1.1): Range Requests (25 pages) * Obsoletes RFC2616 RFC7234: Hypertext Transfer Protocol (HTTP/1.1): Caching (43 pages) * Obsoletes RFC2616 RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication (19 pages) * Updates RFC2617 * Obsoletes RFC2616 * Obsoletes RFC2617 RFC7236: Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations (3 pages) RFC7237: Initial Hypertext Transfer Protocol (HTTP) Method Registrations (5 pages) RFC7538: The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) (6 pages) * Obsoletes RFC7238 RFC7540: Hypertext Transfer Protocol Version 2 (HTTP/2) (96 pages) RFC7541: HPACK: Header Compression for HTTP/2 (55 pages) RFC7615: HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields (6 pages) * Obsoletes RFC2617 RFC7639: The ALPN HTTP Header Field (7 pages) RFC7694: Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding (7 pages) RFC7725: An HTTP Status Code to Report Legal Obstacles (5 pages) RFC7838: HTTP Alternative Services (20 pages) RFC8164: Opportunistic Security for HTTP/2 (10 pages) RFC8187: Indicating Character Encoding and Language for HTTP Header Field Parameters (13 pages) * Obsoletes RFC5987 RFC8188: Encrypted Content-Encoding for HTTP (16 pages) RFC8246: HTTP Immutable Responses (6 pages) RFC8297: An HTTP Status Code for Indicating Hints (7 pages) Interactive Connectivity Establishment (ice) -------------------------------------------- Charter Last Modified: 2015-10-20 Current Status: Active Chairs: Ari Keränen Peter Thatcher Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Ben Campbell Tech Advisor: Martin Stiemerling Mailing Lists: General Discussion: ice@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ice Archive: https://mailarchive.ietf.org/arch/browse/ice/ Description of Working Group: Interactive Connectivity Establishment (ICE) is at the same time a NAT traversal technique, a multihomed address selection technique, and a dual stack address selection technique that works by including multiple IP addresses and ports in both the request and response messages of a connectivity establishment transaction. It makes no assumptions regarding network topology on the local or remote side. Interactive Connectivity Establishment was published as RFC 5245 in April 2010. Until recently the protocol had seen rather limited deployment. This situation has changed drastically as ICE is mandatory to implement in WebRTC, a set of technologies developed at the IETF and W3C to standardize Real Time Communication on the Web. ICE was originally defined for the Offer-Answer (RFC 3264) protocol used by SIP (RFC 3261). Later XMPP (XEP-0176), RTSP (draft-ietf-mmusic-rtsp-nat), RTCWeb (draft-ietf-rtcweb-jsep) and other realtime media establishment protocols have used the protocol. ICE is also used by non-realtime media protocols, like HIP (RFC 5770) and RELOAD (RFC 6940). The goal of the ICE Working Group is to consolidate the various initiatives to update and improve ICE, and to help ensure suitability and consistency in the environments ICE operates in. Current work in this area includes an updated version of the ICE RFC (ICEbis), Trickle ICE and dualstack/multihomed fairness. This work will make ICE more flexible, robust and more suitable for changing mobile environments without major changes to the original ICE RFC. The ICE workgroup will consider new work items that follow this pattern. The core ICE work will offer guidance to help minimize the unintentional exposure of IP addresses. ICE is an application controlled protocol that leverages a set of network defined protocols. The STUN (RFC 5389), TURN (RFC 5766) and related protocol work done in the TRAM working group must be closely synchronized with the work in this working group. To avoid interoperability issues and unwanted behavior it is desired to increase the interaction with other working groups dealing with network protocols closer to the wire. Example of such work may be, but not limited to: issues regarding multi-homing, multi subnet and prefixes, QoS, transport selection and congestion control. From the application side, the users of ICE, there is a need to make sure what is specified is actually usable. Getting input from the application working groups will be helpful (RTCWEB, HIP, MMUSIC, P2PSIP). Goals and Milestones: Done - Submit Dual-stack Fairness with ICE as Proposed Standard Dec 2016 - Submit a revision of ICE (RFC 5245) as Proposed Standard (draft-ietf-mmusic-ice-sip-sdp remains in MMUSIC) Jan 2017 - Submit Trickle ICE as Proposed Standard (draft-ietf-mmusic-trickle-ice-sip remains in MMUSIC) Internet-Drafts: - ICE Multihomed and IPv4/IPv6 Dual Stack Guidelines [draft-ietf-ice-dualstack-fairness-07] (10 pages) - Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal [draft-ietf-ice-rfc5245bis-17] (95 pages) - Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol [draft-ietf-ice-trickle-16] (32 pages) No Requests for Comments INtermediary-safe SIP session ID (insipid) ------------------------------------------ Charter Last Modified: 2017-08-01 Current Status: Active Chairs: Gonzalo Salgueiro Keith Drage Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Ben Campbell Mailing Lists: General Discussion: insipid@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/insipid Archive: https://mailarchive.ietf.org/arch/browse/insipid/ Description of Working Group: An end-to-end session identifier in SIP-based multimedia communication networks refers to the ability for endpoints, intermediate devices, and management and monitoring system to identify and correlate SIP messages and dialogs of the same higher-level end-to-end "communication session" across multiple SIP devices, hops, and administrative domains. Unfortunately, there are a number of factors that contribute to the fact that the current dialog identifiers defined in SIP are not suitable for end-to-end session identification. Perhaps the most important factor worth describing is that in real-world deployments of Back-to-Back User Agents (B2BUAs) devices like Session Border Controllers (SBC) often change the call identifiers (e.g., the From-tag and To-tag that are used in conjunction with the Call-ID header to make the dialog-id) as the session signaling passes through. An end-to-end session identifier should allow the possibility to identify the communication session from the point of origin, passing through any number of intermediaries, to the ultimate point of termination. It should have the same aim as the From-tag, To-tag and Call-ID conjunction, but should not be mangled by intermediaries. A SIP end-to-end session identifier has been considered as possible solution of different use cases like troubleshooting, billing, session recording, media and signaling correlation, and so forth. Some of these requirements come from other working groups within the RAI area (e.g., SIPRec). Moreover, other standards organizations have identified the need for SIP and H.323 to carry the same "session ID" value so that it is possible to identify a call end-to-end even when performing inter working between protocols. Troubleshooting SIP signalling end-to-end becomes impractical as networks grow and become interconnected, including connection via transit networks, because the path that SIP signalling will take between clients cannot be predicted and the signalling volume and geographical spread are too large. This group will focus on two documents: The first document will specify a SIP identifier that has the same aim as the From-tag, To-tag and Call-ID conjunction, but is less likely to be mangled by intermediaries. In doing this work, the group will pay attention to the privacy implications of a "session ID", for example considering the possibility to make it intractable for nodes to correlate "session IDs" generated by the same user for different sessions. The second document will define an indicator that can be added to the SIP protocol to indicate that signalling should be logged. The indicator will typically be applied as part of network testing controlled by the network operator and not used in regular client signalling. However, such marking can be carried end-to-end including the SIP terminals, even if a session originates and terminates in different networks. Goals and Milestones: Done - Requirements and use cases for new identifier sent to IESG (Informational) Done - Requirements for marking SIP sessions for logging to IESG (Informational) Done - Specification of the new identifier sent to the IESG (Proposed Standard) Jun 2017 - Protocol for marking SIP sessions for logging to IESG (Proposed Standard) Internet-Drafts: - Marking SIP Messages to be Logged [draft-ietf-insipid-logme-marking-09] (37 pages) - Requirements for Marking SIP Messages to be Logged [draft-ietf-insipid-logme-reqs-12] (11 pages) - End-to-End Session Identification in IP-Based Multimedia Communication Networks [draft-ietf-insipid-session-id-27] (45 pages) - Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks [draft-ietf-insipid-session-id-reqts-11] (15 pages) Requests for Comments: RFC7206: Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks (15 pages) RFC7989: End-to-End Session Identification in IP-Based Multimedia Communication Networks (45 pages) * Obsoletes RFC7329 RFC8123: Requirements for Marking SIP Messages to be Logged (11 pages) Internet Video Codec (netvc) ---------------------------- Charter Last Modified: 2017-03-29 Current Status: Active Chairs: Mo Zanaty Natasha Rooney Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Adam Roach Mailing Lists: General Discussion: video-codec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/video-codec Archive: https://mailarchive.ietf.org/arch/browse/video-codec/ Description of Working Group: Objectives This WG is chartered to produce a high-quality video codec that meets the following conditions: 1. Is competitive (in the sense of having comparable or better performance) with current video codecs in widespread use. 2. Is optimized for use in interactive web applications. 3. Is viewed as having IPR licensing terms that allow it to be widely implemented and deployed. To elaborate, this video codec will need to be commercially interesting to implement by being competitive with the video codecs in widespread use at the time it is finalized. This video codec will need to be optimized for the real-world conditions of the public, best-effort Internet. It should include, but may not be limited to, the ability to support fast and flexible congestion control and rate adaptation, the ability to quickly join broadcast streams and the ability to be optimized for captures of content typically shared in interactive communications. The objective is to produce a video codec that can be implemented, distributed, and deployed by open source and closed source software as well as implemented in specialized hardware. The working group shall heed the preference stated in BCP 79: "In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing." In keeping with this BCP, the WG will prefer algorithms or tools where there are verifiable reasons to believe they are available on an royalty-free (RF) basis. In developing the codec specification, the WG may consider information concerning old prior art or the results of research indicating royalty-free availability of particular techniques. Note that the preference stated in BCP 79 cannot guarantee that the working group will produce an IPR unencumbered codec. Process The core technical considerations for such a codec include, but are not necessarily limited to, the following: 1. High compression efficiency that is competitive with existing popular video codecs. 2. Reasonable computational complexity that permits real-time operation on existing, popular hardware, including mobile devices, and efficient implementation in new hardware designs. 3. Use in interactive real-time applications, such as point-to-point video calls, multi-party video conferencing, telepresence, teleoperation, and in-game video chat. 4. Resilient in the real-world transport conditions of the Internet, such as the flexibility to rapidly respond to changing bandwidth availability and loss rates, etc. 5. Integratable with common Internet applications and Web APIs (e.g., the HTML5