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

[Orie Steele <[e-mail]>]

Inline:

On Tue, Apr 9, 2024 at 4:19 PM Karen Moore <[e-mail]> wrote:

> Hi Robert, Bron, and *Orie (AD),
>
> Thank you for your replies.  Our files now reflect the removal of the
> semicolon in Section 4.3 and the removal of "This property is defined by
> the following notation” (5 instances).
>
> *Orie, we have noted your approval of Section 3.4. Please confirm that you
> are okay with the following change in Section 3.2 (as proposed by Robert);
> see https://www.rfc-editor.org/authors/rfc9554-auth48diff.html.
>
> Original:
>    GRAMGENDER;LANGUAGE=de:masculine
>    GRAMGENDER:LANGUAGE=en:neuter
>
> New:
>    GRAMGENDER;LANGUAGE=de:feminine
>

I approve of this change.


>
>
> 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
>
> These diffs show just the changes made during the last edit round:
>  https://www.rfc-editor.org/authors/rfc9554-lastdiff.html
>  https://www.rfc-editor.org/authors/rfc9554-lastrfcdiff.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 8, 2024, at 10:50 PM, Robert Stepanek <[e-mail]>
> wrote:
> >
> > Hi Karen,
> >
> > On Mon, Apr 8, 2024, at 8:50 PM, Karen Moore wrote:
> >> 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]).
> >
> > Great, thanks.
> >
> >>
> >> 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
> >
> > The semicolon can be deleted indeed.
> >
> >>
> >> 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
> >
> > The phrase it not needed. Please remove all instances for consistency.
> >
> > Thanks,
> > Robert
> >
>
>
>
> > On Apr 8, 2024, at 10:47 PM, Robert Stepanek <[e-mail]>
> wrote:
> >
> > On Tue, Apr 9, 2024, at 3:03 AM, Orie Steele wrote:
> >> To be clear are you saying the original example is correct and should
> remain as is?
> >
> > Sadly, the original example is wrong indeed for the reasons Orie had
> noticed:
> >
> > Original
> >
> >     GRAMGENDER;LANGUAGE=de:masculine
> >     GRAMGENDER:LANGUAGE=en:neuter
> >
> > Note the ":" following GRAMGENDER in the second line, which should be
> ";".
> >
> > It's fine for me to only use a single GRAMGENDER example, but
> "inanimate" isn't a grammatical gender in German. Let's change this example
> to:
> >
> >     GRAMGENDER;LANGUAGE=de:feminine
> >
> >
> > I'll reply to the remaining questions on a separate email thread.
> >
> >
>
> > On Apr 8, 2024, at 6:48 PM, Bron Gondwana <[e-mail]>
> wrote:
> >
> > Yep - it's correct syntax.  I don't have a strong opinion on one vs two
> examples.
> >
> > Bron.
> >
> > On Tue, Apr 9, 2024, at 11:03, Orie Steele wrote:
> >> Thanks Bron :)
> >>
> >> To be clear are you saying the original example is correct and should
> remain as is?
> >>
> >> OS
> >>
> >
> >
> >
>
> > On Apr 8, 2024, at 12:06 PM, Orie Steele <[e-mail]>
> wrote:
> >
> >
> >
> > 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
> >
>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>