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

[Orie Steele <[e-mail]>]

On Mon, Apr 8, 2024 at 1:50 PM Karen Moore <[e-mail]> wrote:

> 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.


I approve these changes, they are consistent with:
https://datatracker.ietf.org/doc/html/rfc6350#section-5.1


>
>
> 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.
> >


Agreed, see above.


>
> > 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.
>
>
This example is now confusing:

  Example(s):
      GRAMGENDER;LANGUAGE=de:masculine
      GRAMGENDER:LANGUAGE=en:neuter

especially given your comment regarding ALTID, I suggest a single example
(and double check ":" vs ";")

I suggest:

Example:
      GRAMGENDER:LANGUAGE=de:inanimate


> 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).
>

No comment / I approve them, although they are clearly now out of date.


>
> ...
> 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
>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>