jiebi/CodeConvo huggingface dataset:
Change:
addressing (and a few minor editorial changes thrown in as well).
This is probably left over from earlier drafts that did cover multiple media types.
There are a couple more places that use the plural form "media types". Unless I am missing something, these all should be changed to singular form.
It's and . I don't have preferences and the singular is OK to me. Feel free to PR :)
that's what i also thought but then again isn't a media type (as i am sure you know). let's make NAME the tie-breaker!
Let's go with the singular form.
fixed via

Discussion:
<del> YAML Media Types </del> <ins> YAML Media Type </ins> draft-ietf-httpapi-yaml-mediatypes-latest Abstract

YAML YAML is a data serialization format that is widely used on the Internet, including in the API sector (e.g. see oas) but the relevant <del> media type and structured syntax suffix are not registered by IANA. </del> <ins> media type and structured syntax suffix previously had not been registered by IANA. </ins> To increase interoperability when exchanging YAML data and leverage content negotiation mechanisms when exchanging YAML resources, this

2. This section describes the information required to register the above <del> media types according to </del> <ins> media type according to </ins> 2.1.

media type structured syntax suffix registration form follows.  See MEDIATYPE for definitions of each of the registration form headings. <del> YAML Ain't Markup LanguageML (YAML) </del> <ins> YAML Ain't Markup Language (YAML) </ins> +yaml

3.1. <del> YAML is an evolving language and, in time, some features have been added, and others removed. </del> <ins> YAML is an evolving language and, over time, some features have been added and others removed. </ins> <del> While this document is based on a given YAML version YAML, media types registration does not imply a specific version.  This allows </del> <ins> While this document is based on a given YAML version YAML, the media type registration does not imply a specific version.  This allows </ins> content negotiation of version-independent YAML resources. Implementers concerned about features related to a specific YAML <del> version can specify it in the documents using the "%YAML" directive (see Section 6.8.1 of YAML). </del> <ins> version can specify it in documents using the "%YAML" directive (see Section 6.8.1 of YAML). </ins> 3.2.

5. <del> This specification defines the following new Internet media types </del> <ins> This specification defines the following new Internet media type </ins> MEDIATYPE. IANA has updated the "Media Types" registry at
Change:
includes clarification on JSON Pointer and alias nodes compatibility includes FAQ fragment identifier moved from media type to section empty fragment + are both under JSON Pointer
cc: NAME NAME PTAL
According to NAME this PR should better clarify JSON Pointer use, so I am going to merge it. The decision on forcing +yaml fragment is deferred to that I will rebase.

Discussion:
1.2. <ins> A fragment identifier starting with "*" is to be interpreted as a YAML alias node fragment-alias-node. A fragment identifier that is empty or that starts with "/" is to be interpreted as a JSON Pointer JSON-POINTER and is evaluated on the YAML representation graph, walking through alias nodes; this syntax can only reference YAML nodes that are on a path that is made up of nodes interoperable with the JSON data model (see int-yaml-and-json). A fragment identifier is not guaranteed to reference an existing node.  Therefore, applications SHOULD define how an unresolved alias node ought to be handled. 1.2.1. </ins> This section describes how to use alias nodes (see Section 3.2.2.2 and 7.1 of YAML) as fragment identifiers to designate nodes.

If multiple nodes would match a fragment identifier, the first such match is selected. <del> A fragment identifier is not guaranteed to reference an existing node.  Therefore, applications SHOULD define how an unresolved alias node ought to be handled. </del> Users concerned with interoperability of fragment identifiers: SHOULD limit alias nodes to a set of characters that do not

based data serialization language designed around the common native data types of dynamic programming languages. <del> An empty fragment identifier references the root node.  A fragment identifier starting with "*" is to be interpreted as a YAML alias node application-yaml-fragment.  A fragment identifier starting with "/" is to be interpreted as a JSON Pointer JSON-POINTER and is evaluated on the YAML representation graph, walking through alias nodes; this syntax can only reference YAML nodes that are on a path that is made up of nodes interoperable with the JSON data model (see int-yaml-and-json). </del> <ins> See </ins> Additional information:
Change:
Fix typical media type template problems Typos
In general, LGTM. About change controller, I was waiting for the feedback from the media type mailing list.

Discussion:
to be interpreted as in URI. The terms "node", "alias node", "anchor" and "named anchor" in this <del> document are to be intepreded as in YAML. </del> <ins> document are to be interpreted as in YAML. </ins> 1.2.

and 7.1 of YAML) as fragment identifiers to designate nodes. A YAML alias node can be represented in a URI fragment identifier by <del> encoding it into octects using UTF-8 UTF-8, while percent-encoding </del> <ins> encoding it into bytes using UTF-8 UTF-8, while percent-encoding </ins> those characters not allowed by the fragment rule in Section 3.5 of URI.

yaml <del> None </del> <ins> N/A </ins> <del> None; unrecognized parameters should be ignored </del> <ins> N/A; unrecognized parameters should be ignored </ins> binary

<del> HTTP </del> <ins> Applications that need a human-friendly, cross language, Unicode based data serialization language designed around the common native data types of dynamic programming languages. </ins> An empty fragment identifier references the root node.  A fragment identifier starting with "*" is to be interpreted as a YAML alias

Deprecated alias names for this type: application/x-yaml, text/ yaml, text/x-yaml <del> Magic number(s) n/a </del> <ins> Magic number(s) N/A </ins> File extension(s): yaml, yml <del> Macintosh file type code(s): n/a </del> <ins> Macintosh file type code(s): N/A </ins> See Authors' Addresses section.

See Authors' Addresses section. <del> n/a </del> <ins> IESG </ins> 2.2.

See <del> See Authors' Addresses section. </del> <ins> httpapi@ietf.org or art@ietf.org </ins> See Authors' Addresses section <del> n/a </del> <ins> IESG </ins> 3.

considerations apply. When using YAML as a more efficient format to serialize information <del> intented to be consumed as JSON, information can be discarded: this </del> <ins> intended to be consumed as JSON, information can be discarded: this </ins> includes comments (see Section 3.2.3.3 of YAML) and alias nodes (see Section 7.1 of YAML), that do not have a JSON counterpart.

identifiers.  This is to improve the interoperability of already consolidated practices, such as the one of writing OAS in YAML. <del> ex-fragid provides a non exhaustive list of examples that could help understanding interoperability issues related to fragment identifiers. </del> <ins> ex-fragid provides a non-exhaustive list of examples that could help understand interoperability issues related to fragment identifiers. </ins> 4.
Change:
in YAML and JSON, explicits that you need to use only information that is stored in the representation graph, not other. See
mention presentation and serialization details they cannot be used to interoperably convey information comments, ordering and anchor names fall in the above categories.

Discussion:
to be interpreted as in URI. The terms "presentation", "stream", "YAML document", "representation <del> graph", "node", "alias node", "anchor" and "anchor name" in this document are to be interpreted as in YAML. </del> <ins> graph", "tag", "node", "alias node", "anchor" and "anchor name" in this document are to be interpreted as in YAML. </ins> 1.2.

considerations apply. When using YAML as a more efficient format to serialize information <del> intended to be consumed as JSON, information can be discarded: this includes comments (see Section 3.2.3.3 of YAML) and alias nodes (see Section 7.1 of YAML), that do not have a JSON counterpart. </del> <ins> intended to be consumed as JSON, information not reflected in the representation graph and classified as presentation or serialization detail (see Section 3.2 of YAML) can be discarded.  This includes comments (see Section 3.2.3.3 of YAML), directives, and alias nodes (see Section 7.1 of YAML) that do not have a JSON counterpart. </ins> Implementers need to ensure that relevant information will not be lost during the processing.  For example, they might consider
Change:
looks good to me (with one minor editorial note i left as a comment).
Would it be valuable to express a preference for over for file extensions? I'm assuming 3 character extensions are legacy from DOS file systems that had a 3 character limit. I reviewed the YAML 1.2 spec and there is no mention of using as a file extensions, so this might be a good opportunity to steer the community away from having two extensions.
Pls let's annihilate the DOS zombie!
NAME let's summon NAME and the YAML folks on that. IMHO: agree on expressing a preference disagree on removing references to .yml, since it's used in the wild. My2¢, R.
Discussed with YAML folks. Ok for indicating a preference without normative implications.

Discussion:
Magic number(s) N/A <del> File extension(s): yaml, yml </del> <ins> File extension(s): "yaml" (preferred), "yml".  See int-yaml- filename-extension. </ins> Macintosh file type code(s): N/A

3.3. <ins> The "yaml" filename extension is the preferred one; it is the most popular and widely used on the web.  The "yml" filename extension is still used.  The simultaneous usage of two filename extensions in the same context might cause interoperability issues (e.g. when both a "config.yaml" and a "config.yml" are present). 3.4. </ins> When using flow collection styles (see Section 7.4 of YAML) a YAML document could look like JSON JSON, thus similar interoperability considerations apply.

types like custom and local tags such as "!!python/object" and "!mytag" (see Section 2.4 of YAML); <del> 3.4. </del> <ins> 3.5. </ins> To allow fragment identifiers to traverse alias nodes, the YAML representation graph needs to be generated before the fragment
Change:
As discussed in today's interim. This is essentially repushing which should not have been reverted.
URL
Interim 2022-06-09: Informational refence from RFC to a draft is allowed Agreement to just un-revert / re-land
Fixed in

Discussion:
agreement properties of MLS will confirm that all members of the group agree on the content of these extensions. <del> Application messages carried by MLS are opaque; they can contain arbitrary data.  The MLS framing for application messages also provides a field where clients can send information that is authenticated but not encrypted.  Such information can be used by servers that handle the message, but group members are assured that it has not been tampered with. </del> 5.8. <ins> Application messages carried by MLS are opaque to the protocol; they can contain arbitrary data.  Each application which uses MLS needs to define the format of its "application_data" and any mechanism necessary to negotiate the format of that content over the lifetime of an MLS group.  In many applications this means managing format migrations for groups with multiple members who may each be offline at unpredictable times. *RECOMMENDATION:* Use the default content mechanism defined in I- D.mahy-mls-content-neg, unless the specific application defines another mechanism which more appropriately addresses the same requirements for that application of MLS. The MLS framing for application messages also provides a field where clients can send information that is authenticated but not encrypted. Such information can be used by servers that handle the message, but group members are assured that it has not been tampered with. 5.9. </ins> The protocol aims to be compatible with federated environments. While this document does not specify all necessary mechanisms required for federation, multiple MLS implementations can

authentication mechanisms, ciphersuites, and infrastructure functionalities. <del> 5.9. </del> <ins> 5.10. </ins> It is important that multiple versions of MLS be able to coexist in the future.  Thus, MLS offers a version negotiation mechanism; this
Change:
Thanks Brendan! I'll merge this modulo the deletion of the paragraph regarding "being a member" since that was specifically discussed during an interim call.

Discussion:
assume this. Users will often use multiple devices, e.g., a phone as well as a <del> laptop.  Different devices are represented as different clients with independent cryptographic state. </del> <ins> laptop.  The formal definition of a Group in MLS is the set of clients that have knowledge of the shared group secret established in the group key establishment phase of the protocol and have contributed to it.  Until a Member has been added to the group and contributed to the group secret in a manner verifiable by other members of the group, other members cannot assume that the Member is a member of the group.  Different devices are represented as different clients with independent cryptographic state. </ins> 3.
Change:
This PR pulls in the CAP theorem-related discussion from URL which is a more helpful way to frame DS design.

Discussion:
Issue credentials to clients that attest to bindings between identities and signature key pairs <del> Enable a group member to verify that a credential presented by another member is valid with respect to a reference identifier </del> <ins> Enable a client to verify that a credential presented by another client is valid with respect to a reference identifier </ins> Enable a group member to verify that a credential represents the <del> same application-level device as another credential </del> <ins> same application-level device as another credential when possible </ins> A member with a valid credential authenticates its MLS messages by signing them with the private key corresponding to the public key

epoch and begins the next one. In practice, there's a realistic risk of two members generating <del> Commit messages at the same time, based on the same state, and both </del> <ins> Commit messages at the same time, based on the same counter, and both </ins> attempting to send them to the group at the same time.  The extent to which this is a problem, and the appropriate solution, depends on the design of the Delivery Service.  Per the CAP theorem, there are two

Strategies for sequencing messages in CP and AP systems are described in the next two subsections. <del> However, note that a Delivery Service could also reorder messages or provide an inconsistent view to different users not just accidentally, but maliciously.  The protocol is designed such that this only results in a group no longer being functional and the group members possibly detecting this and requesting reinitialization. </del> <ins> However, note that a malicious Delivery Service could also reorder messages or provide an inconsistent view to different users.  The protocol is designed such that this only results in a group no longer being functional and the group members possibly detecting this and requesting reinitialization. </ins> Other forms of Delivery Service misbehavior are still possible that are not easy to detect.  For instance, a Delivery Service can simply
Change:
According to I-D Nits: Checking nits according to URL : The abstract seems to contain references ([I-D.ietf-mls-protocol]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 557: 'URL forked group states MUST be deleted...'
TY!
Thanks NAME

Discussion:
Abstract <del> The Messaging Layer Security (MLS) protocol I-D.ietf-mls-protocol </del> <ins> The Messaging Layer Security (MLS) protocol (I-D.ietf-mls-protocol) </ins> specification has the role of defining a Group Key Agreement protocol, including all the cryptographic operations and serialization/deserialization functions necessary for scalable and

past epoch is received, clients use a deterministic tie-breaking policy to decide if they should continue using the Commit they originally accepted or revert and use the later one.  Note that <del> any copies of previous or forked group states MUST be deleted </del> <ins> any copies of previous or forked group states must be deleted </ins> within a reasonable amount of time to ensure the protocol provides forward-secrecy.
Change:
Made minor changes to the section of content and framing. Updated reference draft-mahy-mls-content-neg -> draft-mahy-mls-content-adv The recommended mechanism is advertising content/media types, not a full negotiation mechanism.

Discussion:
Application messages carried by MLS are opaque to the protocol; they can contain arbitrary data.  Each application which uses MLS needs to define the format of its "application_data" and any mechanism <del> necessary to negotiate the format of that content over the lifetime </del> <ins> necessary to determine the format of that content over the lifetime </ins> of an MLS group.  In many applications this means managing format migrations for groups with multiple members who may each be offline at unpredictable times. *RECOMMENDATION:* Use the default content mechanism defined in I- <del> D.mahy-mls-content-neg, unless the specific application defines </del> <ins> D.mahy-mls-content-adv, unless the specific application defines </ins> another mechanism which more appropriately addresses the same requirements for that application of MLS.
Change:
As per Jan MLS meetup, malicious insiders should be considered as a potential threat, though perhaps in a restricted set of scenarios. It is probably bad if a malicious group member can trivially DoS people, for example, as in naïve ART.

Discussion:
Clients should not be able to send messages to groups which appear to be from other Clients <ins> Clients should not be able to perform trivial denials of service </ins> 4. As the MLS protocol provides an important service to users, its

cryptographic keys for attachments is usually higher than for messages, hence slightly weakening the PCS guarantees for attachments. <ins> 4.2.2.4. In general we do not consider denial of service to be the responsibility of the protocol.  However, it should not be possible for anyone to perform a trivial denial of service from which it is hard to recover. --- back </ins>
Change:
I'll add references for QUIC, TLS, IPsec, WireGuard, and TOR. Update: Created
Comment by NAME It is a bit odd to mention a non-IETF VPN protool, but not the IETF VPN protocol. Especially since IPsec also has constant byte stream support via IPTFS that WireGuard does not have :P
This is just a list of examples, it doesn't need to cover everything in the universe. And IETF docs are allowed to mention non-IETF things.

Discussion:
As discussed above, MLS provides the highest level of security when its messages are delivered over a secure transport.  Any secure channel can be used as a transport layer to protect MLS messages, <del> such as QUIC, TLS, WireGuard or TOR.  However, the MLS protocol is designed to consider the following threat-model: </del> <ins> such as QUIC RFC9000, TLS RFC8446, IPsec RFC6071, WireGuard WireGuard, or TOR TOR.  However, the MLS protocol is designed to consider the following threat-model: </ins> The attacker can read, write, and delete arbitrary messages inside the secure transport channel.
Change:
Comment by NAME It scares me a bit that this could possibly not be detected at all? What is the scenario where it cannot be detected?
It's actually non-trivial to guarantee detection. Consider a scenario like the following: A, B, C, D are in a group The DS decides to partition the group into (AB) (CD) The DS forwards commits and messages within a partition, but not across partitions. As a result, the two subgroups work fine, but they diverge from each other This will be immediately obvious if two participants in opposite partitions ever try to compare state across the partition boundary, say by checking whether a message arrived or even by comparing the value. But it will be invisible if nobody does -- it just looks like the other partition is offline at the moment. And note that comparing across the partition boundary has to be done out of band, because the DS is blocking in-band comms across the boundary. To prevent this with any reliability, you would need a consensus protocol by which a quorum of members verify that they've received a Commit. And even then, the members outside any particular quorum could be partitioned. In any case, designing a consensus protocol is clearly outside the MLS WG charter. The silver lining here, as the document notes, is that the protocol fails closed. If two members have different views of the group, then they cannot communicate.
This is only true wrt to handshake messages. The DS can still reorder and provide an inconsistent view of application messages. We intentionally punted this to an extension (which I realize now we never specified in the extensions doc) to give applications leeway in the ordering/delivery guarantees provided to application messages. Handshake messages require reliable and in-order but application messages may or may not.

Discussion:
However, note that a malicious Delivery Service could also reorder messages or provide an inconsistent view to different users.  The <del> protocol is designed such that this only results in a group no longer being functional and the group members possibly detecting this and requesting reinitialization. </del> <ins> "generation" counter in MLS messages provides per-sender loss detection and ordering that cannot be manipulated by the DS.  A mechanism for more robust protections is discussed in I-D.ietf-mls- extensions.  A DS can cause a partition in the group by partitioning key exchange messages; this can be detected only by out of band comparison (e.g., confirming that all clients have the same "epoch_authenticator" value`). </ins> Other forms of Delivery Service misbehavior are still possible that are not easy to detect.  For instance, a Delivery Service can simply
Change:
There have been a lot of comments about the inclusion of WireGuard and Tor as potential secure transports, but I actually think it's confusing to cite IPsec as well for layering issues. We don't have a real praxis for using things that aren't application-layer style protocols for protecting this kind of traffic, so I don't think we should encourage these. I've trimmed it to just QUIC and TLS.

Discussion:
As discussed above, MLS provides the highest level of security when its messages are delivered over a secure transport.  Any secure <del> channel can be used as a transport layer to protect MLS messages, such as QUIC RFC9000, TLS RFC8446, IPsec RFC6071, WireGuard WireGuard, or TOR TOR.  However, the MLS protocol is designed to consider the following threat-model: </del> <ins> channel, such as QUIC RFC9000, TLS RFC8446, can be used to transport MLS messages.  However, the MLS protocol is designed to consider the following threat-model: </ins> The attacker can read, write, and delete arbitrary messages inside the secure transport channel.