Re: [calsify] Roman Danyliw's Discuss on draft-ietf-calext-vcard-jscontact-extensions-05: (with DISCUSS and COMMENT)

[Robert Stepanek <[e-mail]>]

Thank you for your review. We need more guidance on this point, please:

On Sat, Apr 8, 2023, at 2:18 PM, Roman Danyliw via Datatracker wrote:
> 
>   -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
>      have content which was first submitted before 10 November 2008.  If you
>      have contacted all the original authors and they are all willing to grant
>      the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
>      this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
>      (See the Legal Provisions document at
>      https://trustee.ietf.org/license-info for more information.)

We tried figuring which disclaimer we are missing, but we failed. Could you please guide us to a document or disclaimer text that we need to add? The document makes use of a couple of ABNF definitions of RFC 6350 which was published in 2011. To our understanding, there is no content created before 2008.

We updated the document for the rest of your review, as follows:

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Please let me know if I’m not parsing the ABNF correctly:
> 
> ** Section 2.1 and 2.3.  Where is “x-value” defined?  RFC6350 has an “x-name”.
> 
> ** Section 2.3.
>       gram-gender-value = "animate" /
>                           "common" /
>                           "feminine" /
>                           "inanimate" /
>                           "masculine" /
>                           "neuter" /
>                           iana-token
>                           x-value
> 
> Trivial typo.  Shouldn’t there should be a “/” between iana-token and x-value?

Fixed the ABNF. x-value got replaced with x-name as done in RFC 6350.

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> ** idnits returned the following actionable feedback:
>   -- The draft header indicates that this document updates RFC6350, but the
>      abstract doesn't seem to mention this, which it should.

Fixed


> 
> ** Section 2.5.
> 
> Multiple occurrences of this property MAY define
>       pronouns for multiple languages, preferences and contexts.
> 
> If there are multiple occurrences, should there be any guidance on making them
> unique in some way (e.g., requiring difference languages with with prefs)?  For
> example, would the following be acceptable (i.e., same language, no preference
> order):
> 
> PRONOUNS;LANG=en:they/them
> PRONOUNS;LANG=en:she/her

Fixed. We added that same-language pronouns SHOULD have PREF parameters. In absence order of preference is implementation-specific. We updated the example accordingly. We also added the ALTID to the ABNF.

> 
> ** Section 3.1.
> 
>       author-param    = "AUTHOR" "=" DQUOTE 1*QSAFE-CHAR DQUOTE
> 
> Other parameters in RFC6350 (e.g., GEO in Section 5.10 and TZ in Section 5.11)
> seem to define URIs as “DQUOTE URI DQUOTE”.  Why not use that there?

Fixed.

> 
> ** Section 3.5
> 
>       The rank is an integer number larger than
>       or equal to 1 and indicates the first or nth rank.  Its location
>       within the RANKS parameter value ranks the name component value at
>       that same position within the N property value.  An empty or
>       absent rank indicates that the rank of its related name component
>       value is undefined.
> 
> ...
> N;RANKS=",1;,1":Hamilton,Cartland;Mary,Barbara;;Dame;
>                    ; The writer Dame Mary Barbara Hamilton Cartland
>                    ; published as "Barbara Cartland"
> 
> Can clearer guidance please be provided on how to parse the parameter when a
> blank rank is provided in a sequence of ranks (i.e., “, 1;”).  Is this the
> right way to read the example: with “Hamilton, Cartland”, the “Hamilton” (“1”)
> should be the second rank and everything else (“Cartland”, 2) should come first?

Yes. We added text to the examples that now should much better explain this.