Hi Sergio, Thank you for the reply. We updated the document and posted updated files.
We also have a few more questions; thank you for your patience as we work through these! a) We updated the sentences in Section 6.5 as you suggest to make them generic for both registries. However, are changes also needed for the following sentences? Current: A Standards Track RFC is also REQUIRED for registration of WHIP extension URNs that modify WHIP extensions previously documented in an existing RFC. An RFC specifying one or more new WHIP extension URNs MUST include the completed registration template(s), which MAY be expanded with additional information. b) It seems the following text related to the template in Section 6.5.3 should also be generic for both registries. What do you think about the proposed updates below? Current: A WHIP extension URN is defined by completing the following template: URN: A unique URN for the WHIP extension (e.g., "urn:ietf:params:whip:ext:example:server-sent-events”). Name: A descriptive name of the WHIP extension (e.g., "Sender Side events”) Perhaps: The following template should be completed for registrations of WHIP URNs and WHIP Extension URNs: URN: A unique URN (e.g., "urn:ietf:params:whip:ext:example:server-sent-events”). Name: A descriptive name (e.g., "Sender Side events”) c) Regarding the "IANA Registry Reference” description in the template in Section 6.5.3, we question if something like the following would be more accurate. Note that we updated the entry in the for "IANA Registry Reference” in Section 6.3 and will ask that IANA update the registry to match the edited document prior to publication. Current: IANA Registry Reference: For parameters defined in an IETF Standards Track document, list the RFC number. For parameters defined by other organizations or in non-IETF documents, provide a stable, publicly available reference (such as a URL or document ID). If multiple specifications define or update the parameter, list all relevant references. Perhaps: IANA Registry Reference: The registry related to the new URN — FILES (please refresh) — Updated XML file: https://www.rfc-editor.org/authors/rfc9725.xml Updated output files: https://www.rfc-editor.org/authors/rfc9725.txt https://www.rfc-editor.org/authors/rfc9725.pdf https://www.rfc-editor.org/authors/rfc9725.html Diff files showing all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9725-auth48diff.html https://www.rfc-editor.org/authors/rfc9725-auth48rfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9725-diff.html https://www.rfc-editor.org/authors/rfc9725-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9725-alt-diff.html (shows changes where text is moved or deleted) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9725 Thank you, RFC Editor/rv > On Feb 27, 2025, at 2:57 AM, Sergio Garcia Murillo > <sergio.garcia.muri...@gmail.com> wrote: > > > Hi Rebeca, > > It took bit longer than expected, but please find my answers to the IANA > pending topics below > > Best regards > Sergio > > On Fri, Feb 7, 2025 at 8:38 PM Rebecca VanRheenen > <rvanrhee...@staff.rfc-editor.org> wrote: > E) >> > c) Sections 6.3 and 6.4: It looks like Section 6.4.1 includes a template >> > from >> > Appendix A of RFC 3406. However, entries in the "IETF URN Sub-namespace for >> > Registered Protocol Parameter Identifiers" registry >> > (https://www.iana.org/assignments/params/) should use the template in >> > Section 4 >> > of RFC 3553. >> > >> > For examples, see: >> > Section 10.1.2 of RFC 9162 (urn:ietf:params:trans) >> > Section 9.3 of RFC 8620 (urn:ietf:params:jmap) >> > Section 9.6 of RFC 8555 (urn:ietf:params:acme) >> > >> > After discussion with IANA, we recommend 1) updating the text in Section >> > 6.3 >> > to include the template from RFC 3553 as follows and 2) removing Section >> > 6.4. >> > The text in Section 6.4 already appears in Section 4.9, and if needed, >> > information from the template in Section 6.4.1 can be folded into Section >> > 4.9. >> > >> > (Note that we would need you to provide text for the "Index value" field in >> > the suggested text below.) >> > >> > Original: >> > >> > 6.3. Registration of WHIP URN Sub-namespace and WHIP registries >> > >> > IANA is asked to add an entry to the "IETF URN Sub-namespace for >> > Registered Protocol Parameter Identifiers" registry and create a sub- >> > namespace for the Registered Parameter Identifier as per [RFC3553]: >> > "urn:ietf:params:whip". >> > >> > To manage this sub-namespace, IANA is asked to create the "WebRTC- >> > HTTP ingestion protocol (WHIP) URNs" and "WebRTC-HTTP ingestion >> > protocol (WHIP) extension URNs". >> > >> > >> > Perhaps (section numbers per suggested organization in previous question): >> > >> > 6.2. URN Sub-namespace for WHIP (urn:ietf:params:whip) >> > >> > IANA has added a new entry in the "IETF URN Sub-namespace for >> > Registered Protocol Parameter Identifiers" registry, following the >> > template in [RFC3553]: >> > >> > Registry name: whip >> > Specification: RFC 9725 >> > Repository: <https://www.iana.org/assignments/whip> >> > Index value: TBD >> > >> > To manage this sub-namespace, IANA has created two registries within >> > a new registry group called "WebRTC-HTTP Ingestion Protocol (WHIP)": >> > >> > * "WebRTC-HTTP Ingestion Protocol (WHIP) URNs" registry (Section 6.3) >> > * "WebRTC-HTTP Ingestion Protocol (WHIP) Extension URNs" registry >> > (Section 6.4) >> > >> >> If IANA is ok with that, I am fine too. What is the index value? > > After discussion with IANA, we have 1) removed the template in the original > Section 6.4 and 2) updated Section 6.2 as follows with the template from RFC > 3553. > > i) Is there any information in the original template that should be moved to > Section 4.9 or another section? We specifically wonder about information in > the “Declaration of Syntactic Structure” and “Identifier Persistence > Considerations” sections of the original template. > > I am not sure either, don't feel that they are needed, but not strong opinion. > > ii) Regarding the index value, see Section 4 of RFC 3553 and perhaps discuss > with the WG Chair or AD if needed. You can also review some examples in other > documents: > > https://www.rfc-editor.org/rfc/rfc8520.html#section-17.7 > https://www.rfc-editor.org/rfc/rfc8322.html#section-8.2 > https://www.rfc-editor.org/rfc/rfc8555.html#section-9.6 > https://www.rfc-editor.org/rfc/rfc9162.html#section-10.1.2 > > Current: > 6.2. URN Sub-namespace for WHIP (urn:ietf:params:whip) > > IANA has added a new entry in the “IETF URN Sub-namespace for > Registered Protocol Parameter Identifiers” registry, following the > template in [RFC3553]: > > Registry name: whip > Specification: RFC 9725 > Repository: <https://www.iana.org/assignments/whip> > Index value: TBD > > I like the text in one of the examples: > > Index: An IANA-assigned positive integer that identifies the > registration. The first entry added to this registry uses the > value 1, and this value is incremented for each subsequent > entry added to the registry. > > > F) >> > i) Section 6.5.3: The template in this section and the fields on the IANA >> > registry do not exactly match, as shown below. Is it correct that the >> > template >> > should be updated to match the registry? >> > >> > Link to registy: https://www.iana.org/assignments/whip/ >> > >> > Template: >> > URN >> > Reference >> > Name >> > Description >> > Contact Information >> > >> > Registry: >> > URI >> > Description >> > Reference >> > IANA Registry Reference >> > Change Controller >> > >> yes , it should be changed > > Per your reply, we have updated the registration template in Section 6.5.3 to > exactly match the registries at https://www.iana.org/assignments/whip. > > i) In some cases, the field names from the original template seem more > accurate. For example, should “URI” be “URN”, and should “Description” be > “Name”? If needed, we will ask IANA to update the registry to match the > edited document. > > Yes, I think that they should be changed as you propose, could you ask it to > IANA please? > > ii) Please provide descriptions for the "IANA Registry Reference” and "Change > Controller” entries. > > Current: > URI: A unique URN for the WHIP Protocol Extension (e.g., > "urn:ietf:params:whip:ext:example:server-sent-events”) > > Description: A descriptive name of the WHIP Protocol Extension (e.g., > "Sender Side events") > > Reference: A formal reference to the publicly available specification > > IANA Registry Reference: TBD > > Change Controller: TBD > > How about? > > IANA Registry Reference: > For parameters defined in an IETF Standards Track document, list the RFC > number. > For parameters defined by other organizations or in non-IETF documents, > provide a stable, publicly available reference (such as a URL or document > ID). > If multiple specifications define or update the parameter, list all > relevant references. > > Change controller: > For Standards-Track documents, state "IETF". > Otherwise, give the name of the person or body > that has change control over the specification. > > > G) >> > j) This document includes a lot of detail about registering URNs in the >> > "WebRTC-HTTP ingestion Protocol (WHIP) Extension URNs" registry. Is any >> > additional information necessary for registering in the other WHIP >> > registry? >> > Both are "Specification Required". >> > --> >> >> The section should apply for both registries, yes > > We updated the text in paragraph 1 of Section 6.5 to note that the section > applies to both new registries. We also moved paragraph 2 and 3 from Section > 6.5 to Section 6.3.2 because they are specific to the WHIP Extension URNs > registry; please review. > > Please review Sections 6.5.1-6.5.3 and let us know what additional updates > are needed. We specifically question if the following sentences need to be > updated to clarify that this section applies to both registries. Please > provide any updates using OLD/NEW format. > > Current: > The IETF has created a mailing list, <w...@ietf.org>, which can be > used for public discussion of proposals regarding WHIP extensions > prior to registration. > > Registration of new "ext" type URNs (in the namespace > "urn:ietf:params:whip:ext") belonging to a WHIP extension MUST be > documented in a permanent and readily available public specification, > > A Standards Track RFC is also REQUIRED for registration of WHIP > extension URNs that modify WHIP extensions previously documented in > an existing RFC. > > Once the registration procedure concludes successfully, IANA creates > or modifies the corresponding record in the "WebRTC-HTTP ingestion > protocol (WHIP) Extension URNs" registry. > > An RFC specifying one or more new WHIP extension URNs MUST include > the completed registration template(s), which MAY be expanded with > additional information. > > The RFC MUST include the syntax and semantics of any > extension-specific attributes that may be provided in a Link header > field advertising the extension. > > A WHIP extension URN is defined by completing the following template: > > > > In order to make it generic for both registries I propose the following > changes: > > OLD: > The IETF has created a mailing list, <w...@ietf.org>, which can be used for > public discussion of proposals regarding WHIP extensions prior to > registration. Use of the mailing list is strongly encouraged. A designated > expert (DE) [RFC8126], appointed by the IESG, will monitor the > <w...@ietf.org> mailing list and review registrations. > > NEW: > The IETF has created a mailing list, <w...@ietf.org>, which can be used for > public discussion of proposals prior to registration. Use of the mailing list > is strongly encouraged. A designated expert (DE) [RFC8126], appointed by the > IESG, will monitor the <w...@ietf.org> mailing list and review registrations. > > OLD: > Registration of new "ext" type URNs (in the namespace > "urn:ietf:params:whip:ext") belonging to a WHIP extension MUST be documented > in a permanent and readily available public specification, in sufficient > detail so that interoperability between independent implementations is > possible, and reviewed by the DE as per Section 4.6 of [RFC8126]. A Standards > Track RFC is REQUIRED for the registration of new value data types that > modify existing properties. A Standards Track RFC is also REQUIRED for > registration of WHIP extension URNs that modify WHIP extensions previously > documented in an existing RFC. > > NEW > Registration of new entries on the WHIP registries defined in this document > MUST be documented in a permanent and readily available public specification, > in sufficient detail so that interoperability between independent > implementations is possible, and reviewed by the DE as per Section 4.6 of > [RFC8126]. A Standards Track RFC is REQUIRED for the registration of new > value data types that modify existing properties. A Standards Track RFC is > also REQUIRED for registration of WHIP extension URNs that modify WHIP > extensions previously documented in an existing RFC. > > OLD > Once the registration procedure concludes successfully, IANA creates or > modifies the corresponding record in the "WebRTC-HTTP Ingestion Protocol > (WHIP) Extension URNs" registry. > > NEW > Once the registration procedure concludes successfully, IANA creates or > modifies the corresponding record in the "WebRTC-HTTP Ingestion Protocol > (WHIP) URNs Registry" or "WebRTC-HTTP Ingestion Protocol (WHIP) Extension > URNs" or registry. > > >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
