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

[Karen Moore <[e-mail]>]

Hi David,

The changes look good, as well as the specific updates you pointed out - thank you! 

RFC Editor/Karen

> On Apr 8, 2024, at 4:54 PM, David Dong via RT <[e-mail]> wrote:
> 
> 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
>>>>> 
>>>> 
>>> 
>