[auth48] [AD] AUTH48: RFC-to-be 9554 <draft-ietf-calext-vcard-jscontact-extensions-10> for your review

[Karen Moore <[e-mail]>]

Hi Robert and *Orie (AD),

*Orie, please review the updates in Sections 3.2 and 3.4 and let us know if you approve. The changes can be viewed here: https://www.rfc-editor.org/authors/rfc9554-auth48diff.html. 

Explanation of changes from Robert:
> Changing the LANG parameter to LANGUAGE:
> The section mistakenly had allowed the LANG parameter for the new properties, but LANG is the name of a vCard _property_. The correct name of the _parameter_ is LANGUAGE.
> 
> Removing the ALTID parameter from GRAMGENDER:
> We removed the ALTID parameter because it isn't necessary. There can only be one grammatical gender per contact and language anyway.
> 
> Updated examples:
> We updated the examples to clarify both the changes that I just outlined.

Murray approved the changes between versions -15 and -17; if you disagree with any of the updates, please let us know (see https://www.rfc-editor.org/authors/rfc9554-ad-diff.html).

...
Robert, we have some additional questions.

1) We updated this sentence for clarity; please let us know if it is agreeable or if you prefer otherwise.

Original: 
  Implementations MUST take care to quote the name part, 
  if otherwise the part would not be a valid param-value
  (see Section 3.3 of [RFC6350]).

Current:
  Implementations MUST take care to quote the name part;
  if otherwise, the part will not be a valid "param-value" 
  (see Section 3.3 of [RFC6350]).

2) Is the semicolon after “param-value” needed, or can it be deleted?

Original:
     created-param = "CREATED" "=" param-value ;
                  ; a valid TIMESTAMP of Section 4.3.5 of [RFC6350]

Perhaps:
     created-param = "CREATED" "=" param-value 
                  ; a valid TIMESTAMP of Section 4.3.5 of RFC 6350

3) Is  "This property is defined by the following notation:" needed? There are 15 format definitions, but this phrase only appears in 5  instances. Should all instances be removed for consistency, or do you prefer to keep it as is?

Original:
  Format definition:  This property is defined by the following 
       notation:

       pronouns       = "PRONOUNS" pronouns-param ":" text

Perhaps:
  Format definition: 

      pronouns       = "PRONOUNS" pronouns-param ":” text


FILES (please refresh):

The updated XML file is here:
 https://www.rfc-editor.org/authors/rfc9554.xml

The updated output files are here:
 https://www.rfc-editor.org/authors/rfc9554.txt
 https://www.rfc-editor.org/authors/rfc9554.pdf
 https://www.rfc-editor.org/authors/rfc9554.html

This diff file shows all changes made during AUTH48:
 https://www.rfc-editor.org/authors/rfc9554-auth48diff.html

This diff file shows all changes made to date:
 https://www.rfc-editor.org/authors/rfc9554-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/rfc9554

Thank you,
RFC Editor/kc


> On Apr 4, 2024, at 9:12 AM, Robert Stepanek <[e-mail]> wrote:
> 
> To clarify: If we wouldn't have done these changes now, we would have had to file an errata the moment that document gets published. The changes are very insignificant, given that even no one in the WG even had seen that error during review.
> 
> -Robert


> On Apr 4, 2024, at 8:00 AM, Murray S. Kucherawy <[e-mail]> wrote:
> 
> I just noticed that Roman is the processing AD, helping Francesca, so I don't know why I replied in the first place.  Either way...
> 
> Changes like this not initiated by the RFC Editor during AUTH48 make ADs nervous.  It's not on the record that this change has WG consensus, even if it appears to be obviously the right thing to do.  The bulletproof solution here is to send it back to the WG to confirm, but I don't have a good feeling for how significant these changes are.
> 
> Orie, this is your WG now.  What do you recommend?
> 
> -MSK, ART AD


> On Apr 4, 2024, at 2:59 AM, Robert Stepanek <[e-mail]> wrote:
> 
> You did not, I missed providing an explanation:
> 
> Changing the LANG parameter to LANGUAGE:
> The section mistakenly had allowed the LANG parameter for the new properties, but LANG is the name of a vCard _property_. The correct name of the _parameter_ is LANGUAGE.
> 
> Removing the ALTID parameter from GRAMGENDER:
> We removed the ALTID parameter because it isn't necessary. There can only be one grammatical gender per contact and language anyway.
> 
> Updated examples:
> We updated the examples to clarify both the changes that I just outlined.
> 
> Sorry for the confusion. I guess we'll owe you a couple of explanations for similar changes in RFC 9555, too.
> 
> Best regards,
> Robert


> On Apr 3, 2024, at 6:14 PM, Murray S. Kucherawy <[e-mail]> wrote:
> 
> On Wed, Apr 3, 2024 at 5:28 PM Karen Moore <[e-mail]> wrote:
> Additionally, please review the updates in Sections 3.2 and 3.4 and let us know if you approve. The changes can be viewed here: https://www.rfc-editor.org/authors/rfc9554-auth48diff.html.
> 
> Is there an explanation of these changes anywhere?  All I see in this thread is a whole new XML file from Robert.  Maybe I've missed something?
> 
> -MSK, ART AD



> On Apr 3, 2024, at 5:28 PM, Karen Moore <[e-mail]> wrote:
> 
> We have noted your approval for the changes between versions 15 and 17 - thank you.
> 
> Additionally, please review the updates in Sections 3.2 and 3.4 and let us know if you approve. The changes can be viewed here: https://www.rfc-editor.org/authors/rfc9554-auth48diff.html.
> 
> *Robert, thank you for the updated (corrected) XML file.  Our files now reflect these changes. We have an additional question.
> 
> 1) We updated this sentence for clarity; please let us know if it is agreeable or if you prefer otherwise.
> 
> Original: 
>   Implementations MUST take care to quote the name part, 
>   if otherwise the part would not be a valid param-value
>   (see Section 3.3 of [RFC6350]).
> 
> Current:
>   Implementations MUST take care to quote the name part;
>   if otherwise, the part will not be a valid "param-value" 
>   (see Section 3.3 of [RFC6350]).
> 
> FILES
> The updated XML file is here:
> https://www.rfc-editor.org/authors/rfc9554.xml
> 
> The updated output files are here:
> https://www.rfc-editor.org/authors/rfc9554.txt
> https://www.rfc-editor.org/authors/rfc9554.pdf
> https://www.rfc-editor.org/authors/rfc9554.html
> 
> This diff file shows all changes made during AUTH48:
> https://www.rfc-editor.org/authors/rfc9554-auth48diff.html
> 
> This diff file shows all changes made to date:
> https://www.rfc-editor.org/authors/rfc9554-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/rfc9554
> 
> Thank you,
> RFC Editor/kc