Re: [auth48] AUTH48: RFC-to-be 9555 <draft-ietf-calext-jscontact-vcard-13> for your review

[Karen Moore <[e-mail]>]

Hi Robert,

Correct - the change occurs in RFC 9553.  We will update the document with your suggested text and send the updated links for review on the RFC 9553 thread.

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
> 
>> 
>> Best regards,
>> RFC Editor/kc
>> 
>> 
>> > Hi Karen,
>> > 
>> > On Wed, Apr 17, 2024, at 8:41 PM, Karen Moore wrote:
>> >> Please note that RFC-to-be 9553 references draft-ietf-uuidrev-rfc4122bis-14 , which is now in AUTH48 state. Would you like to wait until AUTH48 completes for that document so the RFC number (RFC-to-be 9562) can be included in RFC-to-be 9553, or do you want to leave the text as is and move forward with publication now?
>> > 
>> > We would like to wait and rather only refer to RFC-to-be 9562 in RFC 9553.
>> > 
>> > Thanks,
>> > Robert
>> 
>> > On Apr 17, 2024, at 11:41 AM, Karen Moore <[e-mail]> wrote:
>> > 
>> > Hello Mario and Robert,
>> > 
>> > Thank you for providing your approval of this document (as noted at https://www.rfc-editor.org/auth48/rfc9555).
>> > 
>> > We now have all necessary approvals and can move this document forward in the publication process, along with RFCs-to-be 9553 and 9554.
>> > 
>> > Please note that RFC-to-be 9553 references draft-ietf-uuidrev-rfc4122bis-14 , which is now in AUTH48 state. Would you like to wait until AUTH48 completes for that document so the RFC number (RFC-to-be 9562) can be included in RFC-to-be 9553, or do you want to leave the text as is and move forward with publication now?
>> > 
>> > Best regards,
>> > RFC Editor/kc
>> > 
>> >> Hi Karen,
>> >> 
>> >> I approve this document too.
>> >> 
>> >> Thanks,
>> >> 
>> >> Mario
>> >> 
>> >> Il 17/04/2024 07:44, Robert Stepanek ha scritto:
>> >>> Hi Karen,
>> >>> 
>> >>> On Wed, Apr 17, 2024, at 3:39 AM, Karen Moore wrote:
>> >>>> Note that the type for "item2.X-FOO:bar” (Figure 2) was not previously set. We believe this should be “text/plain”; if that is not correct, please let us know.
>> >>> 
>> >>> This is correct, thanks.
>> >>> 
>> >>> 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 16, 2024, at 6:39 PM, Karen Moore <[e-mail]> wrote:
>> >> 
>> >> Hi Orie (and authors),
>> >> 
>> >> Thank you for your review. We have noted your approval of those sections on the AUTH48 status page. We now await approvals from Robert and Mario.
>> >> 
>> >> Note that we have updated the sourcecode type to “text/plain” for the examples that include partial vCard text (thank you for your patience while we were discussing it internally). Note that the type for "item2.X-FOO:bar” (Figure 2) was not previously set. We believe this should be “text/plain”; if that is not correct, please let us know.
>> >> 
>> >> Original - XML:
>> >> <figure anchor="group_conversion_props">
>> >>   <name>Example of How to Preserve the Group Name in vCardProps during Conversion</name>
>> >>      <sourcecode><![CDATA[
>> >> item2.X-FOO:bar
>> >> ]]></sourcecode>
>> >>     <sourcecode type="json"><![CDATA[
>> >> "vCardProps": [
>> >> ["x-foo", {
>> >>   "group": "item2"
>> >> }, "unknown", "bar"]
>> >> ]
>> >> ]]></sourcecode>
>> >>    </figure>
>> >> 
>> >> Output:
>> >> item2.X-FOO:bar
>> >>  "vCardProps": [
>> >>    ["x-foo", {
>> >>      "group": "item2"
>> >>    }, "unknown", "bar"]
>> >>  ]
>> >> 
>> >>    Figure 2: Example of How to Preserve the Group Name in vCardProps
>> >>                            during Conversion
>> >> 
>> >> 
>> >> — FILES (please refresh) —
>> >> 
>> >> The updated XML file is here:
>> >> https://www.rfc-editor.org/authors/rfc9555.xml
>> >> 
>> >> The updated output files are here:
>> >> https://www.rfc-editor.org/authors/rfc9555.txt
>> >> https://www.rfc-editor.org/authors/rfc9555.pdf
>> >> https://www.rfc-editor.org/authors/rfc9555.html
>> >> 
>> >> This diff file shows all changes made during AUTH48:
>> >> https://www.rfc-editor.org/authors/rfc9555-auth48diff.html
>> >> 
>> >> These diff files show only the changes made during the last edit round:
>> >> https://www.rfc-editor.org/authors/rfc9555-lastdiff.html
>> >> https://www.rfc-editor.org/authors/rfc9555-lastrfcdiff.html
>> >> 
>> >> This diff file shows all changes made to date:
>> >> https://www.rfc-editor.org/authors/rfc9555-diff.html
>> >> 
>> >> 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/rfc9555
>> >> 
>> >> Best regards,
>> >> RFC Editor/kc
>> >> 
>> >> 
>> >>> On Apr 15, 2024, at 1:07 PM, Orie Steele <[e-mail]> wrote:
>> >>> 
>> >>> Lets use text/plain for the examples that include parts of the vcard data model.
>> >>> 
>> >>> I approve these changes.
>> >>> 
>> >>> Regards,
>> >>> 
>> >>> OS
>> >>> 
>> >>> On Mon, Apr 15, 2024 at 2:27 PM Karen Moore <[e-mail]> wrote:
>> >>> Hi Robert and *Orie (AD),
>> >>> 
>> >>> Apologies for the delayed reply.  We have been further discussing the use of  “text/plain” for partial vCard text - we will get back to you shortly on that, so we will hold off on updating the “type” for the sourcecode in this editing round.
>> >>> 
>> >>> In the meantime, we have removed 2 extraneous instances of “Section” under “Card /calendars” and “Card / directories" that were not needed in Table 8, and we updated the PROP-ID definition as follows.
>> >>> 
>> >>> Original:
>> >>> The PROP-ID parameter (Section 4.7 of [RFC9554]) converts to the Id-
>> >>> typed key of the JSContact object, to which the vCard property having
>> >>> this parameter converts.
>> >>> 
>> >>> Current:
>> >>> The PROP-ID parameter (Section 4.7 of [RFC9554]) converts to the 
>> >>> Id-typed key of the derived JSContact object.
>> >>> 
>> >>> *Orie, please review the following changes that were made by the authors during AUTH48 and let us know if you approve. Note that we double checked all of the section references that were added. The changes can be viewed here: https://www.rfc-editor.org/authors/rfc9555-auth48diff.html. 
>> >>> 
>> >>> Abstract
>> >>> Sections:
>> >>> 2.1.2
>> >>> 2.2.2
>> >>> 2.2.5
>> >>> 2.2.7
>> >>> 2.2.8
>> >>> 2.3.2
>> >>> 2.3.5
>> >>> 2.3.7
>> >>> 2.3.8
>> >>> 2.3.9
>> >>> 2.3.11
>> >>> 2.3.15
>> >>> 2.3.17
>> >>> 2.3.18
>> >>> 2.3.19
>> >>> 2.5.1
>> >>> 2.5.2
>> >>> 2.8.2
>> >>> 2.9.3
>> >>> 2.10.1
>> >>> 2.10.2
>> >>> 2.10.3
>> >>> 3.2.1
>> >>> 3.3.1
>> >>> Appendix A (Table 8: organization —> organizationId)
>> >>> 
>> >>> 
>> >>> — FILES (please refresh) —
>> >>> 
>> >>> The updated XML file is here:
>> >>> https://www.rfc-editor.org/authors/rfc9555.xml
>> >>> 
>> >>> The updated output files are here:
>> >>> https://www.rfc-editor.org/authors/rfc9555.txt
>> >>> https://www.rfc-editor.org/authors/rfc9555.pdf
>> >>> https://www.rfc-editor.org/authors/rfc9555.html
>> >>> 
>> >>> This diff file shows all changes made during AUTH48:
>> >>> https://www.rfc-editor.org/authors/rfc9555-auth48diff.html
>> >>> 
>> >>> These diff files show only the changes made during the last edit round:
>> >>> https://www.rfc-editor.org/authors/rfc9555-lastdiff.html
>> >>> https://www.rfc-editor.org/authors/rfc9555-lastrfcdiff.html
>> >>> 
>> >>> This diff file shows all changes made to date:
>> >>> https://www.rfc-editor.org/authors/rfc9555-diff.html
>> >>> 
>> >>> 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 and the AD prior to moving forward in the publication process.
>> >>> 
>> >>> For the AUTH48 status of this document, please see:
>> >>> https://www.rfc-editor.org/auth48/rfc9555
>> >>> 
>> >>> Best regards,
>> >>> RFC Editor/kc
>> >>> 
>> >>>> On Apr 15, 2024, at 12:01 AM, Robert Stepanek <[e-mail]> wrote:
>> >>>> 
>> >>>> Hi Karen,
>> >>>> 
>> >>>> I'm not sure if you are waiting for our approval for RFC 9555? I am waiting for Editors to provide an updated document version for RFC 9555 with the changes I agreed to below, but maybe I have missed some email thread and you are waiting for some action on my behalf?
>> >>>> 
>> >>>> I can certainly apply the changes outlined below myself, should you prefer that.
>> >>>> 
>> >>>> Thanks,
>> >>>> Robert
>> >>>> 
>> >>>> On Fri, Apr 5, 2024, at 11:10 AM, Robert Stepanek wrote:
>> >>>>> Hi Karen, Orie,
>> >>>>> 
>> >>>>> On Thu, Apr 4, 2024, at 11:29 PM, Karen Moore wrote:
>> >>>>>>> [OS] Thanks for making this change, in case "text/vcard" is rejected (for some tooling reason) "text/plain" would also work... in fact it may be more appropriate if the source code is not a fully valid vcard in text serialization... Is it valid?
>> >>>>>> 
>> >>>>>> Additionally, we updated Section 2.3.17 with Orie’s suggested text; however, if further changes are desired by the authors, we are happy to make the update.
>> >>>>> 
>> >>>>> The examples contain only partial vCard text, so strictly speaking "text/vcard" is not appropriate. If that is an issue, "text/plain" is equally fine.
>> >>>>> 
>> >>>>>> 
>> >>>>>>> NEW:
>> >>>>>>>  The PREF parameter (Section 5.3 of [RFC6350]) converts to the pref
>> >>>>>>>  property of the derived JSContact object.
>> >>>>>> 
>> >>>>>> 
>> >>>>>> Please consider if any updates are needed to this similar sentence that follows in Section 2.3.18:
>> >>>>>> 
>> >>>>>> The PROP-ID parameter (Section 4.7 of [RFC9554]) converts to the Id-
>> >>>>>>  typed key of the JSContact object, to which the vCard property having
>> >>>>>>  this parameter converts.
>> >>>>> 
>> >>>>> I think Orie's suggestion for the PREF parameter is great, and I kindly ask you to apply it also to the PROP-ID definition.
>> >>>>> 
>> >>>>> Thanks,
>> >>>>> Robert
>> >>> 
>> >>> 
>> >>> 
>> >>> -- 
>> >>> 
>> >>> ORIE STEELE
>> >>> Chief Technology Officer
>> >>> www.transmute.industries
>> >>> 
>> >> 
>> >