One possible way to address the problem with positive relative times
NAME Fixed
Looks like two of you are still working details of phrasing but I like where it is going and all looks about right to me.


This PR aims to take the design discussions we had at the last interim, and propose a potential solution. This PR should in theory contain enough information to allow folks to implement this new design. That will allow us to perform interop testing and confirm whether the design is sound.
I'm confused by this pull request (probably because I was out of the loop for a while). My understanding, at least when I first read the proposal a month ago was that we would separate multiplexing streams and multiplexing contexts into different layers, so that methods that need context would get it (CONNECT-UDP), and features that don't (WebTransport/extended CONNECT) could use stream-associated datagrams directly.
NAME you're referring to which this PR isn't trying to address. That'll happen in a subsequent PR.
In , capsules, contexts and context IDs are explicitly defined as end-to-end and there are requirements for intermediaries to not modify them, and to not even parse them. The motivation for this was to ensure that we retain the ability to deploy extensions end-to-end without having to modify intermediaries. NAME mentioned that these requirements might be too strict, as he would like to have his intermediary be able to parse the context ID, for logging purposes.
Part of the comment from the PR is also about consistency of interface for generic HTTP libraries that can be used to build either endpoints or intermediaries. If the context ID is always present, it's overly prescriptive to say that an intermediary can't parse it, and such a requirement couldn't be enforced anyways. If context IDs are negotiated on/off, whether this is possible depends on the negotiation mechanism.
I think its fine for a component that has bytes passing through it to look at those bytes. The import thing to do is set expectations on what that means for the protocol behaviour we are defining. We don't expect intermediaries to do anything with a context ID; they should not enforce the protocol semantic rules (odd, even, reuse etc). H2 and H3 somewhat solve this problem by decoupling frame parsing from frame payload interpretation. E.g. if the form of a request or response is invalid, an intermediary shouldn't pass it on. DATAGRAM is different because it isn't defined as an actual HTTP/3 frame with frame headers and frame payload.


Something that might work is to formalise that quarter stream ID is part of the envelope that intermediaries have to be able to handle the syntax of, but context ID is part of content and separate.
Unless you encrypt capsules end-to-end, I don't think any text in the spec can in practice prevent intermediaries from inspecting and modifying capsules. You can send something like GREASE capsules, though.
In , we introduce the CLOSEDATAGRAMCONTEXT capsule which allows endpoints to close a context. That message currently only contains the context ID to close. NAME suggests that we may want to add more information there. Should we differentiate between "context close" and "context registration rejected"? Should we add an error code? In particular, do folks have use cases for these features?
My first concern is with infinite loops. If the context was "garbage collected" by the recipient, the sender can simply re-create it if they still want it. However, if it was closed due to incompatibility (i.e. rejected) or hitting a resource limit (e.g. max # of contexts), reopening it in response will produce a tight infinite loop. This could be maybe be avoided by some kind of heuristic, but an explicit indication of what's going on seems better.
This issue assumes that decide to go with the two-layer design described in . Given that design, some applications might not need the multiplexing provided by context IDs. We have multiple options here: Make context ID mandatory Applications that don't need it waste a byte per datagram Negotiate the presence of context IDs using an HTTP header Context IDs would still be mandatory to implement on servers because the client might send that header Have the method determine whether context IDs are present or not This would prevent extensibility on those methods Create a REGISTERNOCONTEXT message This assumes we use the Message design from We add a register message that means that this stream does not use context IDs This allows avoiding the byte overhead without sacrificing extensibility
Making the context ID mandatory is simple, although slightly wasteful. For the variations where it is optional, I prefer the one that uses a header. It could work with a variant of where we do Header + Message, and the Header determines whether or not you have contexts, and whether or not they can be dynamic.
What are the benefits of message over header to make it optional?


To me it seems like header is sufficient, because the context IDs are end-to-end, and should not affect intermediaries, making the header a natural place to put it. I think having the context ID be the default behavior and the header is to opt-out is the right decision if we were to allow removing it.
This is a bit of a bike-shed, but why would it default to having context-IDs instead of not having them?
I think the second option "Negotiate the presence of context IDs using an HTTP header" is the best personally. In terms of: "Context IDs would still be mandatory to implement on servers because the client might send that header", I assume server in this context is the final application server, not a proxy? Even so, I'd argue it's applications which decide if they need this functionality, so if a server only implemented one application and it didn't use Context-IDs, then I don't see why it would need to implement it.
Ian, in your comment, are you talking about an intermediary when you say "proxy"? If so, then an intermediary need not implement anything based on the payload of than H3 DATAGRAM, it only has to pass the data along. That may be worth a clarification.
Having context ID optional has a nice future-proof property - other uses of datagrams in HTTP/3 can decide if they want the second layer or not. I wouldn't even state it as application needing multiplexing or not. Other applications might find it very useful to include a second ((third, fourth, fifth) layer of frame header. I think its fine for us to state as much in this in the spec, while also defining an explicit second layer for multiplexing.
Yes, by proxy I meant intermediary. And I agree about what intermediaries need to do, I just wanted to ensure I understood what server meant when David used it above. Yup, whenever all this gets written up, we can make it clear that intermediaries can ignore much of this.
The method defines the semantics of datagrams for a particular request, thus I think the third option makes most sense.


I don't see a point in using explicit negotiation, since in the two cases I can think of the top of the head, the answer is always clear from the method (CONNECT-IP seems to always want context IDs, WebTransport does not ever want context IDs). If some method starts out without context, but wants to add context later, it can add its own negotiation.
One set of use cases for which the method approach(3) is best are those where there are multiple context IDs but they're predefined by the method and don't need negotiation. My strawman is WebRTC.
During the 2021-04 MASQUE Interim, we discussed multiple options for registering context IDs. Without going into the specific of the encoding, there are two broad classes of solutions: "Header" design Once-at-setup registration This happens during the HTTP request/response Simplest solution is to use an HTTP header such as (encoding TBD) Example use-case: CONNECT-UDP without extensions "Message" design Mid-stream registration This can happen at any point during the lifetime of the request stream This would involve some sort of "register" message (encoding TBD, see separate issue) Example use-case: CONNECT-IP on-the-fly compression (this can't be done at tunnel setup time because the bits top be compressed aren't always known at that time) It's possible to implement once-at-setup registration using the Message design, but it isn't possible to implement mid-stream registration. Therefore I think we should go with the Message design. It would also be possible to implement both but I don't think that provides much value.
I'd like to here some more from the WebTransport use case on the issue. My understanding is that the Requests are used to create WebTransport sessions and that creation of datagram flows(contexts) could be a lot more ad-hoc / server generated after the request phase, when compared to the CONNECT-UDP case. Cc NAME
Personally, I'd vote for either "message" or "message + header" (a la priorities), but not just "header". Mid-stream annotation of context/flow/etc is quite useful.
I prefer "Message" only, since the dynamic use case seems like a fairly compelling use of sub-flows(contexts?).


I'm not sure there are many cases when one allocates all sub-flows up front AND needs to use a header to do that in a flexible way. If an application needs multiple sub-flows, but they're fixed in number/format(ie: data and control), I don't think there's a need for a header or a "Message", since the application can consider that part of its internal format.
During the 2021-04 MASQUE Interim, we discussed having the ability to accept or reject registration of context IDs. An important motivation for this is the fact that context ID registrations take up memory (for example it could be a compression context which contains the data that is elided) and therefore we need to prevent endpoints from arbitrarily making their peer allocate memory. While we could flow control context ID registration, a much simpler solution would be to have a way for endpoints to close/shutdown a registration.
IIUC there's an opposing view that the constraints can be negotiated apiori. Either statically (such as defining an extension which states that there can only be N contenxts of a given type) or dynamically using something like a HTTP header. Failure to meet these constraints could lead to an HTTP/3 stream or connection error rather than a flow rejection.
NAME I've filed to discuss whether to register/negotiate at request start or mid-stream.
I think that if there is the ability to register mid-stream (), we need the ability to close/de-register/reject mid-stream as well. If we don't have mid-stream changes, then no need to negotiate. However, someone trying to register something needs to be able to know whether or not the thing they registered will be accepted.
I agree that notification of the registration status is particularly important if we allow mid-stream registration.
In draft-ietf-masque-h3-datagram-00, flow IDs are bidirectional. During the 2021-04 MASQUE Interim, we discussed the possibility of making them unidirectional. Here are the differences: Bidirectional single shared namespace for both endpoints (even for client, odd for server) it's easier to refer to peer's IDs, which makes negotiation easier Unidirectional one namespace per direction every bidirectional use needs to associate both directions somehow I'm personally leaning towards keeping them bidirectional.


Unlike QUIC streams, these do not have a state machine or flow control credits, so there is no cost to only using a single direction of a bidirectional flow for unidirectional use-cases.
There's another option where flows are unidirectional but they share a namespace (cleint even/server odd). I'm undecided. And I also don't know how important it is to choose. The 2 layer design means that DATAGRAMs always have a bidirectional tie via the stream ID. On balance, I think bidirectional would be good enough today but I would be receptive to extension use cases that make a strong point of unidirectional.
Bidirectional is my personal preference, but either way could work ultimately. It seems to me that any extension that wants unidirectional can just only use this context/flow/etc ID for one direction if it wants.
I think bidirectional flows are likely overcomplicated and unnecessary. For example, if either peer can "close" a flow, this requires a much more complex state machine. In my experience, half-closed states are hard to get right. Closing unidirectional flows seems much easier to reason about. Many, perhaps most, of our use cases for flows are really unidirectional. For example, DSCP marking likely only makes sense from client to server, while timestamps for congestion control tuning likely only make sense from server to client. QUIC connection IDs are different in each direction, so QUIC header compression may be easiest to understand with unidirectional flows.
Bidirectional doesn't imply half-close states. I'm thinking of a bidirectional flow that can only be closed atomically as a whole. I don't think that's true. The default extension-less CONNECT-UDP is bidirectional. So is ECN, and so would a timestamp extension.
I would prefer bidirectional without support for half-close. I feel that having unidirectional flow/context IDs adds overhead we don't need; peers now need to track those associations and it's unclear what the benefits of having them separated out are.
This issue is conflating consent (unilateral/bilateral) with scope (unidirectional/bidirectional). IIUC there are two questions here: 1) Can I send a flow-id forever once declared, or can the endpoint tell me to stop without killing the whole stream (consent)?


2) Can the receiver of a flow-id assignment use that same flow-id when sending datagrams, or could this mean something completely different? I think the answer to (1) is "yes, it can tell me to stop" (i.e. it is negotiated while allowing speculative sending). For (2), I lean toward bidirectional, but not strongly. There are plenty of codepoints, so it seems wasteful for each endpoint to define the same semantic explicitly.
NAME the intent of this issue wan't to conflate those two things. This issue is about scope. For consent, see issue .
Conceptually, I like unidirectional better. I tell the peer that when I send with context-ID=X, it has a given semantic. For bidirectional the sender is saying both that and that if the peer sends on that ID the original sender will interpret with the same semantic. That might not even make sense. Is it possible to associate datagrams with a unidirectional stream (push?). If so, does allowing for bidirectional context imply that even though the receiver cannot send frames on the stream, it can send datagrams? Every negotiation does run the risk of loss/reordering resulting in a drop or buffering event at the receiver. The appeal of bidirectional is that it removes half of this risk in the cases where the bidirectionality is used.
To second NAME I would also prefer bidirectional without support for half-close. Given you can always not send something in one direction, and there's none of the overhead of streams(ie: flow control, etc) I can't see any benefits of unidirectional over bidirectional in this case. Associating h3-datagrams with a server push seems like unnecessary complexity to me, but you're right that it should be clarified.
During the 2021-04 MASQUE Interim, we discussed a design proposal from NAME to replace the one-layer flow ID design with a two-layer design. This design replaces the flow ID with two numbers: a stream ID and a context ID.


The contents of the QUIC DATAGRAM frame would now look like: While the flow ID in the draft was per-hop, the proposal has better separation: the stream ID is per-hop, it maps to an HTTP request the context ID is end-to-end, it maps to context information inside that request Intermediaries now only look at stream IDs and can be blissfully ignorant of context IDs. In the room at the 2021-04 MASQUE Interim, multiple participants spoke in support of this design and no one raised objections. This issue exists to ensure that we have consensus on this change - please speak up if you disagree.
I am fine with the 2-layer design for CONNECT-UDP, but I am not sure if the second identifier should be in H3 DATAGRAM or should be specific to CONNECT-UDP. As I indicated to the list, webtrans and httpbis might weigh in on this with broader consideration of other use cases.
Hi NAME the topic of the optionality of context IDs is discussed in issue .
I think this is a good design, because it minimizes the core functionality of the draft, but avoids every application that needs multiple dynamically created sub-flows from re-inventing a different mechanism. Nit: I would not call this a 'Frame', since it's not an HTTP(TLV) frame.
I think this is a good change. Thanks! There are some things that I think we should still discuss, but we shouldn't hold up this change on those details.


Several small updates, mostly to clean things up a bit, and align property names and such.
NAME - I think you're wrong: my understanding (and also the way the text is written - otherwise we'd have to change it in the API draft) was that Connection Properties can (and should) also be set on Preconnections, to give as much input as possible for Connection establishment. In the API draft, the Selection Properties in Section 5.2 can only be used on Preconnections: you can't ask for congestion control after establishment. You can't say that you'd rather have multistreaming support after establishment. But that doesn't exclude Connection properties from being usable earlier. Required minimum checksum coverage could influence choosing UDP-Lite vs. UDP. Bounds on Send or Receive Rate could influence the interface choice. The capacity profile could influence various things (and no, there isn't a matching Selection Property now - there is a per-Message override). So... I think that either you're wrong, or I'm missing something and the API draft heavily lags behind a decision that was made. I hope not!
NAME The API drafts says: I interpret this as only the Selection Properties influence selection and the Connection properties are used to further configure the connections according to user preferences. Otherwise what is the difference between them?
If you interpret it as you do, I think the text isn't clear enough (indeed it isn't super clear - in particular, "eventually established" is misleading IMO). Though, note that it says that Connection properties can also be used later. Regarding the difference between them: Selection Properties only make sense for Preconnections.
NAME - sorry lost this thread. But I saw that you have started cleaning up some Connection properties that had mixed Connection and Selection properties up in the API draft. Does it mean that we are now in synch and agree that only Selection properties are used in the selection and Connection properties are used for configuration (both during establisment and also after the connection setup).
NAME the other PR means nothing about what I said here: it only tried to address issue which is about a wording inconsistency in a specific property. You say that Connection properties can also be used during establishment - if you agree with allowing this, then why not allow to configure them as early as possible and allow them to influence selection?


What's bad about having more information available that can guide the selection process?
NAME the problem is that the Connection properties are not expressed in a way suitable for selection. If they should also be used for Selection they would have to be reworked to be of type Preference. Otherwise I do not know what they mean for selection. What does it mean if I pick say a particular connection group transmission scheduler? Is it required or preferred? Most connection properties also do not look very useful to me for selection so in case there are some we need I think it would be simpler to just define a matching selection property.
NAME we're only discussing whether it's allowed to use them as additional input or not. I agree, some (like the scheduler choice) don't seem useful, but some do... generally we may not have good guidance on how they should be used by an implementation, but giving the system freedom to use as many inputs as possible is probably a good thing. Regarding the type, require/prefer//ignore/avoid/prohibit obviously works fine for a "wishlist" of boolean character: having something, or not having it. The selection properties are generally like that - except "Interface Instance or Type" and "Provisioning Domain Instance or Type" which are, well... wishlist-collections. Consider the capacity profile. Surely configuring this early can be useful input - e.g. if someone picks low latency / interactive, you may even want to put this traffic on a specific network interface! But if you'd want to make a copy of the capacity profile as a "proper" selection property, how would you do it? Apply require/prefer/ignore/avoid/prohibit for each of its values? Then I could say "prefer" low latency/non-interactive but "avoid" low latency/non-interactive, which would surely be odd. Apply the qualifier to the whole thing? Then it's about, e.g. "avoiding" to use a capacity profile at all. That's odd as well. I think it's in the nature of the current selection properties that they merely say "I want to be able to do this, and this is how important it is to me", which is different from configuring something. That's also why, as written, they simply wouldn't work for later connection configuration.


Connection properties really are about configuring something, but I still say that being able to use them as early input is good. I agree that the implementation isn't super clear as they don't come with a require/prefer/... etc. qualifier, but then we just offer some freedom to implementers.
NAME I just pushed a commit that updates the selection and connection properties text, removing "connection" almost everywhere, but adding a disclaimer in the beginning that says that connection properties should be configured as early as possible because they can influence decisions made by the implementation, and "In the remainder of this document, we only refer to Selection Properties because they are the more typical case." Frankly I'm not sure this is better... but it does remove most of the "selection and connection" double mentions that you pointed out.
Fixed up branch building and resolved merge conflicts. I'll merge this in later today before the posting deadline.
Cool thanks! Sorry if I messed something up
As discussed in
Thank you for updating this – looks good! just needs s/send-params/msg-properties/ and merging


Current text says: the "encryptedservername" extension. However, I am not sure if this is the desired behavior. I would rather suggest encrypting even when the hostname exceeds the padded_length. Having some protection is better than none. The issue is that in certain deployments it is impossible to guess what the maximum length of the hostname will be. Consider . It uses a wildcard certificate. Anybody can add a new hostname of any length by creating a new Github account (it might be true that Github some limitation on the length, but that does not necessarily mean that Github shares the maximum length information with the fronting CDN, assuming that it uses a CDN).
I have filed that fixes another issue (it's just a clarification of an open issue) related to wildcard delegation.
Technically, it is possible to guess the maximum length of the hostname, as that maximum textual representation length is defined as 253 bytes per RFC 1034.
Yes. So the question is if a CDN that has a wildcard mapping needs to set to 253 (since current text is a MUST NOT for sending a server name longer than the paddedlength), or if we should introduce a different rule.
How about something like: padded_length : The length to pad the ServerNameList value to prior to encryption. This value SHOULD be set to the largest ServerNameList the fronting server expects to support rounded up the nearest multiple of 16. If the fronting server supports wildcard names, it SHOULD set this value to 256.
NAME Thank you for the suggestion. I was feeling uneasy (and am still feeling a bit) about requiring the client to send an ESNI extension as large as ~300 bytes, assuming that CDN's would have at least one wildcard mappings. But it's about the first packet sent from the client, and we typically have enough room even when 0-RTT data is involved. So I think that we can live with that.
To be
Thank you for working on this! LGTM aside from the two comments shown below.Sorry, I missed the padding thing, so you'll need to adjust


This PR adds a RequiredCapabilities extension that allows the members of a group to impose a requirement that new joiners support certain capabilities. The extension is carried in the GroupContext and verified at Add time (including on external commits). In the interim 2021-10-04, we briefly discussed whether this mechanism needed to be included in the core protocol. Because of its interactions with Add and GroupContextExtensions proposals, it seems worth having in the main protocol.
s currently have two usages in the spec: Pre-published key packages that you can download and put in a leaf when adding a new member leaf node content that you update when doing a full Currently, things have been designed to use only one structure for both uses, leading to some weirdness such as: and are useful in the usage 1, but are parameters of the group in usage 2. is a good name in usage 1, but would better be named in usage 2. some data is important in usage 2 and have no meaning in usage 1, hence they were designed as "mandatory-when-updating extensions" (such as , and we were also discussing about adding the in to help prevent cross-group attacks) How about using different structures for these? // Essentially identical to KeyPackage struct { ProtocolVersion version; CipherSuite ciphersuite; HPKEPublicKey hpkeinitkey; opaque endpointid; Credential credential; Extension extensions; opaque signature; } PrePublishedKeyPackage; struct { HPKEPublicKey hpkekey; opaque endpointid; Credential credential; opaque parenthash; opaque groupid; Extension extensions; opaque signature; } LeafNodeContent; enum { reserved(0), prepublishedkeypackage(1), leafnodecontent(2), (255) } LeafNodeType; struct LeafNode { // This is not included in the signature, but with the "unambiguous signature" PR that's not a problem LeafNodeType type; select(URL) { case prepublishedkeypackage: PrePublishedKeyPackage data; case leafnode_content: LeafNodeContent data; } } What would you think about refactoring like this?
If we're doing this, I'd suggest including a dedicated public key to encrypt Welcome messages to for the . NAME suggested this at some point.


It gives us better FS guarantees, because the receiver of the can delete the corresponding private key immediately after decryption, while they might have to keep the other key around for a bit until they can actually issue an update. This might also help clarify .
Ties into as well because is an example of an extension that is required and should be a field instead
NAME one concern I have is how is that field in created?
When sending a full , the participant includes a new in the (it replaces the field). It computes the signature with where: corresponds to all the fields of except (the usual thing) comes from
What about the scenario where Alice pulls down Bob's key package to add him to the group? In that case Alice can't do the conversion between formats on Bob's behalf.
Alice don't have to do the conversion, this is why either contain a (when adding someone to the group) or a (when updating your own key package).
Ah somehow I missed that part in your original post. Makes sense
I like this general direction. It solves a few things. Instead of having leaf nodes contain either a prepublished thing or a normal leaf node, how about having the prepublished thing wrap the leaf node thing? As a bonus, we get separation between the key pair used for Welcome encryption and the key pair that goes in the leaf for TreeKEM. Then when Alice adds Bob, she extracts his LeafNodeContent and sends that in the Add. That doesn't let the other members of the group verify that Alice did the right thing w.r.t. expiry, but I'm not heartbroken about that. We might also be able to remove the extensions field from the outer (KeyPackage) wrapping if we turn the extension into KeyPackage field. I expect we probably need leaf extensions, but would be open to making into a field.
Why not keep sending the KeyPackage in the Add? That wouldn't cost much and would allow everyone to validate the lifetime. Note, that the lifetime is crucial in achieving PCS for pre-published key material. If I compromise Bob and get hold of the private key material of a bunch of his KeyPackages, I can add "Bob" to any group I want as long as the Credential inside the LeafNodeContent remains valid and Bob doesn't revoke the LeafNodeContent somehow.


Also, we'll have to do this if we want to enable any member to send the Welcome message as you proposed here: URL
I agree that including inside is quite clean, but something is bothering me with this approach: I'd like that the is signed by the participant occupying that leaf, to protect against cross-group attacks. In the first message of this issue I did this by including in , but in fact we don't need to store it in the leaf, we just need to include it in the . In any case, if we want to include in the signature, we need a way to differentiate between leaves that triggered a commit and the ones that are "fresh". And for that I think using a tagged-union struct is the cleanest way to do it.
It always feels a bit lazy to use an extension (and implementations have to be careful to check for their presence), but we could use a extension in the same way that we use a extension. You will find both of them only on LeafContents that were updated at least once. Another result of including GroupId in the KeyPackage is that the signature will explicitly sign the and I'm not sure if that doesn't completely destroy any deniability guarantees we can still get from MLS.
I don't think there's really a good way to get the into the leaf. Because of prepublication, it would have to be optional, but in order to prevent attacks, you need rules to decide whether it's required in a given situation. It seems like the best you can do is basically TOFU: When you first get the tree, you can't validate whether the groupid should be in a given leaf or not Once you're a member, you require that groupid is sent in Update and UpdatePath.leafkey_package I could live with a solution of that character, but given it's a bit complex, might prefer to leave it out unless we get a useful property from it. NAME - Re: Sending KeyPackage in Add - Yep, that makes sense. So you would send KeyPackage in Add, and LeafNode in Update.
I tried to worked through what would be necessary to implement this. It looks like it would require some fairly invasive changes to be made to rationalize the document's structure before making this change. But those changes should probably be made anyway.


Proposal: Preparatory PR: Rationalize layout Move "Cryptograhic Objects" to before "Ratchet Trees" Update "Ratchet Tree Nodes" to define ParentNode and LeafNode structs, with LeafNode initially just equal to KeyPackage Move subsections of "Key Packages" to under "Ratchet Trees" Parent Hash Tree Hashes Update Paths Move Group State to its own top-level section Main PR: Change LeafNode to have the required content: HPKE key for TreeKEM Credential Parent hash Capabilities Extensions Signature Change KeyPackage to refer to LeafNode for internals, plus: HPKE key for Welcome Lifetime Extensions Signature Add continues to send KeyPackage Update and Commit send LeafNode instead of KeyPackage Remove and Sender refer to LeafNodeRef instead of KeyPackageRef We should probably do the preparatory PR regardless of this issue.
Discussion on working call: General agreement on the approach Should sign group_id when possible Include in TBS if we at least have a flag for pre-published / in-group Or we can store it Or we could have independent structs for pre-published / in-group leaves Do we need extensions at both levels? Capabilities / lifetime should probably be promoted to fields
Many protocols which have an extensibility mechanism have a way to indicate that understanding an extension is mandatory for certain behaviors. For MLS, this would mean having a way to require a member understand an MLS extension before it can join a group. The three extension types defined currently are: MLS ciphersuites, MLS extension types, and MLS credential types. One logical way to add mandatory extensions would be to pick one of these types (the MLS extensions type) and use the high order bit or a specific range to indicate that a member must understand and implement the extension to join a group which uses that extension. The IANA values could be changed as follows: Values from 0x8000-0xffff indicate understanding the extension is required 0x7f00 - 0x7fff Reserved for Private Use (not required) 0xff00 - 0xfff Reserved for Private Use (required) If a required ciphersuite or credential becomes necessary, a new extension type could be created to add an extension in the KeyPackage or GroupInfo which would be required and would indicate support for the mandatory ciphersuites or credentials.


In order to prevent some other entity from adding an MLS client that does not support a mandatory extension, we already have the KeyPackage Client Capabilities, which lists which extensions are supported by the client.
Note that though this might seem "now or never", I don't think it really is. Consider TLS by way of analogy -- it has no mechanism for specifying that extensions are required. But if a server gets a ClientHello that is missing some extension that it requires, it can just abort the handshake. Likewise in MLS, the member adding a new joiner to the group can examine that joiner's KeyPackage to see if they support the extensions needed for the group. So I think you could implement this as a non-mandatory GroupContext extension, which would state the extensions required by the group so that all members apply the same requirements for new joiners.
While you can implement this "out-of-band", that makes it implicit rather than explicit behavior.
Discussed at 20211004 interim, liked this functionality. But, instead of IANA registry use field (or extension) in group context to indicate which extensions are required. NAME to generate PR.
Discussed with NAME and incorporated this functionality into PR


Explain the different use-cases on specifying interfaces to
There's something obvious I'm not seeing: if I want to specify a multicast or link-local address for an endpoint, why not simply specify that address? What's the use of adding the interface into it? Some addresses will inherently limit interfaces; I thought interface preference was about preferring wifi to 4G, etc.
Like, in section 6.1.1:
Multicast groups can be scoped (see RFC7346), thus, may only be available on certain interfaces or even have different meanings based on the interface. So for Interface- and Link-Local scope, specifying the interface is strictly required. For others use cases (like coping with non-unique use of RFC1918 addresses) this may also be helpful.
Why does the API have both the ability to say LocalSpecifier.WithInterface and to set interface requirements on TransportProperties? Why not just keep the latter and remove the former?
There's history here: LocalSpecifier.WithInterface predates explicitly setting the interface name in interface requirements. There might be reasons to keep this: LocalSpecifier is more likely to show up in application UI than in transport properties. Any text proposed to keep both would need to have an unambiguous way to resolve conflicts between the two. This might be a source of hard-to-debug errors.
To discuss next interim


…ument, dealing with issue
handling different views (7.0) .... some would like to have different views, This document deals with the view that the Internet gets from the CPE(s) only.


This closed As we have no methods on a connection object that query properties, cansend/canreceive also became connection properties. As with all the other connection properties, these are indeed a little underspecified. I want to keep it that way till we fix it for all connection properties with and
Aehm… that comes surprising – NAME why didn't you bring this up in ? Do you think this pull-request is the right place to discuss this issue? I would prefer we merge it now and make a new issue for the question whether the uni-directional connection should be more reflected in the connection. I am not particularly found on keeping it a selection property but would like to have the concept of unidirectional connections rather sooner than later. Our consensus in was that unidirectional connection should use the same abstraction for QUIC unidirectional streams, multicast sources/sinks, and half-closed connections – despite they are constructed in completely different ways. The Selection property is just for the QUIC style ones…

Aehm… that comes surprising – NAME why didn't you bring this up in ? Do you think this pull-request is the right place to discuss this issue? Happy to move the discussion back over to the issue if you like. Will continue the thread here for now though since you've got points to address below. fine, but keep open then, because adding the selection property is possibly-necessary but definitely-not-sufficient to fully address unidirectional connection semantics. good, I agree with this. then I'm confused why this PR purports to since it only addresses part of the issue...?
NAME agreed. The question (and discussion) was about support for including some support for unidirectional connections (with focus on QUIC and half-closed), but omitted details on multicast, as this has not laned yet. So indeed, this pull-requests does everything requested by , but does not fully capture the topic. I will move the open issues (Multicast support, is the Selection Property enough, find some place for more explanation of Uni/Bidi Streams) to once this PR is merged.
In Section 9 – "Setting and Querying of Connection Properties" – the properties of an established connection and path are heavily underspecified. Should be fixed along with .
I'm working on this issue within our pull request for , using the terminology as simplified there.


For Section 9, I'm proposing the following: An application can query Connection Properties on a connection. Connection Properties include the status of the connection and whether it is possible to send and to receive data on it. (One of them might not be possible, e.g., in a unidirectional connection.) Additionally, Connection Properties include the Connection's Transport Properties. Transport Properties include Selection Properties, so the application can know which Protocol Selection Properties had been specified, and which ones are actually supported by the protocol that has been chosen. For Establishing connections (i.e., we are not done racing yet, the final protocols have not been selected yet), the application gets the Selection Properties that had been specified on the Preconnection earlier. For Established, Closing, or Closed connections (i.e., the protocols have been selected), the application learns whether the Selection Properties are actually provided by the selected protocols. For example, if the application specified earlier, "Control Checksum Coverage: Prefer", now it will get "Control checksum coverage: True", indicating that on this connection it can indeed control the checksum coverage. Transport Properties also include Protocol Properties (Generic and Specific). These Protocol Properties can still be modified by the application. Basically, Protocol Properties are the only thing that the application can still set, everything else it can only query at this point. Finally, the application can query properties of the path. Not sure how well we have to specify them, probably this part will be implementation-specific just like, e.g., the Interface Instance or Type. Does everyone agree, or is there anything to discuss here? For me this is not a big change, it's just putting what was already there in terms of . The only thing I'm wondering if whether the Protocol Selection Properties of the finally chosen protocols are still "Selection Properties", as the selection is already done. That's why they were called "Transport Features" before, but now I want less terms and they're almost the same thing...
OK - so I commented on these things before - but in these things I think I agree. I'd personally prefer to keep the features as attributes implemented in the transport (etc) and the properties as the things requested. Indeed this begs the question about what to call the resulting transport when you selected properties and now get a transport. I think still calling them (for consistency) properties seems really good to me. :-).


As QUIC has unidirectional streams, we might want to be able to accommodate them in our transport API. Do we want to handle them fundamentally different from a half-closed connection? This should match the decisions made in .
Side note: we don't support half-closed connections to begin with. As for unidirectional streams, is this the final decision in QUIC's design, or might it change? I'd suggest postponing this until we can be sure.
NAME regarding half-closed connections: we don't have any top-level state in the connection for being half-closed. However, being able to express that a message is final in a given direction when sending allows the same functionality. As I've discussed before, we absolutely need the ability to express sending a TCP FIN, but I whole-heartedly agree it doesn't need to be a top level concept. I think this is somewhat different from half-closing, since a unidirectional stream never allows sending on one end. You could imagine that it is a connection object that returns an error if you ever try to send on it, etc. If you wanted it to look like half-closing, you could open a connection (stream), and then mark it complete in a direction immediately? But that's a bit odd.
All ok, I agree with your suggestion to fin-mark a message
I agreee with NAME regarding half-closed. My suggestion is to explicitly state that connections can be uni- or bi-directional and to add a method to query that (cansend / canrecv). This aligns nicely with final messages after which can_send becomes false. I can do a PR for that.
Thanks! I like this
Still missing unidirectional stream for multicast. – please continue discussion of multicast aspects in The connection properties (can send/receive data) are still a little under-specified - please discuss in details in – we should fix this together with .
We need unidirectional connections. You know, for multicast. And ICN. And unidirectional streaming protocols.
This is a dup of , which has more discussion
I am re-opening this ticket as only dealt with unidirectional streams in unicast context (added with PR ): Current status: The current model for unidirectional streams supports half-closed connections and QUIC style unidirectional streams so far.


We don't know yet whether it is sufficient to have canread/canwrite property on the connection level to model unidirectional connections We don't have pre-connection methods to create multicast sessions yet
there's a selection property for this, tagged discuss, which we haven't discussed yet. I'm moving this down to the appendix as part of my restructuring in my work on
If help is still wanted here, I'm maybe up for an attempt or 2 at adding multicast support. Has there been some prior discussion I can review about rough ideas on pre-connection methods for multicast sessions, or should I just try making something up?

ok, with the caveat that we need to keep multicast as an open issueLGTM About the multicast concern: I agree that it would be good if this could function for multicast reception too, and I couldn't tell if this is suitable for multicast. I suspect that multicast support is much harder anyway - see RFC 3678... so for now, this is a good step forward IMO, and let's discuss how this relates to multicast when we see a concrete text proposal that addresses it.


Solves issue (from review comments by NAME : URL)
In section 5.4 you have the text requestpiv: contains the value of the 'Partial IV' in the COSE object of the request (see Section 5), with one exception: in case of protection or verification of Observe cancellations, the requestpiv contains the value of the 'Partial IV' in the COSE object of the corresponding registration (see Section 4.1.3.5.1). I am unclear how/why this is different for observations. A cancelation is a message, so the IV is the request. A re-registration is a request message, any response would correspond to that request. The only interesting question has to do with updating the MID on a re-registration but not how PIVs work for this field.
Another case to make sure that works Client - please cancel my observation Server - I don't have an observation for you, but sure I am willing to tell you I canceled it. What request PIV would I use in the AAD?
Yes, the verification of cancellation would fail since the server does not have the initial registration's partial iv saved, if it does not have the observation stored. So OSCORE would fail, which is not right. We have reverted to previous version (request_piv is not exception for cancellations) in c94314321 , but we want to add some security considerations about Observe and cancellations before closing this issue. Section 4.1.3.1 - I am unclear why an OSCORE error response can be cached by an OSCORE unaware intermediate would be cached, but a success message is never going to be cached. Based on this, I don't plan to set an outer Max-Age option. In section 5.4 you have the text requestpiv: contains the value of the 'Partial IV' in the COSE object of the request (see Section 5), with one exception: in case of protection or verification of Observe cancellations, the requestpiv contains the value of the 'Partial IV' in the COSE object of the corresponding registration (see Section 4.1.3.5.1). I am unclear how/why this is different for observations. A cancelation is a message, so the IV is the request.


A re-registration is a request message, any response would correspond to that request. The only interesting question has to do with updating the MID on a re-registration but not how PIVs work for this field. Section 6.1 - Is a registry needed for the leading byte of compression? Behavior if bits 0, 1, or 2 is set in the flags byte on decode? Section C - given the way that my system is implemented, it would be nice if the outputs included the first full IV to be used for both the sender and the recipient. That would allow for a test that the combination of ids and common ivs is done correctly. In my case I do not have the shared IV available for testing as I immediately or in the id.


Thanks for merging. I had a small fix to the caption of table 1 which is now .
(This was original raised in and now being split out) (Michael Kay) want to confuse the JSONPath spec by going into detailed comparisons at the risk of contradicting the normative text. (Glyn Normington) (Michael Kay) It seemed to be important in 2007, while argumenting to have something like XPath for JSON. If nowadays the terminology used has changed significantly with XPath 2.0 and 3.0, we better leave that comparison table 2 out. I am quite passionless here. At the IETF 110 meeting consensus was raised that inclusion of XPath in the Appendix section would be the most appropriate way to reference to it.
Closed in
Great improvement!Additions / Replacements of high value ... thanks


NAME It would be good to address NAME comments in this PR. I have made some suggestions, but feel free to pick them apart if you are keen to retain "truthiness" and "falsiness". BTW perhjaps I struggle with the latter term because of the existence of some .
Indeed. It is not that easy to say here what needs to be said, so I'm still in thinking mode. Thanks for the pointer to English slang; of course I was completely unaware. We don't want to use the fooiness terms. Interestingly, the remaining grammar does not seem to have a place where JSON values are implicitly converted to Boolean; this is now all explicit unless I'm missing something. So maybe we don't need this table (and its legend) at all?
You're right! The two occurrences of are as follows. which simply tests for non-existence of a value(s) selected by a path and does not depend on the actual values themselves. which negates a boolean expression. Looking at the details of , there's no way it can result in a value which might need to be converted to boolean. So please can we scrap the table and kiss "fooiness" goodbye once and for all?
I think we should first merge it and then delete it, in case we need to resurrect it later.
what's about ... which can surely be converted to a negated form. But sometimes someone doesn't want to do that ... like in any programming language. Nevertheless I second to kick fooiness out. As a minimalist I am always a friend of kicking unneeded things out.
Comparisons already yield Boolean values, as does /.
Well, then in fact I misunderstood Glyn's comment above ... I agree to remove the conversion table as superfluous.


We have inconsistent definitions for Ack-Eliciting Threshold, which probably has people implementing this differently. In Section 4: In Section 7: The intended definition is the one in Section 4, so fixes and makes this consistent.
The document uses MUST in multiple places, however, as discussed in the new proposed text for the security considerations (see PR ) the requester cannot enforce any ACK strategy and there might be reason like practical limitation or an overload situation where the ACK sender simply decides to send less ACKs. So the question is really can to requirements be MUSTs or is SHOULD more realistic and correct?


Expands the key parameter to allow it to be an object or a string, to facilitate methods with multiple parameters such as HTTPSig.
To edit notification comments on pull requests, go to your .
Some key proofing methods have additional options that could be signaled in the GNAP protocol structure. Notable, HTTP Message Signatures has the ability to use different HTTP Signing Algorithms and different HTTP Digest Algorithms. The field could be changed to an object to accomodate this kind of use, allowing each proofing method to define its own parameters: Each method can also define "Default" values for missing parameters, allowing this to collapse in the simple case back to a string as it is today: These string values would have a deterministic expansion defined in the core protocol.
Note that the httpsig document itself wavers between and and does not require either of them. Though maybe this is OK if the current document makes mandatory for the appropriate cases.
There are some updates pending in the Digest draft -- once that's out, we'll reference using as that's the most appropriate for our use case, and examples will be updated.


... as promised for yesterday (oops)
ad "what is sub": it's DNS-SD's syntax for subtypes (RFC6763 Section 7.1). Might also be URL ("Subtype strings are not required to begin with an underscore, though they often do").
Looks good to me.
There are several ways specified for finding a host serving an RD: static (unicast or anycast, addresses or DNS? could contain full RD path (as in LWM2M)?) various neighbor discovery derived RDAO the border router (ABRO) "other ND options that happen to point to servers (such as RDNSS)" might-be-defined DHCPv6 options multicast (all-coap-nodes + .well-known/core; serves the path by design) There is an open issue to describe how this can be used with DNS-SD (), and it came up 2017-04-07 that discovery via mDNS by those mechanisms might be possible but is not advisable. Can we give a set of discovery options that should be supported by all general-purpose clients and servers to avoid fragmentation where one vendor's clients expect an RDAO while the other vendor's server relies on clients doing a multicast? Can we say anything about which options are recommended to use, and which are rather to be viewed as shortcuts in extremely constrained cases? Using RDNSS would be a candidate for such a statement. Maybe those cases are better described as "explicitly configured to use whichever RDNSS is announced", so this is something that's better than static configuration but still not to be expected from a generic client.
The new section 4 introduced in URL takes care of this.


This draft attempts to address all of the issues identified during with the exception of Dealing with overload situations where further guidance has been requested from early implementers of webpush. Hi, This review is an early, i.e. pre IETF Last Call TSV-ART review. The TSV-ART reviews document that has potential transport implications or transport related subjects. Please treat it as an IETF Last call comment if you don't want to handled it during the AD review. Document: draft-ietf-webpush-protocol-09 Title: Generic Event Delivery Using HTTP Push Reviewer: M. Westerlund Review Date: Sept 27, 2016 Below are a number of comments based on my review. The one with transport related subject is the overload handling in comment 4. Section 3: So the Security Considerations do require use of HTTP over TLS. However, I do wonder if there would be a point to move that requirement up into the relevant connection sections, like 3. Especially as when one reads the confidentiality requirement in Section 4 for the message one wonders a bit why it is not explicitly required in section 3. Section 5.2: TTL = 1*DIGIT Shouldn't the upper range for allowed values be specified here. At least to ensure that one doesn't get interoperability issues. Section 7.2: To limit the number of stored push messages, the push service MAY either expire messages prior to their advertised Time-To-Live or reduce their advertised Time-To-Live. Do I understand this correctly, that theses options are push service side actions that is not notified at that point to the application server? Instead it will have to note that the message was early expired if it subscribes to delivery receipts? Dealing with overload situations Reviewing Section 7.1 and other parts I find the discussion of how overload situations of various kinds are dealt with missing some cases. So the general handling of subscriptions are covered in Section 7.1 and with a mitigation of redirecting to another server to handle the new subscription. What I lack discussion of are how any form of push back are handled when first the deliver of push service to UA link is overloaded. Is the assumption here that as the push service can store messages the delivery will catch up eventually, or the message expires?


How does one handle a 0-RTT messages when one has a queue of messages to deliver, despite having a UA to Push service connection? The second case is how the push service server can push back on accepting new message when it is overloaded. To me it appears that the load on a push service can be very dynamic. Thus overload can really be periods. Thus, what push back to application servers is intended here? Just, do a 503 response on the request from the application server? I do note that RFC 7231 does not appear to have any guidance one how one sets the Retry-After header to spread the load of the retries. This is a known issue. And in this context with automated or external event triggered message creations the push back mechanism needs to be robust and reduce the issues, not make them worse. I would recommend that some recommendations are actually included here for handling overload from application server message submissions. Life of subscription in relation to transports I find myself a bit perplexed of if there are any relation between the subscription and the relation to an existing transport connection and outstanding request, i.e. the availability to receive messages over push. I would guess, that there are no strict need for terminating the subscription even if there are no receiver for an extended time. However, from an application perspective there could exists reason for why a subscription would not be terminated as long as the UA is connected, while any longer duration of no connections could motivate the subscription termination. I personally would like a bit more clarification on this, but seeing how these issues are usually handled around HTTP, I would guess the answer, it will be implementation specific? Still there appear to be assumptions around this, why it wouldn't matter that much, but that is only given that one follows these assumptions. Unclarities which requests that require HTTP/2. The specification is explicit that some request can be performed over HTTP/1.x. However, it is not particular clear which requests that require HTTP/2. I assume all the GET requests that will hang to enable PUSH promises needs to be HTTP/2? Maybe this should be clarified?


Cheers Magnus Westerlund Services, Media and Network features, Ericsson Research EAB/TXM Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: EMAIL


(well, the priority framework is still confusing, this PR makes it clear that that is intentional, and why)
Martin (I think) said that he'd check this offline after the Sep 11 interim.
At 8.1.2 you say lower values have higher priorities for connPrio. But later, at msgPrio, higher values have higher priority, and in the examples where you speak of the interaction of connPrio and msgPrio, you imply that higher means higher for both properties. Please check for consistency and clarify.
Lower values having higher priorities for connPrio is a remnant that we must have missed when we flipped this, e.g. PR which I don't know... too many iterations have mangled the text.
Aha, now I see what happened: following some more PRs, also , in PR , NAME re-introduced some text saying that sends on Connections with lower-priority values will be prioritized over sends on Connections with a higher-priority value. This reverses the logic for some part of the text - I suspect that NAME (very understandably!) forgot what happened and this created this mix. We have been editing these documents for way too long!
I'm not sure the priority framework really fits together. Sec 6.4 says we 'should' do something that sounds like WFQ, but 7.1.5 allows the application to decide what happens. Meanwhile message priority suggests a strict priority-based scheduler. Meanwhile, in sec 8.1.3.2 "Note that this property is not a per-message override of the connection Priority - see Section 7.1.3. Both Priority properties may interact, but can be used independently and be realized by different mechanisms." At the risk of overindexing on a partly-baked draft in httpbis, how would I implement strict priority of HTTP/3 streams over a taps API that implements QUIC? Would I need to request strict priority in both connection priority and message priority? Or I guess connection priority would be sufficient?
We seem comfortable with the mechanisms in the API, but we should have more text connecting the various sections explaining priority.
My comment concerned "7.1.3. Priority (Connection)", my thought was this just influences the sender-side to control queuing within a connection group.


If so, if it worth calling this property "Group Priority" and explain this is sender-side?
I find the priority framework perhaps overspecified at the connection level and underspecified at the message level, with the interaction between the two left explicitly unstated. I would almost rather see the priority type and meaning left completely implementation-specific; otherwise, my suspicion is that someone will write an application using numeric priorities, declare victory when it works fine on one platform, and not understand that the behavior is not universal. In general, I think if TAPS is going to produce a consistent, easily-understandable, and portable API, it needs to stick to easily-understood abstractions. Message-level priority is sort of like the TCP URG mechanism (though better specified and more useful, for sure), but I'm thinking urgent messages sent explicitly out-of-band (e.g., new Connection) with implementation-specific QoS will produce more consistent, predictable, and understandable outcomes in the pessimal case.
Ok for me (and thanks for doing this!)Some nits, but I believe this addresses my concerns in the issue.


This tries to write something small but specific about Network Policies
LGTM
In Sec 2: Should Section 3.2 also talk about network policies, e.g. a certain network supports a DSCP that the application desires?
As discussed in Feb 2021 interim, this seems like a rabbithole. Gorry will figure out whether it is and write language if not, or close if so.
I'd like to add a couple of lines of text here to bullet 2 that discusses how you might learn that an attached network supports certain features - e.g. through a PvD, routing advertisement, or local discovery method, and suggest that this could enable a system to know which paths have specific characteristics.
I propose this as a starter: When additional information (such as Provisioning Domain (PvD) information {{RFC7556}}) is provided about the networks over which an endpoint can operate, this can inform the selection between alternate network paths. Such information includes network segment PMTU, set of supported DSCPs, expected usage, cost, etc. The usage of this information by the Transport Services API is generally independent of the specific mechanism/protocol that was used to receive the information (e.g. zero-conf, DHCP, or IPv6 RA). Thoughts... ?
Tried to create a PR to add some policy to the path selection
I think the policy is separate from the API.LGTM


The first commit is editorial. I removed all the DH terminology I could find and replaced it with KEM terminology. The second commit is related to URL It would massively reduce complexity of implementations if people were able to rely on HPKE to do all private key parsing, key validation, public key computation, etc. Currently, all the information in the deleted CFRG and NIST sections is either redundant (performed by HPKE) or outdated and performed correctly by HPKE (e.g., old P-256 DH secret representation). Instead of having all this duplicated, it would be easier to keep it in one place. An issue with the new definition of : Repeatedly calling can be computationally expensive. Each call requires computing the group hash (which, okay, it could be cached) and serializing a struct. It would be nice to do something that's cheaper but still ties context into the secret key generation.
Update: This now uses HPKE's function to do all the heavy lifting


All protocol request messages contain a field, which allows aggregators to service multiple tasks from a single set of endpoints. The exception is : since it is an HTTP GET request, there is no body, and thus no place for the client to indicate the desired to the aggregator. We don't want to introduce a request body to , because then it would have to be a POST instead of a GET, and that would make it harder for implementations to cache HPKE config values. So instead we have clients encode the task ID in RFC 4648 Base16 (a.k.a. hexadecimal) and provide it as a query parameter. See issue
My goal here is to enable our aggregator implementations in the interop target to use one HPKE config per task. The alternative to this would be for us to use aggregator endpoints that somehow incorporate the task ID, as I described , which is already permitted by the spec as written.
The Base64 alphabet includes , and , which means you have to URL encode (a.k.a. percent encode) Base64 strings before you can use them in a URL, which is a chore and yields less readable URLs (not that 64 character hex strings is especially user-friendly). An alternative would be to use RFC 4648's , omitting the padding characters as suggested in since task IDs are of a known length.
Gotcha. I think the main thing is to be consistent. I would either: Change this PR to use base64url; or Tack on a commit that makes all encodings of the taskID (except those that appear in the body, of course) the same (i.e., hexadecimal). I think (2.) would be my preference.
I agree with the consistency argument. I'm leaning towards using everywhere because it's more compact than Base16/hex, and also I think implementations are less likely to be surprised by case requirements in base64url (i.e., it's obvious that base64 is case sensitive, but you have to read RFC 4648 attentively to notice that it mandates uppercase hex strings).
Base64Url sounds good to me. I took a quick look and it appears that most standard base64 libraries also support the URL encoding.
I will clean this up and merge it once I have implemented it in Janus and convinced myself it's sound.
SGTM, but why not base64 encode the taskID for consistency with URL


Just some nits.
The public key name and type have been changed in , as NAME suggested on the mailing list.
NAME beat me to it!
oh looks like the travis build is failing for some reason
NAME I have no idea why pushing that worked ...
awesomesauce. it's probably some temporary failure while trying to fetch the new references or something


On the mailing list, NAME and NAME pointed out some risks arising from the default virtual host behavior of some web servers. This PR integrates the changes they suggest, namely (1) removing the "tls" option from the challenge, and (2) adding iterations to the challenge. This PR is based on top of and .
Sorry, feel free to tell me to go away, but reading the backing decision to drop HTTPS for SimpleHTTP doesn't make sense to me. If I understand everything correctly, you control the originator of the HTTPS requests and the requests are always sent to domains. So why can't you just enforce to always send the Host header and this wouldn't be an issue?
From : behaviour that if a default TLS/HTTPS virtual host is not configured explicitly, one will be selected based on the ordering of vhosts in the webserver configuration (in practice, this often amounts to alphabetical ordering of files in a configuration directory). As far as I know Apache does the exact same thing for nonencrypted HTTP hosts (this is also acknowledged by a later mail in the thread), so the reasoning is a little weird. I suppose the idea is that hosters are more likely to have HTTP configured correctly rather than HTTPS?
The section on the "" registry says that "Fields marked as "client configurable" may be included in a new-account request". This seems like a copy-paste-o, and perhaps should say that such fields may be included in a new-order request.
Good catch. I opened URL to fix. Thanks! Apache (and I gather nginx too) have the subtle and non-intuitive behaviour that if a default TLS/HTTPS virtual host is not configured explicitly, one will be selected based on the ordering of vhosts in the webserver configuration (in practice, this often amounts to alphabetical ordering of files in a configuration directory). URL URL This creates a vulnerability for SimpleHTTP and DVSNI in any multiple-tenant virtual hosting environment that failed to explicitly select a default vhost [1]. The vulnerability allows one tenant (typically one with the alphabetically lowest domain name -- a situation that may be easy for an attacker to arrange) to obtain certificates for other tenants.


The exact conditions for the vulerability vary: SimpleHTTP is vulnerable if no default vhost is set explicitly, the server accepts the "tls": true parameter as currently specified, and the domains served over TLS/HTTPS are a strict subset of those served over HTTP. DVSNI is vulnerable if no default vhost is set explicitly, and the hosting environment provides a way for tenants to upload arbitrary certificates to be served on their vhost. James Kasten and Alex Halderman have done great work proposing a fix for DVSNI: URL That fix also has some significant performance benefits on systems with many virtual hosts, and the resulting challenge type should perhaps be called DVSNI2. The simplest fix for SimpleHTTP is to remove the "tls" option from the client's SimpleHTTP response, and require that the challenge be completed on port 80. URL Alternatively, the protocol could allow the server to specify which ports it will perform SimpleHTTP and SimpleHTTPS requests on; HTTPS on port 443 SHOULD be avoided unless the CA can confirm that the server has an explicitly configured default vhost. The above diffs are currently against Let's Encrypt's version of the ACME spec, we'll be happy to rebase them against the IETF version upon request. [1] though I haven't confirmed it, it's possible that sites that attempted to set a default vhost are vulernable if they followed advice like this when doing so: URL ; an attacker need only sign up with a lexicographically lower name on that hosting platform to obtain control of the default. Peter Eckersley EMAIL Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993


introduce numbered sections for YAML NAME since each media type is defined in its IANA consideration, would it be ok for you if we just add a section for YAML? Feel free to PR with another proposal.
NAME could you PTAL ? :)
to be honest, i prefer definitions to have URIs and not just registrations. but if we have URIs, that's already a lot better than not having URIs! thanks!
it's maybe just OCD (and because it's very useful for URL to have linkable references) but i think it's nice to have numbered sections for everything that's being defined in the spec. in this case, i suggest to have a numbered section for each of the four media types, and to have a brief explanation of what it identifies. that way, each definition is self-contained and can be easily referenced when necessary. NAME NAME


…transport protocols Also tighten up description of the assumed protocol stack in (what is now) Section 6.1. Note that the UDP and TCP sections have been flipped in order, to improve section flow and clarity.
NAME - If you have a moment before our call on Friday to take a look at this PR, I'd appreciate it. I think it's important to to get that right, in order to address both the INTDIR and TSVART reviews.
From NAME As a bit of transport commentary, I don't find the setup of Section 6 compelling. While UDP is a transport in a technical sense, for the purpose of media, it is almost always a layer upon which the protocol doing the congestion control work runs. To that end, QUIC is just another more standardized case of this, just like SCTP over UDP. Rather than talking about "UDP's behavior" vs "TCP's behavior", I suggest talking about how applications over UDP for media behave vs applications over TCP for media behave.
NAME - I need to look at this more closely. I understand your point about UDP, but (because UDP is not a real transport layer, while TCP and QUIC are), I suspect (without looking closely yet) I'm going to be making sure that I explain this more clearly, without trying to explain the behavior(s) of applications running over TCP and QUIC. As an aside, I'm trying to make this clearer in drafts I'm targeting forwards Media Over QUIC/MOQ, so I actually DO believe you ... Please await results.
A +1 from NAME 's review (URL): Section 6. Evolution of Transport Protocols and Transport Protocol Behaviors I really wonder whether UDP vs. TCP vs. QUIC is actually the relevant distinction. What may actually matter are the transport services provided by the protocol stack (e.g., RFC 8095). I fully agree to a related comment in the INTDIR review.
After looking at this issue. I agree with both NAME and NAME that the emphasis should be on the interaction between (see new section describing this) media transport protocols and the transport services provided by underlying transport protocols. I'm moving the formerly-UDP section below the formerly-TCP section, because it's easier to describe what UDP is NOT doing after describing what TCP IS doing.


I'm also moving one paragraph into the formerly-TCP section from Section 6, because it is specific to ABR strategies that assume a reliable transport. More news to come, when I create a PR for this issue ...
We think is now mergrable. Reviewer: Michael Scharf Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC EMAIL if you reply to or forward this review. This informational document surveys network and transport protocol issues that affect quality of experience for streaming applications, in particular video. The overview covers many topics across different technologies. Readers may only be familiar with a subset of these topics and could therefore learn quite a bit from this kind of tutorial. Nonetheless, it remains somewhat unclear what the actual objective of some of the text is. For some topics, quite a bit of technical background is provided, but the discussion is not really comprehensive. In many sections, the document neither derives technical challenges, nor system/protocol requirements, nor practical usage guidance. It is just a kind of tutorial. Quite a bit of text also presents ongoing IETF work, and an RFC with this scope may thus get outdated soon. Section 6.2 deals with topics owned by TCPM. In similar past documents, I have asked for a TCPM presentation prior to an IETF last call in order to ensure that owners of running code are in the loop. I believe this strategy has worked well in the past. Having said this, as TSV-ART reviewer I don't strongly disagree with a publication. All these issues may just be OK for an informational RFC. Some more specific comments: Section 3.2.1. Recognizing Changes from an Expected Baseline This section apparently assumes relatively static path properties, e.g., fixed network connectivity. It would be more useful to analyze the impact of Wifi and 4G/5G networks in one place.


Some of this follows later in sections 3.2.1 and Yet, the split between these three sections is unclear. Having a discussion about today's Internet path characteristics and the dynamics at one place could be more useful. The text could also better distinguish between what matters to endpoints and considerations relevant only for middleboxes (such as passive monitors). Section 3.3 Path Requirements The statement "to find the bandwidth requirements for a router on the delivery path" may assume that the bottleneck on the path will be routers. Yet, on a path the bottlenecks could also be a link layer device (e.g., an Ethernet Switch, a Wifi access point, etc.). RFC 6077 (specifically Section 3.1.3) also explains that issue. A better wording may be "to find the bandwidth requirements for a delivery path". Section 3.6. Unpredictable Usage Profiles / Section 3.7. Extremely Unpredictable Usage Profiles I am not fully convinced by the distinction between "unpredictable" and "extremely unpredictable". To me, these two sections could be merged and maybe also be shortened. More specifically, Section 3.7 lists a lot of statistics from the past. What is IMHO a bit missing in Section 3.7 are actual operational considerations. For instance, are there any lessons learnt for the future? Note that Section 3.6 has a reasonable conclusion at the end. Section 4. Latency Considerations and Section 4.1. Ultra Low-Latency I am surprised by the definition "ultra low-latency (less than 1 second)", as well as some of the other numbers. For other real-time communication use cases, "ultra low-latency" would probably imply a latency requirement of the order of one millisecond. For instance, isochronous traffic for motion control in industrial networks may require a latency of 1 ms, and such "ultra-low latency" requirements are discussed elsewhere, e.g., in the DetNet WG. The terminology in this section should be better explained to readers dealing with networked systems with much harder latency requirements. And a reference should be added for these definitions in the context of video streaming.


Section 5.5.2 Head-of-Line Blocking If Head-of-Line Blocking is indeed a relevant operational problem, it would be useful to add a corresponding reference (e.g., with measurements). Section 5.5.3. Wide and Rapid Variation in Path Capacity The statement "As many end devices have moved to wireless connectivity for the final hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detction have emerged from radio interference and signal strength effects." could be moved to earlier parts of the document. Quite a bit of new computers apparently only have Wifi connectivity and no Ethernet port, i.e., Wifi may just be their default. Also, wireless may not only be used on the last hop, for instance in meshed setups. This may make the problem even harder. Section 6. Evolution of Transport Protocols and Transport Protocol Behaviors I really wonder whether UDP vs. TCP vs. QUIC is actually the relevant distinction. What may actually matter are the transport services provided by the protocol stack (e.g., RFC 8095). I fully agree to a related comment in the INTDIR review. Section 6.1. UDP and Its Behavior UDP is also used for encrypted tunnels (OpenVPN, Wireguard, etc.). Does encrypted tunneling really have no operational impact on streaming apps other than circuit breakers? (I am thinking about 4K streaming over OpenVPN and the like.) Section 6.2. TCP and Its Behavior This text should IMHO be presented and be discussed in TCPM. Personally, I am not convinced that this document is a good place for discussing the long history of TCP congestion control. If the objective of the document is to provide a tutorial, IMHO it would be more useful to briefly explain the state-of-the-art in year 2022. Some further specific comments on TCP congestion control: It is surprising that RFC 5681 is not referenced.793bis has normative statements regarding congestion control, and most stacks are compatible to what is written in 793bis. Several operating systems use CUBIC by default and support standard Reno. Another general good reference for TCP standards is RFC 7414.Does ECN, DCTCP, etc. really not matter at all, for instance, if a data center hosts video playout servers?


Section 6.3. QUIC and Its Behavior As already noted, the discussion about head-of-line-blocking would really benefit from backing by a reference. Section 7. Streaming Encrypted Media As far as I know, streaming users sometimes use encrypted tunnels such as OpenVPN or WireGuard (or IPsec) to access video content. I may miss something, but it is unclear to me how that fits into the categories presented in Section


Why is it that media type registration is a journey of discovery each and every time? It's like the coastline paradox: the closer you get, the more detail resolves. Also, each requirement makes sense in isolation, but if you need an entire RFC to explain it, maybe something has gone wrong.
no strong feelings on this one.


I have committed all request changes. Thank you for the refinements.
The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete. First, IANA understands that this document calls for the addition of "URL" to the Special-Use Domain Names (SUDN) registry established by RFC6761. RFC6761 specifically requires that any request for a Special-Use Domain Name needs to contain a subsection of the "IANA Considerations" section titled Domain Name Reservation Considerations. The current draft does not have such a section. IANA Question --> Could the authors either conform to the requirements of RFC6761 or provide explicit guidance as to why that section is not appropriate? Second, in the Transport-Independent Locally-Served DNS Zone Registry on the Locally-Served DNS Zones registry page located at: URL a new registration will be made as follows: Zone: URL Description: DNS Resolver Special-Use Domain Reference: [ RFC-to-be ] The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. For definitions of IANA review states, please see: URL


Had offline conversation with Lucas, conclusion was that this is good enough to merge to allow interop - we'll have plenty of time to figure out details in subsequent issues and PRs.


As suggested by Éric Vyncke, mention that the new ciphertext record format provides ContentType encryption and per-record padding in both abstract and introduction.
URL Update from Éric re: Section 6
About "-- Section 3 --, DTLS / zero-length CID" "An extension type MUST NOT appear in the ServerHello unless the same extension type appeared in the corresponding ClientHello." The "zero-length CID" therefore is mainly used for the very common cases, where only the clients are required to send such a CID, but not the server. Maybe adding a hint to RFC5246 7.4.1.4 will help?
About "-- Section 6 --" Yes, that's still very complex: First, processing the record seems to be easier (less restricted), than use a changed source address for sending data back. Using a changed source address for sending data back to, is not generally solved. There are some special case, e.g., if the data sent back is very small, there is no risk (at least, none has explained one). There may also be some upper-layer mechanisms, which helps out (e.g. for coap). And there is a idea of a general solution , but that will require more time. Because of the required time, the idea was to release this spec without RRC and postpone that general work (see also issue ).
also in the abstract ? Some initial attempt at this in
LGTM Éric Vyncke has entered the following ballot position for draft-ietf-tls-dtls-connection-id-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: Thank you for the work put into this document. This specification addresses the IPv4-mainly issue of NAT binding and is still required. I am also trusted the security ADs for section 5. Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.


I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Abstract -- As an important part of this document is the padding, should it be mentioned also in the abstract ? -- Section 3 -- While I am not a DTLS expert, I find this section quite difficult to understand the reasoning behind the specification as little explanations are given about, e.g, what is the motivation of "A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID." -- Section 6 -- I am puzzled by the text: "There is a strategy for ensuring that the new peer address is able to receive and process DTLS records. No such strategy is defined in this specification." Does this mean that there is no way to update the peer IP address ? == NITS == -- Section 1 -- Please expand CID on first use outside of the abstract. -- Section 4 -- Suggest to add a short paragraph as a preamble to figure 3. Currently, it looks like figure 3 belongs to the 'zeros' field description.


From NAME Can we (additionally or in replacement) point to the "HPKE KEM Identifiers" IANA registry created from this table instead? Same for this and "HPKE AEAD Identifiers" registry.


This proposal consolidates normative language into the section on design principles (now requirements), using the suggestions in .
Please review the latest updates!
Early art-art review of draft-ietf-taps-architecture My first observation and request is that the group rethink the separation of the architecture and interface documents. It is a warning-sign that the interface document is a normative reference for the architecture document. As the documents are currently constructed, a new reader cannot grasp the architecture without inferring some of it through reading the interface. Consider reformulating the architecture document as an overview - introduce principles, concepts, and terminology, but don't attempt to be normative. (There are signs that this may already be, or have been, a path the document was being pushed towards). If nothing else, rename it, and acknowledge that the actual architecture is specified using the interface definition. Note that the first sentence of the Overview in the interface document also highlights the current structural problem.
I don't entirely agree with this ART-ART comment: I think I might well agree with moving more of the description to this Arch document, but as discussed before, I also think it useful here to set the actual requirements for the architecture, and to define the architecture. It may need to be much clearer that this architecture consists of more the API.
For completeness, this is the first statement of the interface document review: This document reads fairly well. I have some structural concerns (see the early review of the architecture document). In particular I think this document contains the actual definition of the architecture and some of that is inferential.
Discussion at September 2021 interim: pass through this document with a view toward making it a high level introduction, not an architecture definition: "An Introduction to the Transport Services Architecture". remove normative language from this document (moving it to API, where necessary). move details not useful in a high level intro to API.
I disagree with this conclusion at first pass—we did a specific analysis and pass on this over a year ago, with PR . The normative language and the standards-track aspect was very intentional and something the WG had consensus on. The point is that the API is a specific incarnation of the TAPS architecture, but there are overarching architectural properties that go beyond a specific abstract API.
I completely agree with Tommy here, and recommend we fix this in . We should also of course check for any stray text or missing concepts.


I think it would also be useful to somehow better explain that in figure 3 the API function is ONE part of the system.
See linked PR first please to see if this resolves this?
A PR was merged that addressed important text issues with separation of requirements and overview, and should more clearly set out that the requirements are for the system. The question of whether the overall TAPS systems requirements belong in this ID; the API; or a separate RFC needs some discussion based on the review, before this can be closed.
Many good text improvements in the PR NAME but I noticed two smaller updates in the PR that I think were incorrect. Fixed in
The review comment showed were many places where the wording of architecture can be improved. There are some high level principles that I think should remain in the architecture document. The decision in today's interim is to review the architecture to get this more into a shape that is valuable as a reference, and then check the updated draft.
I now suggest the issues are addressed and we close this issue without moving text between documents
I agree with that; closing.
Overall review: I think we need to keep the normative language for the key features that differentiate the API. I'd really like to use REQUIRED, RECOMMENDED, rather MUST and SHOULD - because these are not protocol operation requirements, but are implementation requirements to conform. This includes requirements based on Minset - where the WG dervied this API: This is after all why the WG worked on Minset as the basis of the API. I suggest we group all the requirements on architecture as short one or two sentence blocks (preferably as a bullet or definition list) collected into a single subsection, so they are easy to find and read and we say that these are the key architectural requirements. We insert this new requirements text either their own section, or in section 1.3 (although I am open to other places where we can call-out the architectural requirements). The following are key requirements, that define the TAPS architecture: It is RECOMMENDED that functionality that is common across multiple transport protocols is made accessible through a unified set of TAPS interface calls. As a baseline, a Transport Services system interface is REQUIRED to allow access to the minimal set of features offered by transport protocols {{?I-D.ietf-taps-minset}}.


A Transport Services system automates the selection of protocols and features and network, based on a set of Properties supplied through the TAPS interface. It is RECOMMENDED that a Transport Services system offers Properties that are common to multiple transport protocols. Specifying common Properties enables a system to appropriately select between protocols that offer equivalent features. This design permits evolution of the transport protocols and functions without affecting the programs using the system. Specifying common Properties enables a Transport Services system to appropriately select an appropriate network interface. It is RECOMMENDED that a system offers Properties that are common to a variety network layer interfaces and paths. This design permits racing of different network paths without affecting the programs using the system. Applications using the Transport Services system interface are REQUIRED to be robust to the automated selection provided by the system, including the possibility to express requirements and preferences that constrain the choices that can be made by the system. If two different Protocol Stacks can be safely swapped, or raced in parallel (see Section 4.2.2), by the Transport Services system then they are considered to be "equivalent". Equivalent Protocol Stacks need to meet the requirements for racing specified in section XX. Applications using a Transport Services system MAY explicitly require or prevent the use of specific transport features (and transport protocols) and XXXinterfaces using the "REQUIRED" and "PROHIBIT" preferences. This allows an application to constrain the set of protocols and features that will be selected for the transport service. It is RECOMMENDED that the default usage by applications does not necessarily restrict this selection, so that the system can make informed choices (e.g., based on the availability of interfaces or set of transport protocols available for the specified remote endpoint). When a Transport Services system races between two different Protocol Stacks, both SHOULD use the same security protocols and options. However, a Transport Services system MAY race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. Transport Services systems MUST NOT automatically fall back from secure protocols to insecure protocols, or to weaker versions of secure protocols. A Transport Services system MAY allow applications to specify that fallback to a specific other version of a protocol is allowed. It is RECOMMENDED that in normal use, a Transport Services system is designed so that all selection decisions result in consistent choices for the same network conditions when they have the same set of preferences.


This is intended to provide predictable outcomes to the application using the transport service. I would then suggest to use lower case within other parts of the document - except were pointed to from here, (we could refer to the requirements subsection, if we thought necessary).
for discussion at the interim, but IMO we could start the interim with a PR based on these suggestions and work from there.
I suspect that we need more protocol-specific properties to be able to talk to various kinds of native protocol peers (other than TCP and UDP: these should already work fine with what we have, I believe). A concrete example: we're hiding stream numbers. In NEAT, we needed to make them configurable though, because we wanted a NEAT client to be able to talk to a native SCTP server, where an application may expect certain type of data to arrive via a certain stream number. I suspect that we may need something similar for a QUIC peer. Should we address this? (I'd say yes) How .. is it a protocol-specific (per-Message) property? (I'd say yes... and perhaps a per-Connection property too, with text explaining that the per-Message one automatically becomes the Connection default unless otherwise specified) What other such things are we missing... what other expectations may e.g. a native QUIC or SCTP application have that we just cannot fulfil with our current system?


Add key for extending sessions. Implements .
I want to be clear that there is no extend-session API here. It's just an indication that the user could do that somehow, in a browser.
NAME correct, there's no specific API to do so. It just indicates if there's a possibility of the user doing so. Future mechanisms for doing so automatically are left for the future =)
Boolean value to add. Suggested names have been and .
LGTM


hopefully addresses issue
I don't think "the same port number as would be used for the same application over TCP" is necessary general-purpose guidance. I would argue for something more like:
Copying from URL There's no requirement that servers use a particular UDP port for HTTP/QUIC or any other QUIC traffic. Using Alt-Svc, the server is able to pick and advertise any port number and a compliant client will handle it just fine. That's already the case, and isn't part of this issue. updates the HTTP draft to highlight this, increasing the odds that implementations will test and support that case. This issue is to track that it might actually be desirable from a privacy standpoint for servers to pick arbitrary port numbers and perhaps even rotate them periodically (though that requires coordination with their Alt-Svc advertisements and lifetimes, which could be challenging) in order to make it more difficult for a network observer to classify traffic (and therefore more difficult to ossify). On the other hand, as we're wrestling with in each of these privacy/manageability debates, removing easy network visibility into the likely protocol by using arbitrary port numbers means that middleboxes will probably resort to other means of attempting to identify protocols and potentially doing it badly, which could result in even worse ossification. (E.g. indexing into the TLS ClientHello to find the ALPN list, then panicking on a different handshake protocol.) There's further discussion on the original issue, but this belongs in the ops drafts, not the protocol drafts.
this kind-of-but-not-really-duplicates , which I'll go ahead and close.
Actually, it's an exact duplicate, given that it points to the same issue. ;-) My bad.
NAME can you check if PR addresses this issue sufficiently? At least for the applicability doc...
Now also PR for the manageability statement.
and are a (ready for -03) treatment of this; however, we should consider if we want to say more, e.g. such as general guidance / recommendations for using ALPN in QUIC mappings, for instance? Keeping this open to track.
created new issue for ALPN


Addressing this . NAME NAME PTAL
I am really growing to dislike these "here is the alert you must use" constructions. Are they necessary? A lot of this was born out of the deprecate TLS 1/1.1 RFC that spun this I-D off. I believe this is the thread back in mid-2019: URL spt


The default template's purpose is to enable compatibility with origin-only proxy configuration schemes. This is a worthwhile goal, but the default template is not a suitable solution: It violates RFC 8615's definition of .well-known/ as the location for metadata about an origin. A MASQUE service is not metadata. It is not representable as a .well-known "URI suffix" as required by the .well-known registry (unless we register all (2^128 + 2^32)2^16 distinct paths). It conflicts with better discovery mechanisms, like the one in the MASQUE development process. It is not compatible with the use of HTTPS records. (In the targeted legacy context, the client has no other DNS server that can be used when a proxy is in use.) This is somewhat ironic, as HTTPS records allow bootstrapping QUIC connections, and proxying for QUIC is the primary motivation for CONNECT-UDP. We should defer this problem to a subsequent draft, and provide a cohesive proxy setup flow, presumably with a standardized configuration object that could be served from .well-known/ and extended to cover CONNECT-IP, DoH and other relevant capabilities.
Fundamentally I disagree with your assessment that this solution isn't good and should be removed. This serves a real purpose. Let's go into the issues individually: Those points are not an argument to remove the default template, they are an argument to revert PR and switch back to a non-well-known prefix. Let's set those aside for now. I don't see a conflict here: the default template doesn't preclude using other templates that have been discovered through other means. Can you clarify what the conflict is? Can you clarify what the incompatibility is here? I don't understand what the relationship between the default template and HTTPS records is. Clients are welcome to query their own HTTPS records before using CONNECT or CONNECT-UDP. The way that the client picks its template has no impact on its DNS settings.
... This is called "squatting on the HTTP namespace", and it would violate the in RFC 7320. It's also messy to implement, as it would require mixing MASQUE-specific "routing" rules with the user's application-specific routing rules. It doesn't prevent better discovery mechanisms, but it doesn't encourage them either.