Hi Rebecca, Almost there! Please find my responses below.
Best regards Sergio On Wed, Mar 5, 2025 at 12:57 AM Rebecca VanRheenen < rvanrhee...@staff.rfc-editor.org> wrote: > 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. > > > I think that is fine, as the only URNs defined currently are the ones defined for the extensions. > 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”) > > I am fine with the proposed changes. > > 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 > > I copied it from one of the examples you provided me as guidance, I am fine with both. > > — 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
