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

Karen Moore <kmoore@amsl.com> Tue, 09 April 2024 21:58 UTC

Return-Path: <kmoore@amsl.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67BFBC14F70D; Tue, 9 Apr 2024 14:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSG_pwO9JBg9; Tue, 9 Apr 2024 14:58:53 -0700 (PDT)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF091C14F6FB; Tue, 9 Apr 2024 14:58:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 9ED77424B455; Tue, 9 Apr 2024 14:58:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o363z2-VFKvi; Tue, 9 Apr 2024 14:58:53 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2600:1700:3681:d010:701f:181e:5a4:c9a4]) by c8a.amsl.com (Postfix) with ESMTPSA id 7F430424B427; Tue, 9 Apr 2024 14:58:53 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\))
From: Karen Moore <kmoore@amsl.com>
In-Reply-To: <CAN8C-_LJQEF=x2uxu+=oGpftd7B745Zws8MhLKT5c-=K8k8kqg@mail.gmail.com>
Date: Tue, 09 Apr 2024 14:58:53 -0700
Cc: rfc-editor <rfc-editor@rfc-editor.org>, calext-ads@ietf.org, calext-chairs@ietf.org, "Murray S. Kucherawy" <superuser@gmail.com>, Daniel Migault <mglt.ietf@gmail.com>, auth48archive <auth48archive@rfc-editor.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <331422B3-E789-42A1-80E7-80FB8B8799C9@amsl.com>
References: <20240315214259.96B0D1FFA18E@rfcpa.amsl.com> <48b5c001-604f-4982-9ce4-c39936733b4b@app.fastmail.com> <2ffce6d6-b5f1-45f4-a9aa-8eb34963c954@app.fastmail.com> <1A81437D-D40C-4BF0-92B6-99C48B2AF357@amsl.com> <3550D1EF-082B-468B-A996-727ED80F48D5@amsl.com> <CAN8C-_J7bxdOK7cK4H+jKVr3A+UL5OB1dgQn5xDj1s_ZjAYLvg@mail.gmail.com> <F4520C59-95B3-44D7-AF8E-CEC26E1B9D91@amsl.com> <CAN8C-_LJQEF=x2uxu+=oGpftd7B745Zws8MhLKT5c-=K8k8kqg@mail.gmail.com>
To: Orie Steele <orie@transmute.industries>, Robert Stepanek <rsto=40fastmailteam.com@dmarc.ietf.org>, Mario Loffredo <mario.loffredo@iit.cnr.it>
X-Mailer: Apple Mail (2.3654.120.0.1.15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/y0tqjsEF2NTFlFCzqXfzBZkpMNM>
Subject: Re: [auth48] [AD] AUTH48: RFC-to-be 9554 <draft-ietf-calext-vcard-jscontact-extensions-10> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Apr 2024 21:58:58 -0000

Orie,

Thank you for your reply - we have noted your approval of Section 3.2 on the AUTH48 status page (https://www.rfc-editor.org/auth48/rfc9554).

Robert and Mario, we now await your approvals. 

Best regards,
RFC Editor/kc


> On Apr 9, 2024, at 2:43 PM, Orie Steele <orie@transmute.industries> wrote:
> 
> 
> Inline:
> 
> On Tue, Apr 9, 2024 at 4:19 PM Karen Moore <kmoore@amsl.com> 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 <rsto@fastmailteam.com> 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 <rsto@fastmailteam.com> 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 <brong@fastmailteam.com> 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 <orie@transmute.industries> wrote:
> > 
> > 
> > 
> > On Mon, Apr 8, 2024 at 1:50 PM Karen Moore <kmoore@amsl.com> 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 <rsto@fastmailteam.com> 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 <superuser@gmail.com> 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 <rsto@fastmailteam.com> 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 <superuser@gmail.com> wrote:
> > > 
> > > On Wed, Apr 3, 2024 at 5:28 PM Karen Moore <kmoore@amsl.com> 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 <kmoore@amsl.com> 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
>