Skip to main content

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

Yes


No Objection

Erik Kline
Jim Guichard
John Scudder
Robert Wilton
Zaheduzzaman Sarker

Note: This ballot was opened for revision 15 and is now closed.

Francesca Palombini
Yes
Comment (2023-10-17 for -15) Not sent
Thank you for the work on this document.

Many thanks to Martin Dürst for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/WxMhQOuODz3MSVomrM6N5LajbMc/ and to the authors for addressing Martin's comments.
Roman Danyliw
Yes
Comment (2023-10-12 for -15) Not sent
After substantive changes were made in response to IESG Review and a late ARTART review, this document was sent for a second IETF LC to confirm consensus.  It is returning to the IESG for a second review and prior ballot positions have been cleared.  Please see the History tab for your previous comments.
Erik Kline
No Objection
Jim Guichard
No Objection
John Scudder
No Objection
Lars Eggert
No Objection
Comment (2023-10-22 for -15) Sent for earlier
# 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
Paul Wouters
No Objection
Comment (2023-10-18 for -15) Sent
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?
Robert Wilton
No Objection
Zaheduzzaman Sarker
No Objection
Éric Vyncke
No Objection
Comment (2023-10-17 for -15) Not sent
Thanks to the authors for addressing all my comments on -08 and thanks to Roman for the 2nd IETF Last Call.