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

[David Dong via RT <[e-mail]>]

Hi Karen,

We've completed these changes, with the below notes:

> Old:
> Author: See the "Author's Address" section of [RFC-ietf-calext-
> jscontact-16].
> 
> New:
> Author: See the “Authors' Address" section of [RFC-ietf-calext-
> jscontact-16].

We've updated this to "Authors' Addresses".

Please see: 
https://www.iana.org/assignments/media-types/application/jscontact+json

> Under  “contexts”:
> Old:
> Sections 1.5.1, 2.5.1, 2.4.1, 2.6.1, 2.6.2, 2.3.1, 2.3.4, 2.6.3,
> 2.6.4, 2.2.1.3, 2.3.2, 2.2.2, 2.3.3, 2.2.3, 2.4.2, 1.4.4
> 
> New:
> Sections 2.5.1.1, 2.4.1, 2.6.1, 2.6.2, 2.3.1, 2.3.4, 2.6.3, 2.6.4,
> 2.2.2, 2.3.2, 2.2.3, 2.3.3, 2.2.4, 2.4.2. Also see Sections 1.4.4 and
> 1.5.1.

For this change (along with the 4 other reference changes with the text "Also see Sections..."), we've separated out the second sentence from the initial reference.

Please see:
https://www.iana.org/assignments/jscontact/

Thank you!

Best regards,

David Dong
IANA Services Sr. Specialist

On Fri Apr 05 22:35:49 2024, [e-mail] wrote:
> Dear IANA,
> 
> Please make the following updates to match the edited document
> <https://www.rfc-editor.org/authors/rfc9553-diff.html> (or see the
> .txt version to view the tables more clearly <https://www.rfc-
> editor.org/authors/rfc9553.txt>).
> 
> 1) Please delete the extra “s” in "File extensions(s)” and move the
> apostrophe after “s” in “Author’s” in this Media Type:
> <https://www.iana.org/assignments/media-
> types/application/jscontact+json>
> 
> Old:
>    File extensions(s): N/A
> 
> New:
>    File extension(s): N/A
> 
> Old:
> Author: See the "Author's Address" section of [RFC-ietf-calext-
> jscontact-16].
> 
> New:
> Author: See the “Authors' Address" section of [RFC-ietf-calext-
> jscontact-16].
> 
> 2) "JSContact Properties" registry
> <https://www.iana.org/assignments/jscontact/jscontact.xhtml#jscontact-
> properties>
> 
> Please update several section mentions.
> 
> Under @type:
> Old:
> Sections 2.5.1, 2.8.1, 2.1.1, 2.4.1, 2.6.1, 2.6.2, 2.3.1, 2.3.4,
> 2.6.3, 2.6.4, 2.2.1, 2.2.1.3, 2.8.3, 2.3.2, 2.2.2, 2.8.4, 2.3.3,
> 2.2.3, 2.1.8, 2.4.2, 2.2.4
> 
> New:
> Sections 2.5.1.1, 2.5.1.2, 2.8.1, 2.8.3, 2.1.1, 2.4.1, 2.6.1, 2.6.2,
> 2.3.1, 2.3.4, 2.6.3, 2.6.4, 2.2.1.1, 2.2.1.2, 2.2.2, 2.8.3, 2.3.2,
> 2.2.3, 2.2.3, 2.8.1, 2.8.4, 2.3.3, 2.2.4, 2.1.8, 2.4.2, 2.2.4, 2.8.1,
> 2.2.5
> 
> Under “addresses”:
> Old:
> Section 2.5.1
> 
> New:
> Section 2.5.1.1
> 
> Under “components / AddressComponent []”:
> Old:
> Section 2.5.1
> 
> New:
> Section 2.5.1.1
> 
> Under “components / NameComponent []”:
> Old:
> Section 2.2.1
> 
> New:
> Section 2.2.1.2
> 
> Under  “contexts”:
> Old:
> Sections 1.5.1, 2.5.1, 2.4.1, 2.6.1, 2.6.2, 2.3.1, 2.3.4, 2.6.3,
> 2.6.4, 2.2.1.3, 2.3.2, 2.2.2, 2.3.3, 2.2.3, 2.4.2, 1.4.4
> 
> New:
> Sections 2.5.1.1, 2.4.1, 2.6.1, 2.6.2, 2.3.1, 2.3.4, 2.6.3, 2.6.4,
> 2.2.2, 2.3.2, 2.2.3, 2.3.3, 2.2.4, 2.4.2. Also see Sections 1.4.4 and
> 1.5.1.
> 
> Under “coordinates”:
> Old:
> Section 2.5.1
> 
> New:
> Section 2.5.1.1
> 
> Under “countryCode”:
> Old:
> Section 2.5.1
> 
> New:
> Section 2.5.1.1
> 
> Under “defaultSeparator”:
> Old:
> Sections 2.5.1, 2.2.1
> 
> New:
> Sections 2.5.1.1, 2.2.1.1
> 
> Under “extra”:
> Old:
> Section 1.5.2
> 
> New:
> Section 1.7.3.1
> 
> Under “full”:
> Old:
> Sections 2.5.1, 2.2.1
> 
> New:
> Sections 2.5.1.1, 2.2.1.1
> 
> Under “grammaticalGender”:
> Old:
> Section 2.2.3
> 
> New:
> Section 2.2.4
> 
> Under "isOrdered”:
> Old:
> Sections 2.5.1, 2.2.1
> 
> New:
> Sections 2.5.1.1, 2.2.1.1
> 
> Under “kind”:
> Old:
> Sections 2.5.1, 2.8.1, 2.4.1, 2.1.4, 2.6.1, 2.6.2, 2.6.3, 2.6.4,
> 2.2.1, 2.8.4, 2.2.4
> 
> New:
> Sections 2.5.1.2, 2.8.1, 2.4.1, 2.1.4, 2.6.1, 2.6.2, 2.6.3, 2.6.4,
> 2.2.1.2, 2.8.4, 2.2.5
> 
> Under “label”:
> Old:
> Sections 1.5.3, 2.4.1, 2.6.1, 2.6.2, 2.3.1, 2.6.3, 2.6.4, 2.3.2,
> 2.8.4, 2.3.3, 2.4.2, 1.4.4
> 
> New:
> Sections 2.4.1, 2.6.1, 2.6.2, 2.3.1, 2.6.3, 2.6.4, 2.3.2, 2.8.4,
> 2.3.3, 2.4.2. Also see Sections 1.4.4 and 1.5.2.
> 
> Under “mediaType”:
> Old:
> Sections 1.4.4, 2.4.1, 2.6.1, 2.6.2, 2.6.3, 2.6.4
> 
> New:
> Sections 2.4.1, 2.6.1, 2.6.2, 2.6.3, 2.6.4. Also see Section 1.4.4.
> 
> Under “name / Name”:
> Old:
> Section 2.2.1
> 
> New:
> Section 2.2.1.1
> 
> Under “name / String”:
> Old:
> Sections 2.8.3, 2.2.1.3, 2.2.2, 2.2.4
> 
> New:
> Sections 2.8.3, 2.2.2, 2.2.3, 2.2.3, 2.2.5
> 
> Under “nicknames”:
> Old:
> Section 2.2.1.3
> 
> New:
> Section 2.2.2
> 
> Under “organizationId”:
> Old:
> Section 2.2.4
> 
> New:
> Section 2.2.5
> 
> Under “organizations”:
> Old:
> Section 2.2.2
> 
> New:
> Section 2.2.3
> 
> Under “phoneticScript” and “phoneticSystem":
> Old:
> Sections 2.2.1, 2.5.1
> 
> New:
> Sections 2.5.1.1, 2.2.1.1
> 
> Under “pref”:
> Old:
> Sections 1.5.4, 2.5.1, 2.4.1, 2.6.1, 2.6.2, 2.3.1, 2.3.4, 2.6.3,
> 2.6.4, 2.2.1.3, 2.3.2, 2.3.3, 2.2.3, 2.4.2, 1.4.4
> 
> New:
> Sections 2.5.1.1, 2.4.1, 2.6.1, 2.6.2, 2.3.1, 2.3.4, 2.6.3, 2.6.4,
> 2.2.2, 2.3.2, 2.3.3, 2.2.4, 2.4.2. Also see Sections 1.4.4 and 1.5.3.
> 
> Under “pronouns”:
> Old:
> Section 2.2.3
> 
> New:
> Section 2.2.4
> 
> Under "sortAs / String[String]”:
> Old:
> Section 2.2.1
> 
> New:
> Section 2.2.1.1
> 
> Under "sortAs / String”:
> Old:
> Section 2.2.2
> 
> New:
> Sections 2.2.3, 2.2.3
> 
> Under “speakToAs”:
> Old:
> Section 2.2.3
> 
> New:
> Section 2.2.4
> 
> Under “timeZone”:
> Old:
> Section 2.5.1
> 
> New:
> Section 2.5.1.1
> 
> Under “titles”:
> Old:
> Section 2.2.4
> 
> New:
> Section 2.2.5
> 
> Under “units”:
> Old:
> Section 2.2.2
> 
> New:
> Section 2.2.3
> 
> Under “uri”:
> Old:
> Sections 2.8.3, 1.4.4, 2.4.1, 2.6.1, 2.6.2, 2.6.3, 2.6.4, 2.3.2, 2.4.2
> 
> New:
> Sections  2.8.3, 2.4.1, 2.6.1, 2.6.2, 2.6.3, 2.6.4, 2.3.2, 2.4.2. Also
> see Section 1.4.4.
> 
> Under “value”:
> Old:
> Sections 2.5.1, 2.2.1, 2.8.4
> 
> New:
> Sections 2.5.1.2, 2.2.1.2, 2.8.4
> 
> 3) "JSContact Types” registry
> https://www.iana.org/assignments/jscontact/jscontact.xhtml#jscontact-
> types
> 
> Please update the section mentions for the following.
> 
> Under “Address”:
> Old:
> Section 2.5.1
> 
> New:
> Section 2.5.1.1
> 
> Under “AddressComponent":
> Old:
> Section 2.5.1
> 
> New:
> Section 2.5.1.2
> 
> Under "Name”:
> Old:
> Section 2.2.1
> 
> New:
> Section 2.2.1.1
> 
> Under “NameComponent”
> Old:
> Section 2.2.1
> 
> New:
> Section 2.2.1.2
> 
> Under “Nickname”:
> Old:
> Section 2.2.1.3
> 
> New:
> Section 2.2.2
> 
> Under “Organization” and “OrgUnit”::
> Old:
> Section 2.2.2
> 
> New:
> Section 2.2.3
> 
> Under “Pronouns” and “SpeakToAs":
> Old:
> Section 2.2.3
> 
> New:
> Section 2.2.4
> 
> Under “Title”:
> Old:
> Section 2.2.4
> 
> New:
> Section 2.2.5
> 
> 4) "JSContact Enum Values” registry
> <https://www.iana.org/assignments/jscontact/jscontact.xhtml#jscontact-
> enum-values>
> 
> For “contexts” under the Context column, add “Organization” to the
> list:
> 
> Old:
> Property Name:  contexts
>  Context column: Calendar, CryptoKey, Directory, EmailAddress,
> LanguagePref, Link, Media,
> Nickname, OnlineService, Phone, Pronouns, SchedulingAddress
> 
> New:
> Property Name: contexts
>  Context column: Calendar, CryptoKey, Directory, EmailAddress,
> LanguagePref, Link, Media,
>  Nickname, OnlineService, Organization, Phone, Pronouns,
> SchedulingAddress
> 
> 5) "JSContact Enum Values for contexts (Context: Address)” registry
> <https://www.iana.org/assignments/jscontact/jscontact.xhtml#jscontact-
> enum-values-0>
> 
> Under “billing” and “delivery":
> Old:
> Section 2.5.1
> 
> New:
> Section 2.5.1.1
> 
> 6) "JSContact Enum Values for grammaticalGender (Context: SpeakToAs)”
> registry
> <https://www.iana.org/assignments/jscontact/jscontact.xhtml#jscontact-
> enum-values-3>
> 
> Under “animate”, “common”, feminine”, “inanimate”, “masculine”, and
> “neuter”:
> Old:
> Section 2.2.3
> 
> New:
> Section 2.2.4
> 
> 7) "JSContact Enum Values for kind (Context: Calendar)” registry
> <https://www.iana.org/assignments/jscontact/jscontact.xhtml#jscontact-
> enum-values-6>
> 
> Under “apartment”, “block”, “building”, “country”, “direction”,
> “district”, “floor”, “landmark”, “locality”, “name”, “number”,
> “postcode”, “postOfficeBox”, “region”, “room”, “separator”, and
> “subdistrict”:
> Old:
> Section 2.5.1
> 
> New:
> Section 2.5.1.2
> 
> 8) "JSContact Enum Values for kind (Context: NameComponent)” registry
> <https://www.iana.org/assignments/jscontact/jscontact.xhtml#jscontact-
> enum-values-11>
> 
> Under “credential”, “generation”, “given”, “given2”, “separator”,
> “surname”, “surname2”, and "title”:
> Old:
> Section 2.2.1
> 
> New:
> Section 2.2.1.2
> 
> 9) "JSContact Enum Values for kind (Context: Title)” registry
> <https://www.iana.org/assignments/jscontact/jscontact.xhtml#jscontact-
> enum-values-13>
> 
> Under “role” and “title”:
> Old:
> Section 2.2.4
> 
> New:
> Section 2.2.5
> 
> 10) "JSContact Enum Values for phoneticSystem (Context: Address,
> Name)” registry
> <https://www.iana.org/assignments/jscontact/jscontact.xhtml#jscontact-
> enum-values-16>
> 
> Under “ipa”, “jyut”, and “piny”:
> Old:
> Section 1.5.5
> 
> New:
> Section 1.5.4
> 
> 
> Thank you in advance!
> 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
> >>>
> >>
> >