Re: [calsify] Lars Eggert's No Objection on draft-ietf-calext-jscontact-15: (with COMMENT)

[Robert Stepanek <[e-mail]>]

Hi Lars,

thanks for you feedback. Please see our replies to your comments below.

On Fri, Oct 13, 2023, at 1:30 PM, Lars Eggert via Datatracker wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> # GEN AD review of draft-ietf-calext-jscontact-15
> 
> ## Comments
> 
> ### Section 1.4.5, paragraph 1
> ```
>   1.4.5.  UTCDateTime
> 
>      This is a string in [RFC3339] date-time format, with the further
>      restrictions that any letters MUST be in uppercase, and the time
>      offset MUST be the character Z.  Fractional second values MUST NOT be
>      included unless non-zero and MUST NOT have trailing zeros, to ensure
>      there is only a single representation for each date-time.
> ```
> Since we coincidentally have draft-ietf-sedate-datetime-extended up
> for approval on this very same telechat, any reason why this new
> format isn't suitable here?

The working group is chartered to require compatibility with vCard (RFC 6350), and we believe that adding support for sedate datetimes in vCard exceeds the scope of our current efforts.

For consistency, sedate datetimes should be supported in both JSContact and JSCalendar (RFC 8984).

> 
> ### Boilerplate
> 
> Document has a TLP Section 6.c.iii "pre-5378" boilerplate. Is this really
> needed?

We removed the boilerplate, now that the JSContact draft does not reuse content of pre-5387 drafts anymore.

> 
> ## Nits
> 
> All comments below are about very minor potential issues that you may choose to
> address in some way - or ignore - as you see fit. Some were flagged by
> automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
> will likely be some false positives. There is no need to let me know what you
> did with these suggestions.
> 
> ### Outdated references
> 
> Reference `[RFC2426]` to `RFC2426`, which was obsoleted by `RFC6350` (this may
> be on purpose).

This is in purpose.

> 
> Document references `draft-ietf-uuidrev-rfc4122bis-11`, but `-12` is the latest
> available revision.
> 
> Document references `draft-ietf-calext-jscontact-14`, but `-15` is the latest
> available revision.

These revisions will be updated once we publish a new revision.

> 
> ### Grammar/style
> 
> #### Section 1.2, paragraph 1
> ```
> jects and all string values are case sensitive. Within context of JSON object
>                                 ^^^^^^^^^^^^^^
> ```
> This word is normally spelled with a hyphen.

Fixed

> 
> #### Section 1.5.1, paragraph 4
> ```
> ronounce Japanese names, or for romanization of Mandarin or Cantonese name a
>                                 ^^^^^^^^^^^^
> ```
> Possible incorrect capitalization. Some nouns that are derived from proper
> nouns can have both an initial capital letter and an initial lower case letter.
> If there is a close association with the proper noun, use "Romanization".
> (Also elsewhere.)

We stick with "romanization".

> 
> #### Section 2.4.1, paragraph 4
> ```
> or number. - subdistrict. The sub district, ward or other subunit of a dist
>                                ^^^^^^^^^^^^
> ```
> This expression is normally spelled as one or with a hyphen.

Fixed.

Regards,
Robert