Thanks Elwyn, Replies inline. Changes can be found here <https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ethernet/compare/5c39341..ff4d640> and in the latest editor's copy <https://ietf-wg-masque.github.io/draft-ietf-masque-connect-ethernet/draft-ietf-masque-connect-ethernet.html> .
Thanks again, -Alejandro On Tue, Jul 14, 2026 at 9:13 AM Elwyn Davies via Datatracker < [email protected]> wrote: > Nits/editorial comments: > > s1, para 1: s/can't carry/cannot carry/ > Done. > s1, para 3: states 'This protocol supports all existing versions of > HTTP by > using HTTP Datagrams [HTTP-DGRAM]. This statement needs to be qualified > to identify what the latest existing version of HTTP at the time of > publication of > this document. > The sentences that follow explicitly mention and reference HTTP/1.x, HTTP/2.0, and HTTP/3.0; I think this is well covered. This text was borrowed from https://www.rfc-editor.org/rfc/rfc9484.html#section-1-4. > s3, para 1, last sentence: It would be good to explicitly mention what > .well-known location is being registered (.well-known/masque/ethernet) and > provide a pointer to s11.2 which specifies the process of registration. > Additionally this section should request the update of the well-known URIs > IANA > registry for masque to reference this document. > I've added a reference to §11.2 at the end of §s3,¶1. > s3, para 4: s/which segment to connect to/the segment to which to connect/ > Done s3, para 8 (1st bullet): s/a level 3 template or lower/a template of type > lwvel > 3 or lower. See Section 1.2 of [TEMPLATE]./ > Done s3, para 9 (2nd bullet): Add a reference to RFC 2396 that defines e > 'absolute' > term. > RFC 2396 was obsoleted by RFC 3986. Added a reference to §4.3 of RFC 3986. > s4, Figures 1 - 4: Capsule-Protocol field definition. A note that '?1' is a > Structured Field Boolean True value as per RFC 8941 might help. > I'm not sure how I would fit that in. [HTTP-DGRAM] already covers it pretty well. I could add an informative reference to RFC 8941 if you think that would be helpful, but I'm inclined to leave this as is. > s5: The last paragraph refers to the possibility of an endpoint receiving a > context ID that has not been regeistered but does not explain the > consequences > of this or whether that is something that would be specified as part of the > registration process. Thwre is discussion in s6 that may imply this. > This text comes directly from https://www.rfc-editor.org/rfc/rfc9484.html#section-5-3. > s6, para 4 (one after fields definitions), last sentence: s/include > include/include/ > Done. > s8.1: Does STREAM(44) need some explanation? Also is Quarter Stream ID = 11 > just a reandom value or meaningful? > Those identifiers are borrowed from https://www.rfc-editor.org/rfc/rfc9484.html#name-examples. The Quarter Stream ID is derived from the Stream ID. 44 / 4 = 11. https://www.rfc-editor.org/rfc/rfc9297.html#section-2.1-3.2.1 explains more, and this is an implementation detail of HTTP/3 Datagrams. The specific Stream ID and Quarter Stream ID used here are not meaningful except in that they are properly related to each other. > s9.2, para 2:s/to access to/for access to/ > Done s11.2: As noted above as related to s3, para 1, IANA should be requested to > update the well-known URIs IANA registry for masque to additionally > reference > this document. > The update is described by the table in §11.2, and already mentions a reference to the document. IANA has confirmed that the reference will be included in the update.
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
