Protocol Action: 'RTP Control Protocol (RTCP) Feedback for Congestion Control' to Proposed Standard (draft-ietf-avtcore-cc-feedback-message-09.txt)
The IESG has approved the following document: - 'RTP Control Protocol (RTCP) Feedback for Congestion Control' (draft-ietf-avtcore-cc-feedback-message-09.txt) as Proposed Standard This document is the product of the Audio/Video Transport Core Maintenance Working Group. The IESG contact persons are Murray Kucherawy and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-cc-feedback-message/ Technical Summary: This document describes an RTCP feedback message intended to enable congestion control for interactive real-time traffic using RTP. The feedback message is designed for use with a sender-based congestion control algorithm, in which the receiver of an RTP flow sends RTCP feedback packets to the sender containing the information the sender needs to perform congestion control. Working Group Summary: The document was reviewed by the WG and went through WG last call and had the WG consensus Document Quality: The feedback message was tested in a recent Hackathon and is used for the RMCAT WG work. Sergio Mena, Nils Olhmeier and Jonathan Lennox had interop implementations at the Hackathon. Ingemar Johansson also provided good feedback. Personnel: Bernard Aboba is the document shepherd. Barry Leiba is the responsible AD. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Sieve Email Filtering: delivery by mailboxid) to Proposed Standard
The IESG has received a request from the Email mailstore and eXtensions To Revise or Amend WG (extra) to consider the following document: - 'Sieve Email Filtering: delivery by mailboxid' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-12-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The OBJECTID capability of the IMAP protocol (RFC8474) allows clients to identify mailboxes by a unique identifier which survives rename. This document extends the Sieve mail filtering language (RFC5228) to allow using that same unique identifier as a target for fileinto rules, and for testing the existance of mailboxes. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-mailboxid/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Uniform Resource Names for Device Identifiers) to Proposed Standard
The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'Uniform Resource Names for Device Identifiers' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-12-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a new Uniform Resource Name (URN) namespace for hardware device identifiers. A general representation of device identity can be useful in many applications, such as in sensor data streams and storage, or equipment inventories. A URN-based representation can be easily passed along in any application that needs the information. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-dev-urn/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (CoAP: Echo, Request-Tag, and Token Processing) to Proposed Standard
The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'CoAP: Echo, Request-Tag, and Token Processing' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-12-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. This document updates RFC7252 with respect to the client Token processing requirements, forbidding non-secure reuse of Tokens to ensure binding of response to request when CoAP is used with a security protocol, and with respect to amplification mitigation, where the use of Echo is now recommended. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Interface to Network Security Functions (i2nsf) WG Virtual Meeting: 2020-12-03
The Interface to Network Security Functions (i2nsf) WG will hold a virtual interim meeting on 2020-12-03 from 14:00 to 15:30 UTC. Agenda: The purpose of this meeting is to discuss a possible re-chartering of the I2NSF working group. We aim to see if the proposed charter text: (1) makes sense (2) can get consensus (3) has enough people who are willing to do work. Proposed text is at https://mailarchive.ietf.org/arch/msg/i2nsf/rn1F7BSqqEzI15ApV2c0UHjmbz8/ More information will be sent to the list before the meeting. Information about remote participation: https://dell.zoom.us/j/97095207458?pwd=RHpTUWpMVE42VFkzV1RWd0F5ZXRxZz09 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'IMAP4 Extension: Message Preview Generation' to Proposed Standard (draft-ietf-extra-imap-fetch-preview-10.txt)
The IESG has approved the following document: - 'IMAP4 Extension: Message Preview Generation' (draft-ietf-extra-imap-fetch-preview-10.txt) as Proposed Standard This document is the product of the Email mailstore and eXtensions To Revise or Amend Working Group. The IESG contact persons are Murray Kucherawy and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-fetch-preview/ Technical Summary This spec extends IMAP with an additional fetch item (PREVIEW) which allows clients to obtain a short piece of text to use as a preview line in mailbox listings. Working Group Summary This document and fetch item was originally named "snippet", however JMAP uses "preview" for the equivalent field, and "snippet" for a marked up section of the message containing search terms, so the working group agreed to change the naming to be consistent. There was also debate over the maximum length, with both JMAP and EXTRA working groups settling on 256 characters maximum. Finally there were questions over whether "LAZY" was useful, but nobody saw any downside to including it. Servers can choose to always calculate the preview even if LAZY is given. There was a significant amount of rework through multiple meetings which led to a very complex document. In the end, the authors asked to drop the complexity and go back to an earlier version, which achieved working group consensus. Document Quality This spec is quite easy to implement - it has multiple examples for all the likely cases. It's been implemented in Dovecot and Cyrus IMAPd. Personnel Document Shepherd - Bron Gondwana (EXTRA co-chair) Responsible Area Director - Barry Leiba RFC Editor Note Please make the following change to the second paragraph in Section 1: OLD Generation of a preview on the server has several benefits. First, it allows consistent representation of previews across all clients. This standardized display can reduce user confusion when using multiple clients, as abbreviated message representations in clients will show identical message contents. NEW Generation of a preview on the server has several benefits. First, it allows consistent representation of previews across all clients. While different clients might generate quite different preview text, having common preview text generated by the server can give a more consistent user experience to those who use multiple clients. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
