Re: [auth48] [AD] Re: AUTH48: RFC-to-be 9553 <draft-ietf-calext-jscontact-16> for your review

[Orie Steele <[e-mail]>]

I approve the change to Section 2.1.9.

OS

On Fri, Apr 19, 2024 at 1:42 PM Karen Moore <[e-mail]> wrote:

> Hi Robert and *Orie (AD),
>
> Section 2.1.9 of this document has been updated with Robert’s suggested
> text. Note that we removed the "RFC 4122” reference entry from the document
> as it is no longer being referenced, and we replaced
> "draft-ietf-uuidrev-rfc4122bis-14"  with "RFC 9562” accordingly.
>
> * Orie, please review and provide your approval of the updates in Section
> 2.1.9 as the key words have changed. The update is highlighted below and
> can be also be reviewed at
> https://www.rfc-editor.org/authors/rfc9553-auth48diff.html.
>
> OLD:
>  uid: String (mandatory). An identifier that associates the object as
>    the same across different systems, address books, and views. The value
>    SHOULD be a URN [RFC8141], but for compatibility with [RFC6350], it
>    MAY also be a URI [RFC3986] or free-text value. The value of the URN
>    SHOULD be in the "uuid" namespace [RFC4122].
>
>   As of this writing, a revision [UUID] of the Universally Unique
>   Identifier (UUID) Standards Track document [RFC4122] is in progress
>   and will likely introduce new UUID versions and best practices to
>   generate global unique identifiers. Implementors SHOULD follow any
>   recommendations described there. Until then, implementations SHOULD
>   generate identifiers using the random or pseudorandom UUID version
>   described in Section 4.4 of [RFC4122].
>
> NEW
> uid: String (mandatory).  An identifier that associates the object as
>   the same across different systems, address books, and views.  The
>   value SHOULD be a URN [RFC8141], but for compatibility with
>   [RFC6350], it MAY also be a URI [RFC3986] or free-text value.  The
>   value of the URN SHOULD be in the "uuid" namespace [RFC9562].
>   [RFC9562] describes multiple versions of Universally Unique
>   IDentifiers (UUIDs); UUID version 4 is RECOMMENDED.
>
>
> FILES (please refresh):
>
> The updated XML file is here:
>  https://www.rfc-editor.org/authors/rfc9553.xml
>
> The updated output files are here:
>  https://www.rfc-editor.org/authors/rfc9553.txt
>  https://www.rfc-editor.org/authors/rfc9553.pdf
>  https://www.rfc-editor.org/authors/rfc9553.html
>
> This diff file shows all changes made during AUTH48:
>  https://www.rfc-editor.org/authors/rfc9553-auth48diff.html
>
> These diff files show only changes made during the last edit round:
>  https://www.rfc-editor.org/authors/rfc9553-lastdiff.html
>  https://www.rfc-editor.org/authors/rfc9553-lastrfcdiff.html
>
> This diff file shows all changes made to date:
>  https://www.rfc-editor.org/authors/rfc9553-diff.html
>
> For the AUTH48 status of this document, please see:
>  https://www.rfc-editor.org/auth48/rfc9553
>
> Best regards,
> RFC Editor/kc
>
>
> > On Apr 19, 2024, at 4:41 AM, Robert Stepanek <[e-mail]>
> wrote:
> >
> > Hi Karen,
> >
> > On Thu, Apr 18, 2024, at 7:46 PM, Karen Moore wrote:
> >>
> >> Thank you for confirming. Once AUTH48 is complete for RFC-to-be 9562,
> we will include the number in RFC 9555 and publish the cluster.
> >
> > Just to be sure: it's RFC 9553 that refers to RFC-to-be 9562, so it's
> RFC 9553 that needs to get updated (not RFC 9555).
> >
> > We could then update the text in RFC 9553, Section 2.1.9. Here is a
> suggestion but feel free to refine:
> >
> > OLD:
> > 2.1.9. uid
> >
> > uid: String (mandatory). An identifier that associates the object as the
> same across different systems, address books, and views. The value SHOULD
> be a URN [RFC8141], but for compatibility with [RFC6350], it MAY also be a
> URI [RFC3986] or free-text value. The value of the URN SHOULD be in the
> "uuid" namespace [RFC4122].
> >
> > As of this writing, a revision [UUID] of the Universally Unique
> Identifier (UUID) Standards Track document [RFC4122] is in progress and
> will likely introduce new UUID versions and best practices to generate
> global unique identifiers. Implementors SHOULD follow any recommendations
> described there. Until then, implementations SHOULD generate identifiers
> using the random or pseudorandom UUID version described in Section 4.4 of
> [RFC4122].
> >
> > NEW
> > 2.1.9. uid
> >
> > uid: String (mandatory). An identifier that associates the object as the
> same across different systems, address books, and views. The value SHOULD
> be a URN [RFC8141], but for compatibility with [RFC6350], it MAY also be a
> URI [RFC3986] or free-text value. The value of the URN SHOULD be in the
> "uuid" namespace [RFC9562]. [RFC9562] describes multiple versions of
> universally unique identifiers (UUIDs); UUID version 4 is RECOMMENDED.
> >
> >>
> >> Thank you for your time during this document’s AUTH48 process!
> >
> > Thank you! It's been my first time being engaged in AUTH48 and it has
> been great getting the documents polished with you and the RFC Editor team.
> >
> > Best regards,
> > Robert
>
>
> > On Apr 9, 2024, at 12:07 PM, Karen Moore <[e-mail]> wrote:
> >
> > Hi Robert and Mario,
> >
> > IANA has completed the requested updates to the registries. Since we
> have all necessary approvals now, we will move this document through the
> publication process (along with RFCs-to-be 9554 and 9555 when approved).
> >
> > Note that in Section 3.7.3, we inserted a line of space between the
> “Context” and "Initial Contents” fields in order to read the tables easier
> in the output files. Please let us know of any concerns.
> >
> > Additionally, "draft-ietf-uuidrev-rfc4122bis-14” [UUID] is still in
> RFC-EDITOR state, so we do not have an RFC number yet.  We will check the
> status again once the other documents are approved and ready for
> publication.
> >
> > FILES (please refresh):
> >
> > The updated XML file is here:
> > https://www.rfc-editor.org/authors/rfc9553.xml
> >
> > The updated output files are here:
> > https://www.rfc-editor.org/authors/rfc9553.txt
> > https://www.rfc-editor.org/authors/rfc9553.pdf
> > https://www.rfc-editor.org/authors/rfc9553.html
> >
> > This diff file shows all changes made during AUTH48:
> > https://www.rfc-editor.org/authors/rfc9553-auth48diff.html
> >
> > This diff file shows all changes made to date:
> > https://www.rfc-editor.org/authors/rfc9553-diff.html
> >
> > For the AUTH48 status of this document, please see:
> > https://www.rfc-editor.org/auth48/rfc9553
> >
> > Best regards,
> > RFC Editor/kc
> >
> >> On Apr 5, 2024, at 2:22 PM, Karen Moore <[e-mail]> wrote:
> >>
> >> Hi Robert and Mario,
> >>
> >> Thank you for your replies.  We have noted your approvals on the AUTH48
> status page for this document (https://www.rfc-editor.org/auth48/rfc9553).
>
> >>
> >> We will now ask IANA to update their registries to match the edited
> document, and we will inform you when the updates are complete.
> >>
> >> Note that we updated “Reference or Description” to
> “Reference/Description” in a few of the tables within the IANA section to
> match the registry headers.
> >>
> >> —FILES (please refresh)—
> >>
> >> The updated XML file is here:
> >> https://www.rfc-editor.org/authors/rfc9553.xml
> >>
> >> The updated output files are here:
> >> https://www.rfc-editor.org/authors/rfc9553.txt
> >> https://www.rfc-editor.org/authors/rfc9553.pdf
> >> https://www.rfc-editor.org/authors/rfc9553.html
> >>
> >> This diff file shows all changes made during AUTH48:
> >> https://www.rfc-editor.org/authors/rfc9553-auth48diff.html
> >>
> >> This diff file shows only the changes made during the last edit round:
> >> https://www.rfc-editor.org/authors/rfc9553-lastdiff.html
> >> https://www.rfc-editor.org/authors/rfc9553-lastrfcdiff.html
> >>
> >> This diff file shows all changes made to date:
> >> https://www.rfc-editor.org/authors/rfc9553-diff.html
> >>
> >> For the AUTH48 status of this document, please see:
> >> https://www.rfc-editor.org/auth48/rfc9553
> >>
> >> Best regards,
> >> RFC Editor/kc
> >>
> >>
> >>> On Apr 5, 2024, at 2:10 AM, Mario Loffredo <[e-mail]>
> wrote:
> >>>
> >>> I approve this document too.
> >>>
> >>> Thanks,
> >>>
> >>> Mario
> >>>
> >>>
> >>>
> >>> Il 05/04/2024 11:11, Robert Stepanek ha scritto:
> >>>> On Fri, Apr 5, 2024, at 3:40 AM, Karen Moore wrote:
> >>>>> We now await further changes (if needed) and approvals from Robert
> and Mario.
> >>>>
> >>>> I approve this document.
> >>>>
> >>>> Thanks,
> >>>> Robert
> >>> --
> >>> Dott. Mario Loffredo
> >>> Senior Technologist
> >>> Technological Unit “Digital Innovation”
> >>> Institute of Informatics and Telematics (IIT)
> >>> National Research Council (CNR)
> >>> via G. Moruzzi 1, I-56124 PISA, Italy
> >>> Phone: [phone]
> >>> Web:
> >>> http://www.iit.cnr.it/mario.loffredo
> >>
> >>> On Apr 4, 2024, at 6:40 PM, Karen Moore <[e-mail]> wrote:
> >>>
> >>> Hi Orie,
> >>>
> >>> Thank you for your reply. We have noted your approval of these changes
> on the AUTH48 status page for this document (
> https://www.rfc-editor.org/auth48/rfc9553).
> >>>
> >>> We now await further changes (if needed) and approvals from Robert and
> Mario.
> >>>
> >>> Best regards,
> >>> RFC Editor/kc
> >>>
> >>>> On Apr 4, 2024, at 3:52 PM, Orie Steele <[e-mail]>
> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Apr 4, 2024 at 5:13 PM Karen Moore <[e-mail]> wrote:
> >>>> — Responsible AD for calext: Orie Steele (adding Orie to the thread) —
> >>>>
> >>>> Hi Robert and *Orie (AD),
> >>>>
> >>>> We have updated the description for “speakToAs”; our files now
> reflect this change.  We now await further changes (if needed) and
> approvals from the authors.
> >>>>
> >>>> *Orie, please review the following questions and let us know if you
> approve.
> >>>>
> >>>> 1) Changes were submitted twice after the document
> >>>> was initially approved. Please review the updates from version 15
> >>>> to version 17 and let us know if you approve. The updates can
> >>>> be viewed in this diff file:
> >>>> https://www.rfc-editor.org/authors/rfc9553-ad-diff.html
> >>>>
> >>>> Note that some of the text has been updated for correctness. For
> example,
> >>>> “got obsolete” is now “was obsoleted” (Section 3.3) . The current
> text can be
> >>>> viewed here:
> https://www.rfc-editor.org/authors/rfc9553-auth48diff.html.
> >>>>
> >>>> I approve.
> >>>>
> >>>>
> >>>> 2) Under "Until Version:" (4 instances), we updated the
> >>>> key words for clarity by replacing "MUST be not set, or be one of
> >>>> the allowed values" with "MUST NOT be set or MUST be one of the
> >>>> allowed values" as shown below. Please review and let us know if
> >>>> you approve of this change to the key words (see
> >>>> https://www.rfc-editor.org/authors/rfc9553-auth48diff.html).
> >>>>
> >>>> Original:
> >>>> The Until Version value either MUST NOT be set, or be one of the
> >>>> allowed values of the version property in the JSContact Enum Value
> >>>> registry (see Table 1).
> >>>>
> >>>> Current:
> >>>> The Until Version value either MUST NOT be set or MUST be one of
> >>>> the allowed values of the version property in the "JSContact Values"
> >>>> registry (see Table 1).
> >>>>
> >>>> I approve.
> >>>>
> >>>>
> >>>> 3) The authors made further changes during AUTH48 (if explanation is
> needed, please ask the authors as only the changes were provided). Please
> review the following sections and let us know if you approve: Abstract;
> Sections 1.1, 1.3.1, 1.3.4, 1.4.4, 1.7.3, 1.7.3.1, 1.9.1, 2.1.2, 2.1.8,
> 2.5.1, and 2.8.1; and  Figure 40. The changes can be viewed here:
> https://www.rfc-editor.org/authors/rfc9553-auth48diff.html.
> >>>>
> >>>> I approve these changes.
> >>>>
> >>>>
> >>>> —FILES (please refresh)—
> >>>>
> >>>> The updated XML file is here:
> >>>> https://www.rfc-editor.org/authors/rfc9553.xml
> >>>>
> >>>> The updated output files are here:
> >>>> https://www.rfc-editor.org/authors/rfc9553.txt
> >>>> https://www.rfc-editor.org/authors/rfc9553.pdf
> >>>> https://www.rfc-editor.org/authors/rfc9553.html
> >>>>
> >>>> This diff file shows all changes made during AUTH48:
> >>>> https://www.rfc-editor.org/authors/rfc9553-auth48diff.html
> >>>>
> >>>> This diff file shows all changes made to date:
> >>>> https://www.rfc-editor.org/authors/rfc9553-diff.html
> >>>>
> >>>> For the AUTH48 status of this document, please see:
> >>>> https://www.rfc-editor.org/auth48/rfc9553
> >>>>
> >>>> Best regards,
> >>>> RFC Editor/kc
> >>>>
> >>>>>
> >>>>>> On Apr 2, 2024, at 6:00 AM, Robert Stepanek <[e-mail]>
> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> On Fri, Mar 22, 2024, at 2:26 AM, Karen Moore wrote:
> >>>>>>> 2) We updated Table 2 (Section 3.5.2) by removing the reference
> column and linking each section number to the corresponding property
> context (so it now fits within the 72-character size limit). Please review
> and let us know if any further changes are needed.
> >>>>>>
> >>>>>> Thank you. No further changes are needed.
> >>>>>>
> >>>>>>>
> >>>>>>> Note that we linked instances of “OrgUnit” to Section 2.2.3. Also
> “contexts”, mediaType”, “name”, “label”, “pref”, and “uri” contain
> additional section mentions.  We handled this by adding, for example, "Also
> see Sections 1.4.4 and 1.5.2” under the list of property contexts. Please
> let us know if this is agreeable or if you prefer otherwise.
> >>>>>>
> >>>>>> Thanks, this is good.
> >>>>>>
> >>>>>>>
> >>>>>>> 3) Regarding the following text, would it be clearer to add “that
> directs” or “on” after “information”?
> >>>>>>>
> >>>>>>> Current:
> >>>>>>> speakToAs: SpeakToAs (optional). The information how to address,
> speak to, or refer
> >>>>>>>     to the entity that is represented by the Card.
> >>>>>>>
> >>>>>>> Perhaps:
> >>>>>>> speakToAs: SpeakToAs (optional). The information that directs how
> to address, speak to, or refer
> >>>>>>>     to the entity that is represented by the Card.
> >>>>>>
> >>>>>> Yes, that would be clearer.
> >>>>>>
> >>>>>>>
> >>>>>>> 4) Currently, I-D.ietf-uuidrev-rfc4122bis is in RFC-EDITOR state.
> We suggest finalizing AUTH48 for all three companion documents and then
> revisiting what state I-D.ietf-uuidrev-rfc4122bis is in prior to
> publication. At that time, we will have a better understanding of where
> that document is in the process and when it may be published.
> >>>>>>
> >>>>>> That is great.
> >>>>>>
> >>>>>> Best regards,
> >>>>>> Robert
> >>>>>>
> >>>>>>>
> >>>>>>>>> 15) <!--[rfced] FYI: For clarity and ease of reading, we added a
> reference
> >>>>>>>>> to RFC 4122 as shown below.
> >>>>>>>>>
> >>>>>>>>> Original:
> >>>>>>>>> As of this writing, a revision [I-D.ietf-uuidrev-rfc4122bis] of
> the
> >>>>>>>>> UUID standard document is being worked on and is likely to
> >>>>>>>>> introduce new UUID versions and best practices to generate global
> >>>>>>>>> unique identifiers.
> >>>>>>>>>
> >>>>>>>>> Current:
> >>>>>>>>> As of this writing, a revision [UUID] of the Universally Unique
> >>>>>>>>> Identifier (UUID) Standards Track document [RFC4122] is in
> >>>>>>>>> progress and will likely introduce new UUID versions and
> >>>>>>>>> best practices for generating global unique identifiers [UUID].
> >>>>>>>>> -->
> >>>>>>>>
> >>>>>>>> At best, we could just reference the newly published RFC that
> currently is I-D.ietf-uuidrev-rfc4122bis? In this case we would rephrase
> that paragraph. Are both RFC 9953 and the UUID document get published at
> the same time?
> >>>>>>>
> >>>>>>>
> >>>>>>> 5) Note that the AD will need to approve some of the updates that
> were made.  We will seek approval once all of the updates are complete.
> >>>>>>>
> >>>>>>> —FILES—
> >>>>>>> The updated XML file is here:
> >>>>>>> https://www.rfc-editor.org/authors/rfc9553.xml
> >>>>>>>
> >>>>>>> The updated output files are here:
> >>>>>>> https://www.rfc-editor.org/authors/rfc9553.txt
> >>>>>>> https://www.rfc-editor.org/authors/rfc9553.pdf
> >>>>>>> https://www.rfc-editor.org/authors/rfc9553.html
> >>>>>>>
> >>>>>>> This diff file shows all changes made during AUTH48:
> >>>>>>> https://www.rfc-editor.org/authors/rfc9553-auth48diff.html
> >>>>>>>
> >>>>>>> This diff file shows all changes made to date:
> >>>>>>> https://www.rfc-editor.org/authors/rfc9553-diff.html
> >>>>>>>
> >>>>>>> Note that it may be necessary for you to refresh your browser to
> view the most recent version. Please review the document carefully to
> ensure satisfaction as we do not make changes once it has been published as
> an RFC.
> >>>>>>>
> >>>>>>> Please contact us with any further updates or with your approval
> of the document in its current form.  We will await approvals from each
> author prior to moving forward in the publication process.
> >>>>>>>
> >>>>>>> For the AUTH48 status of this document, please see:
> >>>>>>> https://www.rfc-editor.org/auth48/rfc9553
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>> RFC Editor/kc
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Mar 20, 2024, at 4:12 PM, Robert Stepanek <rsto=
> [e-mail]> wrote:
> >>>>>>>>
> >>>>>>>> Thank your for your review. Attached is the updated document.
> Please see below for replies and additional remarks.
> >>>>>>>>
> >>>>>>>> On Thu, Mar 7, 2024, at 3:13 AM, [e-mail] wrote:
> >>>>>>>>
> >>>>>>>>> 3) <!--[rfced] Please clarify the meaning of "reducing
> complexity of
> >>>>>>>>> their representation". Is the intended meaning that the
> >>>>>>>>> attributes must be described as simple key-value pairs to
> >>>>>>>>> reduce complexity (option A) or to reduce complexity of the
> >>>>>>>>> representation of the card data (option B)?
> >>>>>>>>>
> >>>>>>>>> Original:
> >>>>>>>>> The attributes of the card data represented must be described as
> >>>>>>>>> simple key-value pairs, reducing complexity of their
> >>>>>>>>> representation.
> >>>>>>>>>
> >>>>>>>>> Perhaps:
> >>>>>>>>> A) The attributes of the card data being represented must be
> >>>>>>>>> described as simple key-value pairs to reduce complexity.
> >>>>>>>>>
> >>>>>>>>> or
> >>>>>>>>>
> >>>>>>>>> B) The attributes of the card data must be described as simple
> >>>>>>>>> key-value pairs to reduce the complexity of the representation
> >>>>>>>>> of the card data.
> >>>>>>>>> -->
> >>>>>>>>
> >>>>>>>> Option B. We updated the document accordingly.
> >>>>>>>>
> >>>>>>>>> 4) <!-- [rfced] The use of <tt> and <em>
> >>>>>>>>>
> >>>>>>>>> a) In the html and pdf outputs, the text enclosed in <tt> is
> output in
> >>>>>>>>> fixed-width font. In the txt output, there are no changes to the
> font,
> >>>>>>>>> and the quotation marks have been removed.
> >>>>>>>>>
> >>>>>>>>> In the html and pdf outputs, the text enclosed in <em> is output
> in
> >>>>>>>>> italics. In the txt output, the text enclosed in <em> appears
> with an
> >>>>>>>>> underscore before and after.
> >>>>>>>>>
> >>>>>>>>> Please review carefully and let us know if the output is
> acceptable or
> >>>>>>>>> if any updates are needed.
> >>>>>>>>>
> >>>>>>>>> b) Some terms appear with and without the "<tt>" element, for
> example,
> >>>>>>>>> "@type", "Card", "version", etc. Please review and let us know
> if any
> >>>>>>>>> updates are needed for consistency.
> >>>>>>>>> -->
> >>>>>>>>
> >>>>>>>> We removed all use of <tt> in the document and replaced with
> quotes where appropriate.
> >>>>>>>>
> >>>>>>>>> 5) <!--[rfced] Section 1.3.1. Please clarify the meaning of
> "qux-ishness"
> >>>>>>>>> as no other RFCs contain this term. Is it a well-known term, or
> >>>>>>>>> can it perhaps be rephrased for clarity?
> >>>>>>>>>
> >>>>>>>>> Also, we removed the blockquote element from this text
> >>>>>>>>> because it is not a direct quote. Please let us know
> >>>>>>>>> if any further updates are needed.
> >>>>>>>>>
> >>>>>>>>> Original:
> >>>>>>>>> A Foo object has the following properties:
> >>>>>>>>>
> >>>>>>>>>   qux: Number (mandatory). Defines the qux-ishness of this
> contact.
> >>>>>>>>>   The value MUST be an integer greater than 0 and less than 10.
> >>>>>>>>> -->
> >>>>>>>>
> >>>>>>>> The term "qux" is a metasyntactic variable names in computer
> programming (https://en.wikipedia.org/wiki/Metasyntactic_variable). We
> now changed this to better known metasyntactic name "baz", as in "foo bar
> baz". We did not use "bar" do avoid confusion with the actual English word.
> >>>>>>>>
> >>>>>>>> We now use a <ul> to separate the contents of the example from
> the rest of the section, thanks to Alice Russo for coming up with this!
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> 14) <!--[rfced] In Section 2.1.8, we updated the order of the
> enumerated
> >>>>>>>>> relation types list by moving "co-resident" and "co-worker" above
> >>>>>>>>> "colleague". The list is now in alphabetical order. Please let us
> >>>>>>>>> know of any objections.
> >>>>>>>>>
> >>>>>>>>> There are several other lists in the document. Please review and
> let
> >>>>>>>>> us know if any other terms should be placed in alphabetical
> order.
> >>>>>>>>> -->
> >>>>>>>>
> >>>>>>>> The list of NameComponent and AddressComponent kind values
> deliberately follows non-alphabetic order, they follow logical order. All
> other lists should sort in alphabetical order.
> >>>>>>>>
> >>>>>>>>> 15) <!--[rfced] FYI: For clarity and ease of reading, we added a
> reference
> >>>>>>>>> to RFC 4122 as shown below.
> >>>>>>>>>
> >>>>>>>>> Original:
> >>>>>>>>> As of this writing, a revision [I-D.ietf-uuidrev-rfc4122bis] of
> the
> >>>>>>>>> UUID standard document is being worked on and is likely to
> >>>>>>>>> introduce new UUID versions and best practices to generate global
> >>>>>>>>> unique identifiers.
> >>>>>>>>>
> >>>>>>>>> Current:
> >>>>>>>>> As of this writing, a revision [UUID] of the Universally Unique
> >>>>>>>>> Identifier (UUID) Standards Track document [RFC4122] is in
> >>>>>>>>> progress and will likely introduce new UUID versions and
> >>>>>>>>> best practices for generating global unique identifiers [UUID].
> >>>>>>>>> -->
> >>>>>>>>
> >>>>>>>> At best, we could just reference the newly published RFC that
> currently is I-D.ietf-uuidrev-rfc4122bis? In this case we would rephrase
> that paragraph. Are both RFC 9953 and the UUID document get published at
> the same time?
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> 20) <!--[rfced] In Figure 39, is the term "autor" correct, or
> should it be
> >>>>>>>>> "author"?
> >>>>>>>>>
> >>>>>>>>> Original:
> >>>>>>>>> "titles/t1/name": "autor"
> >>>>>>>>> -->
> >>>>>>>>
> >>>>>>>> The term "autor" is OK as it exemplifies a Spanish localization.
> But we came to realize that "escritor" is the better translation and
> updated the document accordingly
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> 21) <!-- [rfced] We have included some specific questions about
> the IANA
> >>>>>>>>> text below. In addition to responding to those questions, please
> >>>>>>>>> review all of the IANA-related updates carefully and let us know
> >>>>>>>>> if any further updates are needed.
> >>>>>>>>>
> >>>>>>>>> a) FYI: In Section 3.5.1, we placed the "Reference or
> Description" entry
> >>>>>>>>> below the "Change Controller" entry to match the order of the
> template
> >>>>>>>>> at https://www.iana.org/assignments/jscontact/.
> >>>>>>>>>
> >>>>>>>>> - As Table is 2 characters past the 72-character limit, may we
> reformat
> >>>>>>>>> the table to fit by removing the Ref column and linking each
> section
> >>>>>>>>> number to the corresponding Property Context? For an example of
> the output,
> >>>>>>>>> see <
> https://www.rfc-editor.org/authors/rfc9553-table.pdf#table-2>.
> >>>>>>>>
> >>>>>>>> Yes, please.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> e) In Section 3.7.1, should the definition of "Reference" be
> added
> >>>>>>>>> after "Change Controller" to match the template at
> >>>>>>>>> https://www.iana.org/assignments/jscontact? Also, since "Initial
> >>>>>>>>> Contents" is not included in the template, should it be removed
> and
> >>>>>>>>> made into a separate paragraph?
> >>>>>>>>
> >>>>>>>> Yes, please
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> f) In Section 3.7.2, should the definition of "Change
> Controller" be
> >>>>>>>>> added after "Until Version" to match the template at
> >>>>>>>>> https://www.iana.org/assignments/jscontact?
> >>>>>>>>
> >>>>>>>> Yes, please.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Additional remarks:
> >>>>>>>>
> >>>>>>>> The "@" in "@type" property is pronounced within the context of
> this specification and this is how all people in the working group refer to
> it. We rephrased this sentence to start as: "Instead, the @type property"
> >>>>>>>>
> >>>>>>>> We moved "Section 1.5.2: extra" to its own section 1.7.3. for
> "Reserved Properties"
> >>>>>>>>
> >>>>>>>> Section: 2.2.1.3. was mistakenly a subsection of the "name"
> property definition. It is now at the right level at 2.2.2.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Thank you!
> >>>>>>>> Robert Stepanek
> >>>>>>>> <rfc9553.xml>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> ORIE STEELE
> >>>> Chief Technology Officer
> >>>> www.transmute.industries
> >>>>
> >>>
> >>
> >
>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>