JSContact: A JSON representation of contact data
draft-ietf-calext-jscontact-17

I reviewed the changes since the last IESG round.

Thanks for adding internationalization support.

One nit:

        Implementations MUST NOT set this property in a JSContact object. 
        Any JSContact object including a property with this name is invalid.

Maybe:

        Implementations MUST NOT set this property in a JSContact object.
        Any JSContact object including a property with this name MUST be 
        considered invalid and MUST NOT be used.

Note I'm a bit puzzled this is needed. Could one not simply use a random
uuid or something instead?

Thanks to the authors for addressing all my comments on -08 and thanks to Roman for the 2nd IETF Last Call.

# GEN AD review of draft-ietf-calext-jscontact-15

CC @larseggert

Thanks to Reese Enghardt for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/H0SgvuhO0xzUM5Y6uwC861Mo_XA).

## 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?

### Boilerplate

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

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

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.

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

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

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

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool