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

[Ballot comment]
# 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

[Ballot comment]
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?

[Ballot comment]
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.

[Ballot comment]
# GEN AD review of draft-ietf-calext-jscontact-15

CC @larseggert

Thanks to Theresa 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

[Ballot comment]
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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-calext-jscontact-15. If any part of this review is inaccurate, please let us know.

IANA has a question about the second action requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are six actions which we must complete.

First, in the application namespace of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a single new registration is to be made as follows:

Name: jscontact+json
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Second, a new registry group is to be created called "JSContact" -- the registry group will have [ RFC-to-be ] as its reference.

IANA Question --> In Section 3.3 of the current draft, are there any specific, immediate actions required of IANA, or is this section included to document the change management procedure for the registries included in the new registry page?

Third, in the new registry group created in IANA action two above, a new registry is to be created called the JSContact Version registry.

The registry policy for assignments that require the JSContact major version to change is Standards Action (as defined by [RFC8126], Section 4.9). The registry policy for other assignments is Specification Required (as defined by [RFC8126], Section 4.6). New registrations in this registry must have a request for that registration sent to the mailing list specified in [ RFC-to-be ]. The template for registration is provided in Section 3.4.1 of [ RFC-to-be ].

There is a single initial registration in the new registry as follows:

Major Version: 1
Highest Minor Version: 0
Reference: [ RFC-to-be ]

Fourth, in the new registry group created in IANA action two above, a new registry is to be created called the JSContact Properties registry.

The registry policy for assignments that require the JSContact major version to change is Standards Action (as defined by [RFC8126], Section 4.9). The registry policy for other assignments is Specification Required (as defined by [RFC8126], Section 4.6). New registrations in this registry must have a request for that registration sent to the mailing list specified in [ RFC-to-be ]. The template for registration is provided in Section 3.5.1 of [ RFC-to-be ].

There are initial registrations in the new registry as outlined in "Table 2: JSContact Properties with 'common' usage" and "Table 3: JSContact Properties with 'reserved' usage" in Section 3.5.2 [note that for every entry in this table, the usage type is "common" (with a single exception, "extra," where the usage is set to "reserved."), the Since Version for all these properties is 1.0 and the Until Version for all properties is not set.].

Fifth, in the new registry group created in IANA action two above, a new registry is to be created called the JSContact Types registry.

The registry policy for assignments that require the JSContact major version to change is Standards Action (as defined by [RFC8126], Section 4.9). The registry policy for other assignments is Specification Required (as defined by [RFC8126], Section 4.6). New registrations in this registry must have a request for that registration sent to the mailing list specified in [ RFC-to-be ]. The template for registration is provided in Section 3.6.1 of [ RFC-to-be ].

There are initial registrations in the new registry as outlined in "Table 4: JSContact Types with 'common' usage" and "Table 5: JSContact Types with 'reserved' usage" in Section 3.6.2 of this draft [note that for every entry, the usage type is "common" (with with a single exception, "Resource," where the usage is set to "reserved."), the Since Version for all these properties is 1.0, the change controller is "IETF," and the Until Version for all properties is not set.].

Sixth, in the new registry group created in IANA action two above, a new registry is to be created called the JSContact Enum Values registry.

Each property in the JSContact Properties registry (see IANA action four, above) will have a subregistry of allowed values.

The registry policy for assignments that require the JSContact major version to change is Standards Action (as defined by [RFC8126], Section 4.9). The registry policy for other assignments is Specification Required (as defined by [RFC8126], Section 4.6). New registrations in this registry must have a request for that registration sent to the mailing list specified in [ RFC-to-be ]. The template for registration of a new property (creation of a new subregistries) in the JSContact Enum registry is provided in Section 3.7.1 of [ RFC-to-be ]. The template for adding a new value to one of the JSContact Enum Values subregistries is provided in Section 3.7.2 of [ RFC-to-be ].

What follows are the initial JSContact Enum Values subregistries (in all of these cases the Since Version is 1.0, the Until Version is not set, the Change Controller is IETF):
====================================================
Property Name: contexts
Context: Address
Initial Contents:

Enum Value | Reference or Description
billing [ RFC-to-be ; Section 2.5.1 ]
delivery [ RFC-to-be ; Section 2.5.1 ]
private [ RFC-to-be ; Section 1.5.1 ]
work [ RFC-to-be ; Section 1.5.1 ]

====================================================
Property Name: contexts
Context: Calendar, CryptoKey, Directory, EmailAddress, LanguagePref, Link, Media, Nickname, OnlineService, Phone, Pronouns, SchedulingAddress

Initial Contents:
Enum Value | Reference or Description
private [ RFC-to-be ; Section 1.5.1 ]
work [ RFC-to-be ; Section 1.5.1 ]

====================================================
Property Name: features
Context: Phone

Initial Contents:
Enum Value | Reference or Description
fax [ RFC-to-be ; Section 2.3.3 ]
main-number [ RFC-to-be ; Section 2.3.3 ]
mobile [ RFC-to-be ; Section 2.3.3 ]
pager [ RFC-to-be ; Section 2.3.3 ]
text [ RFC-to-be ; Section 2.3.3 ]
textphone [ RFC-to-be ; Section 2.3.3 ]
video [ RFC-to-be ; Section 2.3.3 ]
voice [ RFC-to-be ; Section 2.3.3 ]

====================================================
Property Name: grammaticalGender
Context: SpeakToAs

Initial Contents:
Enum Value | Reference or Description
animate [ RFC-to-be ; Section 2.2.3 ]
common [ RFC-to-be ; Section 2.2.3 ]
feminine [ RFC-to-be ; Section 2.2.3 ]
inanimate [ RFC-to-be ; Section 2.2.3 ]
masculine [ RFC-to-be ; Section 2.2.3 ]
neuter [ RFC-to-be ; Section 2.2.3 ]

====================================================
Property Name: kind
Context: AddressComponent

Initial Contents:
Enum Value | Reference or Description
apartment [ RFC-to-be ; Section 2.5.1 ]
block [ RFC-to-be ; Section 2.5.1 ]
building [ RFC-to-be ; Section 2.5.1 ]
country [ RFC-to-be ; Section 2.5.1 ]
direction [ RFC-to-be ; Section 2.5.1 ]
district [ RFC-to-be ; Section 2.5.1 ]
floor [ RFC-to-be ; Section 2.5.1 ]
landmark [ RFC-to-be ; Section 2.5.1 ]
locality [ RFC-to-be ; Section 2.5.1 ]
name [ RFC-to-be ; Section 2.5.1 ]
number [ RFC-to-be ; Section 2.5.1 ]
postcode [ RFC-to-be ; Section 2.5.1 ]
postOfficeBox [ RFC-to-be ; Section 2.5.1 ]
region [ RFC-to-be ; Section 2.5.1 ]
room [ RFC-to-be ; Section 2.5.1 ]
separator [ RFC-to-be ; Section 2.5.1 ]
subdistrict [ RFC-to-be ; Section 2.5.1 ]

====================================================
Property Name: kind
Context: Anniversary

Initial Contents:
Enum Value | Reference or Description
birth [ RFC-to-be ; Section 2.8.1 ]
death [ RFC-to-be ; Section 2.8.1 ]
wedding [ RFC-to-be ; Section 2.8.1 ]

====================================================
Property Name: kind
Context: Calendar

Initial Contents:
Enum Value | Reference or Description
calendar [ RFC-to-be ; Section 2.4.1 ]
freeBusy [ RFC-to-be ; Section 2.4.1 ]

====================================================
Property Name: kind
Context: Card

Initial Contents:
Enum Value | Reference or Description
application [ RFC-to-be ; Section 2.1.4 ]
device [ RFC-to-be ; Section 2.1.4 ]
group [ RFC-to-be ; Section 2.1.4 ]
individual [ RFC-to-be ; Section 2.1.4 ]
location [ RFC-to-be ; Section 2.1.4 ]
org [ RFC-to-be ; Section 2.1.4 ]

====================================================
Property Name: kind
Context: Directory

Initial Contents:
Enum Value | Reference or Description
directory [ RFC-to-be ; Section 2.6.2 ]
entry [ RFC-to-be ; Section 2.6.2 ]

====================================================
Property Name: kind
Context: Link

Initial Contents:
Enum Value | Reference or Description
contact [ RFC-to-be ; Section 2.6.3 ]

====================================================
Property Name: kind
Context: Media

Initial Contents:
Enum Value | Reference or Description
logo [ RFC-to-be ; Section 2.6.4 ]
photo [ RFC-to-be ; Section 2.6.4 ]
sound [ RFC-to-be ; Section 2.6.4 ]

====================================================
Property Name: kind
Context: NameComponent

Initial Contents:
Enum Value | Reference or Description
credential [ RFC-to-be ; Section 2.2.1 ]
generation [ RFC-to-be ; Section 2.2.1 ]
given [ RFC-to-be ; Section 2.2.1 ]
given2 [ RFC-to-be ; Section 2.2.1 ]
separator [ RFC-to-be ; Section 2.2.1 ]
surname [ RFC-to-be ; Section 2.2.1 ]
surname2 [ RFC-to-be ; Section 2.2.1 ]
title [ RFC-to-be ; Section 2.2.1 ]

====================================================
Property Name: kind
Context: PersonalInfo

Initial Contents:
Enum Value | Reference or Description
expertise [ RFC-to-be ; Section 2.8.4 ]
hobby [ RFC-to-be ; Section 2.8.4 ]
interest [ RFC-to-be ; Section 2.8.4 ]

====================================================
Property Name: kind
Context: Title
Initial Contents:
Enum Value | Reference or Description
role [ RFC-to-be ; Section 2.2.4 ]
title [ RFC-to-be ; Section 2.2.4 ]

====================================================
Property Name: level
Context: PersonalInfo

Initial Contents:
Enum Value | Reference or Description
high [ RFC-to-be ; Section 2.8.4 ]
low [ RFC-to-be ; Section 2.8.4 ]
medium [ RFC-to-be ; Section 2.8.4 ]

====================================================
Property Name: relation
Context: Relation

Initial Contents:
Enum Value | Reference or Description
acquaintance [ RFC-to-be ; Section 2.1.8 ]
agent [ RFC-to-be ; Section 2.1.8 ]
child [ RFC-to-be ; Section 2.1.8 ]
colleague [ RFC-to-be ; Section 2.1.8 ]
contact [ RFC-to-be ; Section 2.1.8 ]
co-resident [ RFC-to-be ; Section 2.1.8 ]
co-worker [ RFC-to-be ; Section 2.1.8 ]
crush [ RFC-to-be ; Section 2.1.8 ]
date [ RFC-to-be ; Section 2.1.8 ]
emergency [ RFC-to-be ; Section 2.1.8 ]
friend [ RFC-to-be ; Section 2.1.8 ]
kin [ RFC-to-be ; Section 2.1.8 ]
me [ RFC-to-be ; Section 2.1.8]
met [ RFC-to-be ; Section 2.1.8 ]
muse [ RFC-to-be ; Section 2.1.8 ]
neighbor [ RFC-to-be ; Section 2.1.8 ]
parent [ RFC-to-be ; Section 2.1.8 ]
sibling [ RFC-to-be ; Section 2.1.8 ]
spouse [ RFC-to-be ; Section 2.1.8 ]
sweetheart [ RFC-to-be ; Section 2.1.8 ]

====================================================
Property Name: phoneticSystem
Context: Address, Name

Initial Contents:
Enum Value | Reference or Description
ipa [ RFC-to-be ; Section 1.5.5 ]
jyut [ RFC-to-be ; Section 1.5.5 ]
piny [ RFC-to-be ; Section 1.5.5 ]

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2023-10-12):

From: The IESG
To: IETF-Announce
CC: calext-chairs@ietf.org, calsify@ietf.org, draft-ietf-calext-jscontact@ietf.org, mglt.ietf@gmail.com, rdd@cert.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (JSContact: A JSON representation of contact data) to Proposed Standard


The IESG has received a request from the Calendaring Extensions WG (calext)
to consider the following document: - 'JSContact: A JSON representation of
contact data'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-10-12. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This specification defines a data model and JSON representation of
  contact card information that can be used for data storage and
  exchange in address book or directory applications.  It aims to be an
  alternative to the vCard data format and to be unambiguous,
  extendable and simple to process.  In contrast to the JSON-based
  jCard format, it is not a direct mapping from the vCard data model
  and expands semantics where appropriate.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-calext-jscontact/



No IPR declarations have been submitted directly on this I-D.


This is the second IETF LC on this document.  Substantial changes were made to the document in response to IESG Review of -09 and a post-IESG Review ARTART review.

[Ballot discuss]
(revised for -10)
Thank you for revising the registration policy text in -10.  I am still having difficulty following the registration guidance.  Let me try to restate my concern.

(a) Section 4.3 says:
  The registry policy for assignments that only require the JSContact
  minor version to change is Expert Review ([RFC8126], Section 4.5),
  optionally amended by Specification Required ([RFC8126],
  Section 4.6).  The registry policy for assignments that require the
  JSContact major version to change is Expert Review + Standards Action
  ([RFC8126], Section 4.9).  The Designated Expert decides if a major
  version change is required.  They also decide if public formal
  documentation is required in addition to Expert Review.

(b) Section 4.3 says:
  *  If the "Intended Usage" field is common, sufficient documentation
      is required to enable interoperability.  Preliminary community
      review for this registry is optional but strongly encouraged.

(c) Section 4.3.3
  For a common-use registration, the DE is
  expected to confirm that suitable documentation, as described in
  Section 4.6 of [RFC8126], is available to ensure interoperability.
 

Text-(a) addressed my other DISCUSS point about handling version numbers.  However, I’m not sure how this new text can be used as a reference for Section 4.4.  I can’t find text that suggests that registering a property in the Section 4.4.* sub-registries would trigger a bump in the minor version number.  Is that something the DE does?

Additionally, per “... minor version to change is Expert Review ([RFC8126], Section 4.5), optionally amended by Specification Required ([RFC8126]”, I don’t understand what it means to optionally amend the registration policy.

Text-(c) is effectively stating that the policy for “Intended Usage” = “common” is Specification Required (which implicitly includes a DE review).

[Ballot comment]
I support Paul's, Roman's, and Eric's DISCUSS positions, and I like Roman's suggestion.

In Section 1.6.2, you have "implementors SHOULD take in mind..."  I'm not sure we can apply our normative guidance to humans.  Maybe reword this so you're addressing the software's requirements rather than people?

It strikes me that Section 1.7.2 could just say this document specifies version 1.0, and future versions will be specified in their own RFCs.  The MUST here seems unnecessary to me, and having this document's version down in Section 2.1.2 seems to bury the lede a little.

Throughout Section 2, you indicate things as "optional" or "mandatory".  Why not "OPTIONAL" or "REQUIRED", since you're already invoking BCP 14?

I have a similar concern in this document as I expressed in the other CALEXT documents on the telechat this week: Many of the SHOULDs are not well explained as to why they're only SHOULD.  You might want to either back them up ("SHOULD, because ...") or provide some guidance about why one might legitimately do something different from what it says ("SHOULD, unless ...").  If you can't do either, maybe they ought to be MUSTs or MAYs.  Wide open SHOULDs are sometimes a little too ambiguous.

[Ballot comment]
Thanks for the specification.

I have No objection from a transport protocol point of view, however, I am actually missing motivations and benefits of this format over other formats like -vCard, in this document. Is that any comparative analysis of these different formats?

[Ballot discuss]

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (easy to address: do not panic), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Daniel Migault for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


# DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

## Charter compliance

The CALEXT charter contains `Any extensions to vcard or jscontact must include a representation in both formats, and define a robust mapping between them`. It is unclear to me what is the actual meaning:

1) the mapping is required between vcard and jscontact (as JScontact is presented in this I-D as an alternative to vCARD) or

2) the mapping is required only between jscontact versions/extensions ? (respectively for vCARD)

If this is the former, then I was unable to find any "robust mapping" between vCARD and JSContact in this document, or is it in another document?

If this is the latter, then I am removing this DISCUSS point.

Happy to discuss this with the CALEXT chairs and responsible AD.

## Sections 2.4.1, 2.6.1, 2.6.2, ...

Please do not use URL with ftp: or http: (I appreciate that this is not a DISCUSS criteria, but I want to be sure that this issue is addressed as it is trivial to fix).

[Ballot comment]

# COMMENTS (non blocking)

## Why not YANG ?

Is there a reason why YANG was not used as the data model language ? AFAIK, YANG data models can easily be serialised in JSON.

## Section 1.4

`A[B] - A JSON object where the keys are all of type A, and the values are all of type B.` isn't there a swap between A and B in the explanation ?

## Section 1.7

`Implementors are RECOMMENDED to always support the latest version` but what about backward compatibility ? Any guidance to be offered ?

## Section 1.9.1

I share Roman's issue about the use of a FQDN as a vendor prefix, there should be some text enforcing the uniqueness of the property name (some vendor organisations are so broad that one part is unaware of extension done by another part). Even if this is kind of obvious, it is worth writing.

Sorry, cannot parse `The following all are valid examples of vendor-specific properties`

## Section 2.2.1

Is the extra white space are meaningful in the example, then please provide some text whether those whitespace can be removed.

## Section 2.3.3

Unsure whether "tel:+33-01-23-45-67" is a typical example phone number (even if the numerical progression is a big hint).

# NITS (non blocking / cosmetic)

## Section 2.1.3 and 2.1.10

Perhaps using a date in this millennium ? ;-)

[Ballot comment]
# GEN AD review of draft-ietf-calext-jscontact-09

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.7.2, paragraph 0
```
  1.7.2.  Version Updates
```
Agree with Roman's DISCUSS on this bit and the overall IANA considerations.

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

### URLs

These URLs in the document did not return content:

* https://rdap.pubtest.nic.it/

### Grammar/style

#### Section 1.2, paragraph 1
```
A JSON object where the keys are all of type A, and the values are all of ty
                                ^^^^^^^^^^^
```
Consider using "all type" or "all of the type".

#### Section 1.2, paragraph 1
```
all of type A, and the values are all of type B. * A[] - A JSON array of valu
                                  ^^^^^^^^^^^
```
Consider using "all type" or "all of the type".

#### Section 1.5.5, paragraph 2
```
e: String This property allows to associate contact data with user-defined l
                              ^^^^^^^^^^^^
```
Did you mean "associating"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

#### Section 1.6, paragraph 1
```
UnsignedInt This property allows to define a preference order for contact in
                                  ^^^^^^^^^
```
Did you mean "defining"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

#### Section 1.6.1, paragraph 4
```
is property defines the JSContact type of a JSContact object. It allows imple
                                  ^^^^^^^^^
```
If "type" is a classification term, "a" is not necessary. Use "type of". (The
phrases "kind of" and "sort of" are informal if they mean "to some extent".).

#### Section 1.7.1, paragraph 1
```
ween three kinds of properties with regards to validation: IANA-registered pr
                              ^^^^^^^^^^^^^^^
```
Use "in regard to", "with regard to", or more simply "regarding".

#### Section 1.7.1, paragraph 1
```
A JSContact object is invalid if any its properties are invalid. If a JSCon
                                  ^^^^^^^
```
A determiner cannot be combined with a possessive pronoun. Did you mean simply
"any" or "its"?

#### Section 1.7.2, paragraph 4
```
dix B.1 of [RFC5234]). Notable exceptions of this rule are metadata properti
                              ^^^^^^^^^^^^^
```
Did you mean "exceptions to"?

#### Section 1.8.2, paragraph 2
```
35]. The prefix ietf.org and its sub-domain names are reserved for IETF speci
                                ^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 1.9.1, paragraph 2
```
y new standard values once a vendor-specific turns out to be useful also for
                          ^^^^^^^^^^^^^^^^^^^^^^^
```
The plural noun "turns" cannot be used with the article "a". Did you mean "a
vendor-specific turn" or "vendor-specific turns"?

#### Section 2.2.2, paragraph 9
```
pe: Id[NickName] (optional). The nick names of the entity represented by this
                                ^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 2.2.2, paragraph 10
```
* name: String (mandatory). The nick name. * contexts: String[Boolean] (opti
                                ^^^^^^^^^
```
This word is normally spelled as one.

#### Section 2.2.2, paragraph 10
```
The contexts in which to use this nick name. Also see Section 1.6.1. * pref
                                  ^^^^^^^^^
```
This word is normally spelled as one.

#### Section 2.2.2, paragraph 10
```
optional). The preference of this nick name in relation to other nick names.
                                  ^^^^^^^^^
```
This word is normally spelled as one.

#### Section 2.2.2, paragraph 10
```
is nick name in relation to other nick names. Also see Section 1.6.3. "nickN
                                  ^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 2.2.3, paragraph 2
```
grammatical gender does not allow to infer the gender identities or assigned
                                  ^^^^^^^^
```
Did you mean "inferring"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

#### Section 2.2.4, paragraph 5
```
presented by this Card. A Title has object the following properties: * @type:
                                    ^^^^^^
```
Use the past participle here.

#### Section 2.2.4, paragraph 9
```
* organization: Id (optional). The id of the organization in which this titl
                                  ^^
```
This abbreviation for "identification" is spelled all-uppercase.

#### Section 2.2.5, paragraph 11
```
e name including capitalization. Typically the service name is the one which
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Typically".

#### Section 2.2.5, paragraph 12
```
ders of that service use on their web sites, in their apps or other publishin
                                  ^^^^^^^^^
```
Nowadays, it's more common to write this as one word.

#### Section 2.3.4, paragraph 3
```
dress] (optional). A map of address ids to Address objects, containing physi
                                    ^^^
```
This abbreviation for "identification" is spelled all-uppercase.

#### Section 2.3.4, paragraph 7
```
ional). The city, town, village, post town, or other locality within which t
                                ^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 2.5.1, paragraph 12
```
n 1.9.1): * contact The resource is an URI by which the entity represented b
                                    ^^
```
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

#### Section 2.5.1, paragraph 32
```
e to the Card that includes the localizations property. A patch MUST NOT tar
                                ^^^^^^^^^^^^^
```
An apostrophe may be missing.

#### Section 4.5.2, paragraph 5
```
s Contact information is very privacy sensitive. It can reveal the identity,
                              ^^^^^^^^^^^^^^^^^
```
This word is normally spelled 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

[Ballot comment]
Hi,

Thanks for this document.

Given time constraints this week.  Sorry, but due to holiday & PTO, I've only been any to review this as a fairly cursory level.

At a high level, the biggest question that I have is why an implementor would choose to use this instead of using one of the established and presumably widely deployed encodings of the vCard format?  As such, I think that this document may benefit from a slightly longer introduction/explanation/justification as to why an implementor may choose to use this over a vCard format (i.e., what problem is being solved), and possibly an appendix (or separate document) highlighting the main differences between this format and the vCard (or jCard) formats.  Perhaps this is what the introduction text is intended to already cover, but if so, that didn't come across clearly.

One minor nit, in section 1.7, where it discusses versioning, it may be helpful to specify that if a new major version is published then the minor version is also reset back to 0.

Regards,
Rob

[Ballot discuss]
I agree with Roman on the IANA Registry policy issues. Additionally, I have a few minor DISCUSSes and COMMENTS.

Section 1.7.2:

        [...] a new standard RFC document MUST be published.

RFCs target implementers, who on their own cannot comply with this MUST :P
Using RFC 2119 language to force someone to write an RFC is .... interesting :)
I would remove the sentence.

Similarly,

        Every new JSContact version MUST be registered at IANA in the JSContact Enum Value registry Table 6.

is pretty meaningless within this RFC. I would also remove this sentence


IDN related:

    The following all are valid examples of vendor-specific properties.

        "example.com:foo": "bar",
        "example.com:foo2": {
          "bar": "baz"
        }

What about:

        "xn--exmple-xta.com:foo": "bar",

Could this cause confusion or security issues ?
(this is the A-label version of "exâmple.com")



        As of this writing, a revision of [RFC4122] is being worked on

Please add an informative reference to draft-ietf-uuidrev-rfc4122bis, so
future implementers might stumble upon the bis document or RFC


Section 2.3.2

        service: String (optional). The name of the online service or
        protocol. This SHOULD be the canonical service name including
        capitalization. Typically the service name is the one which the
        providers of that service use on their web sites, in their apps or
        other publishing material. Examples are GitHub, kakao, Mastodon.

This seems a bit dangerous from a security point of view, eg "GitHub" vs "Github"
and might be misleadiing. Would it be safer to match a string without case, and
allow a presentation format with case?


Section 2.6.1

Why is there no  cryptoKeys option that embeds the public key. Only indirect URI
syle options are available. Two phones using "airdrop" could benefit from being
able to exchange the actual public key blobs directly.

Also perhaps using "kind" could be RECOMMENDED ? Otherwise there will be some guessing
needed for the crypto protocol/application kind which could be dangerous.


Section 2.8.1. anniversaries

Since "kind" is mandatory, there should be a value "other", or else it can only contain
birthday, deathday and wedding day.

Section 2.8.4. personalInfo

Similarly, needs an "other" option as "kind" is mandatory.

Section 5.

The Security Considerations start of with stating the importance of privacy, but in Section
5.2 still allows (almost recommends) HTTP along with HTTPS. Why not remove HTTP there?

[Ballot comment]
1.6.3. The pref property

why not start from 0 ? What to do when the value is set to 0, same as unset ?


        Implementors are RECOMMENDED to always support the latest version.

I would remove this (obvious) advise

        Such extensions are not meant for interoperation and vendors
        MUST NOT expect other implementations to process their contents.

The "MUST NOT expect" reads a little strange, as if we are dictating a mind set
instead of a technical process. Maybe say "other implementations MUST NOT process" ?

Setion 1.9.1:

        followed by a name consisting of any other non-control ASCII or non-ASCII characters.

I can't parse this constraint. Perhaps "consisting of only non-control ASCII characters" ?

Section 2.2.1 lists limitations on "fullName" with respect to "name", but
section 2.2.2 for "name" does not list its limitations to "fullName".
A similar case is true for StreetComponents and fullAddress.

Also, why is StreetComponent not lowerCamelCase like the other options?
It seems only the values of 4.4.2 using capitals instead of starting with
lowercase. Is there a convention or reason for this that I am not aware of?

Section  2.4.1

Can the ftp examples be replaced by non-ftp examples? The IETF as a whole is trying
to move away from the ftp protocol.

[Ballot discuss]
** Section 1.9.1. 
  The vendor-specific prefix SHOULD be a domain name under control of
  the service or application that sets the property, but it need not
  resolve in the Domain Name System [RFC1034] and [RFC1035].

How are vendor-specific prefixes intended to avoid collision if there is no mandatory, collision free algorithm to avoid it?

** Thank you for the thoughtful and detailed guidance to the designated expert with an eye towards long term flexible and extensibility in the ecosystem. 

I see two inconsistencies in the registration guidance.

-- “Intended usage” field changes the registration behavior:

(a) Section 4.3 says:
  This registry follows the Expert Review process ([RFC8126],
  Section 4.5).

(b) Section 4.3 says:
  If the "Intended Usage" field is common, sufficient
  documentation is required to enable interoperability.  Preliminary
  community review for this registry is optional but strongly
  encouraged.

(c) Section 4.3.3 says:
  For a common-use registration, the DE is
  expected to confirm that suitable documentation, as described in
  Section 4.6 of [RFC8126], is available to ensure interoperability.

Text-(a) establishes a DE registration policy.  However, the subsequent text in (b) and (c) is effectively saying that the registry has different registration practices depending on the value of the “intended usage” field.  If “intended usage” = “common”, then the registration policy is “Specification Required” (where a DE review is required, and a stable reference is needed).  It isn’t uncommon for a collection of code points in a single registry to have different registration practices (e.g., https://www.iana.org/assignments/cose/cose.xhtml#key-common-parameters).  Why not be explicit here?

-- @version/Table 6.

Section 1.7.2. says:
  If Expert Review or the IETF working group decides that a new major JSContact version is required, a 
  new standard RFC document MUST be published. Such an RFC document MUST specify all changes to
  the former JSContact version. An RFC document is not required to change the minor JSContact version.

Doesn’t this imply that registration policy of this subregistry is: Specification Required for new minor versions; and major versions are Standards Action (per Section 4.9 of RFC8126) + Expert Review?

[Ballot comment]
Thank you to Derek Atkins for the SECDIR review.

** Section 1.7.2
  If Expert Review or the IETF working group decides that a new major
  JSContact version is required, a new standard RFC document MUST be
  published.  Such an RFC document MUST specify all changes to the
  former JSContact version.  An RFC document is not required to change
  the minor JSContact version.

-- Is “new standard RFC document” the same as “new standards-track or BCP RFC document” (i.e., per Section 4.9 of RFC8126)?

-- Is this decision of the Expert Reviewer envisioned after CALEXT closes?  Could there be a situation where the Expert Reviewer and the WG disagree?

** Section 1.8
  If a JSContact object is valid,
  implementations MUST preserve all its properties.

What does “preserve all … properties” mean in this context?  This section seems to be about validating of the document.  Is this the same as the text is Section 1.8.2?

** Section 1.8.2.

(a)

  Implementations may encounter JSContact data where a property name is
  unknown to that implementation, but the name adheres to the
  restrictions of an IANA-registered property.

(b)
  Implementations
  that create or update JSContact data MUST only set IANA-registered
  properties or vendor-specific properties,

(c) ... but MUST preserve any
    already existing unknown properties.

Per (c), what are these properties are being noted that aren’t those defined in (a), which is covered with the behavior described in (b).

** Section 1.9.  Editorial.
  Typically, sending a short description to the IETF working
  group mailing list is enough for Expert Review to make a decision.

Recommend dropping this sentence.  There appears to be significant nuance in Section 4’s registration practices.  Instead of re-stating, the reference here works.

** Section 1.9.1
  They MUST NOT reject the
  property value as invalid, unless they are in control of the vendor-
  specific property.

What does it mean to “control” the vendor-specific property?

** Section 2.2.2.
      This
      specification does not mandate how to do this but recommends the
      following: If at least one of two adjacent name components is of
      type separator then implementations SHOULD join their values
      without any additional character.

This mixing of lower-case RFC2119 words which claims that there is no normative guidance, followed by a (lower-case) recommendation that has normative guidance requires refinement.

** Section 2.3.2. Editorial.
    This SHOULD be the canonical service name including
      capitalization.

I don’t have better language.  However, I’m unsure what makes something “canonical” in naming the service.  Consider if that particular word is needed.

** Section 23.  Figure 23.  The examples here are clear.  Is serving .ics or .ifb over FTP common?  Consider replacing this with a protocol which provides confidentiality and integrity.

** Section 2.5.1.  Editorial. Per timeZone, consider if the IANA Time Zone Database should be made a normative reference.

** Section 2.6.1.  Additional flexibility in cryptoKeys seems like it would helpful.  For consideration:

-- Supporting a “kind” property to allow specific typing of a public key vs. certificate, or even supporting a shared symmetric secret?

-- Supporting @context here?

-- Is it possible associate a given cryptoKey with a particular email address?

-- Inline support for a certificate or symmetric key.  It could be as simple as reminding the readers of the data:// scheme (RFC3986) with text or an example; or a native property.

** Section 2.6.1.  Figure 26.  The example proposes to retrieve a certificate (judging from the .cer file extensions) over HTTP.  In the general case, this doesn’t seem like a good idea.  Please use the https:// scheme.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-calext-jscontact-08. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has questions about two of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete.

First, in the application namespace of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a new registration will be made as follows:

Name: jscontact+json
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Second, a new registry is to be created called the JSContact Properties registry. The new registry is to be managed via Expert Review as defined in RFC8126. There are initial registrations in the new registry as follows:

Property Name: @type
Property Type: String
Property Context: Address, Anniversary, Author, Card, CalendarResource, ContactChannelPreference, CryptoResource, DirectoryResource, EmailAddress, LanguagePreference, LinkResource, MediaResource, Name, NameComponent, NickName, Note, OnlineService, Organization, OrgUnit, PartialDate,PersonalInfo, Phone, Pronouns, Relation, Resource, SchedulingAddress, SpeakToAs, StreetComponent, Timestamp, Title
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.5.1, Section 2.8.1, Section 2.1.1, Section 2.4.1, Section 2.3.4, Section 2.6.1, Section 2.6.2, Section 2.3.1, Section 2.3.5, Section 2.6.3, Section 2.6.4, Section 2.2.2, Section 2.2.3, Section 2.8.3, Section 2.3.2, Section 2.2.4, Section 2.8.4, Section 2.3.3, Section 2.2.5, Section 2.1.8, Section 2.4.2, Section 2.2.6 ]

Property Name: @version
Property Type: String
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.1.2]

Property Name: address
Property Type: String
Property Context: EmailAddress
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.3.1]

Property Name: addresses
Property Type: Id[Address]
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.5.1]

Property Name: anniversaries
Property Type: Id[Anniversary]
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.8.1]

Property Name: author
Property Type: Author
Property Context: Note
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.8.3]

Property Name: calendars
Property Type: Id[CalendarResource]
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.4.1]

Property Name: calendarScale
Property Type: String
Property Context: PartialDate
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.8.1]

Property Name: components
Property Type: NameComponent[]
Property Context: Name
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.2.2]

Property Name: contexts
Property Type: String[Boolean]
Property Context: Address, NickName, Pronouns, EmailAddress, OnlineService, Phone, ContactChannelPreference, LanguagePreference, CalendarResource, CryptoResource, DirectoryResource, LinkResource, MediaResource, Organization, SchedulingAddress
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 1.6.1, Section 2.5.1, Section 2.2.3, Section 2.2.5, Section 2.3.1, Section 2.3.2, Section 2.3.3, Section 2.3.4, Section 2.3.5, Section 1.5.4, Section 2.4.1, Section 2.6.1, Section 2.6.2, Section 2.6.3, Section 2.6.4, Section 2.2.4, Section 2.4.2 ]

Property Name: coordinates
Property Type: String
Property Context: Address
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.5.1 ]

Property Name: country
Property Type: String
Property Context: Address
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.5.1 ]

Property Name: countryCode
Property Type: String
Property Context: Address
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.5.1 ]

Property Name: created
Property Type: UTCDateTime
Property Context: Card, Note
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.1.3, Section 2.8.3 ]

Property Name: date
Property Type: Timestamp|PartialDate
Property Context: Anniversary
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.8.1 ]

Property Name: day
Property Type: UnsignedInt
Property Context: PartialDate
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.8.1 ]

Property Name: directories
Property Type: Id[DirectoryResource]
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.6.2]

Property Name: emails
Property Type: Id[EmailAddress]
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.3.1 ]

Property Name: features
Property Type: String[Boolean]
Property Context: Phone
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.3.3 ]

Property Name: fullAddress
Property Type: String
Property Context: Address
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.5.1 ]

Property Name: fullName
Property Type: String
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.2.1 ]

Property Name: grammaticalGender
Property Type: String
Property Context: SpeakToAs
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.2.5 ]

Property Name: keywords
Property Type: String[Boolean]
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.8.2 ]

Property Name: kind
Property Type: String
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.1.4 ]

Property Name: label
Property Type: String
Property Context: EmailAddress, OnlineService, Phone, CalendarResource, CryptoResource, DirectoryResource, LinkResource, MediaResource, PersonalInfo, SchedulingAddress
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 1.6.2, Section 2.3.1, Section 2.3.2, Section 2.3.3, Section 1.5.4, Section 2.4.1, Section 2.6.1, Section 2.6.2, Section 2.6.3, Section 2.6.4, Section 2.8.4, Section 2.4.2 ]

Property Name: level
Property Type: String
Property Context: PersonalInfo
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.8.4 ]

Property Name: links
Property Type: Id[LinkResource]
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.6.3 ]

Property Name: listAs
Property Type: UnsignedInt
Property Context: DirectoryResource, PersonalInfo
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.6.2, Section 2.8.4 ]

Property Name: locale
Property Type: String
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.1.5 ]

Property Name: locality
Property Type: String
Property Context: Address
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.5.1 ]

Property Name: localizations
Property Type: String[PatchObject]
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.7.1 ]

Property Name: media
Property Type: Id[MediaResource]
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.6.4 ]

Property Name: mediaType
Property Type: String
Property Context: CalendarResource, CryptoResource, DirectoryResource, LinkResource, MediaResource
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 1.5.4, Section 2.4.1, Section 2.6.1, Section 2.6.2, Section 2.6.3, Section 2.6.4 ]

Property Name: members
Property Type: String[Boolean]
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.1.6 ]

Property Name: month
Property Type: UnsignedInt
Property Context: PartialDate
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.8.1 ]

Property Name: name
Property Type: Name
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.2.2 ]

Property Name: name
Property Type: String
Property Context: Author, NickName, Organization, OrgUnit, Title
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.8.3, Section 2.2.3, Section 2.2.4, Section 2.2.6 ]

Property Name: nickNames
Property Type: Id[NickName]
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.2.3 ]

Property Name: note
Property Type: String
Property Context: Note
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.8.3 ]

Property Name: notes
Property Type: Id[Note]
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.8.3 ]

Property Name: number
Property Type: String
Property Context: Phone
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.3.3 ]

Property Name: onlineServices
Property Type: Id[OnlineService]
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.3.2 ]

Property Name: organization
Property Type: String
Property Context: Title
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.2.6 ]

Property Name: organizations
Property Type: Id[Organization]
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.2.4 ]

Property Name: personalInfo
Property Type: Id[PersonalInfo]
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.8.4 ]

Property Name: phones
Property Type: Id[Phone]
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.3.3 ]

Property Name: place
Property Type: Address
Property Context: Anniversary
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.8.1 ]

Property Name: postcode
Property Type: String
Property Context: Address
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.5.1 ]

Property Name: pref
Property Type: UnsignedInt
Property Context: Address, NickName, Pronouns, EmailAddress, OnlineService, Phone, ContactChannelPreference, LanguagePreference, CalendarResource, CryptoResource, DirectoryResource, LinkResource, MediaResource, SchedulingAddress
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 1.6.3, Section 2.5.1, Section 2.2.3, Section 2.2.5, Section 2.3.1, Section 2.3.2, Section 2.3.3, Section 2.3.4, Section 2.3.5, Section 1.5.4, Section 2.4.1Section 2.6.1, Section 2.6.2, Section 2.6.3, Section 2.6.4, Section 2.4.2 ]

Property Name: preferredContactChannels
Property Type: String[ContactChannelPreference[]]
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.3.4 ]

Property Name: preferredLanguages
Property Type: String[LanguagePreference[]]
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.3.5 ]

Property Name: prodId
Property Type: String
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.1.7 ]

Property Name: pronouns
Property Type: Id[Pronouns]
Property Context: SpeakToAs
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.2.5 ]

Property Name: pronouns
Property Type: String
Property Context: Pronouns
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.2.5 ]

Property Name: rank
Property Type: UnsignedInt
Property Context: NameComponent
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.2.2 ]

Property Name: region
Property Type: String
Property Context: Address
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.5.1 ]

Property Name: relatedTo
Property Type: String[Relation]
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.1.8 ]

Property Name: relation
Property Type: String[Boolean]
Property Context: Relation
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.1.8 ]

Property Name: schedulingAddresses
Property Type: Id[SchedulingAddress]
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.4.2 ]

Property Name: service
Property Type: String
Property Context: OnlineService
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.3.2 ]

Property Name: sortAs
Property Type: String[String]
Property Context: Name
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.2.2 ]

Property Name: sortAs
Property Type: String
Property Context: Organization, OrgUnit
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.2.4 ]

Property Name: speakToAs
Property Type: SpeakToAs
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.2.5 ]

Property Name: street
Property Type: StreetComponent[]
Property Context: Address
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.5.1 ]

Property Name: timeZone
Property Type: String
Property Context: Address
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.5.1 ]

Property Name: titles
Property Type: Id[Title]
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.2.6 ]

Property Name: type
Property Type: String
Property Context: Anniversary, NameComponent, Title, CalendarResource, CryptoResource, DirectoryResource, LinkResource, MediaResource, OnlineService, StreetComponent, PersonalInfo
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.8.1, Section 2.2.2, Section 2.2.6, Section 1.5.4, Section 2.4.1, Section 2.6.1, Section 2.6.2, Section 2.6.3, Section 2.6.4, Section 2.3.2, Section 2.5.1, Section 2.8.4 ]

Property Name: uid
Property Type: String
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.1.9 ]

Property Name: units
Property Type: OrgUnit[]
Property Context: Organization
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.2.4 ]

Property Name: updated
Property Type: UTCDateTime
Property Context: Card
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.1.10 ]

Property Name: uri
Property Type: String
Property Context: Author, CalendarResource, CryptoResource, DirectoryResource, LinkResource, MediaResource, SchedulingAddress
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.8.3, Section 1.5.4, Section 2.4.1, Section 2.6.1, Section 2.6.2, Section 2.6.3, Section 2.6.4, Section 2.4.2 ]

Property Name: user
Property Type: String
Property Context: OnlineService
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.3.2 ]

Property Name: utc
Property Type: UTCDateTime
Property Context: Timestamp
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.8.1 ]

Property Name: value
Property Type: String
Property Context: NameComponent, StreetComponent, PersonalInfo
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.2.2, Section 2.5.1, Section 2.8.4 ]

Property Name: year
Property Type: UnsignedInt
Property Context: PartialDate
Intended Usage: Common
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 2.8.1 ]

Property Name: extra
Property Type: not applicable
Property Context: not applicable
Intended Usage: reserved
Change Controller: IETF
Since Version: 1.0
Until Version:
Reference(s): [ RFC-to-be; Section 1.10 ]


IANA QUESTION --> Where should this new registry be located? Should it be added to an existing registry page? If it needs a new page, does it also need a new category at http://www.iana.org/protocols (and if so, should the page and the category have the same name)?


Third, a new registry is to be created called the JSContact Types registry. The new registry is to be managed via Expert Review as defined in RFC8126. There are initial registrations in the new registry as follows:

Type Name: Address
Reference: [ RFC-to-be ; Section 2.5.1 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: Anniversary
Reference: [ RFC-to-be ; Section 2.8.1 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: Author
Reference: [ RFC-to-be ; Section 2.8.3 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: Boolean
Reference: [ RFC-to-be ; Section 1.4 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: CalendarResource
Reference: [ RFC-to-be ; Section 2.4.1 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: Card
Reference: [ RFC-to-be ; Section 2 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: ContactChannelPreference
Reference: [ RFC-to-be ; Section 2.3.4 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: CryptoResource
Reference: [ RFC-to-be ; Section 2.6.1 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: DirectoryResource
Reference: [ RFC-to-be ; Section 2.6.2 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: EmailAddress
Reference: [ RFC-to-be ; Section 2.3.1 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: Id
Reference: [ RFC-to-be ; Section 1.5.1 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: Int
Reference: [ RFC-to-be ; Section 1.5.2 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: LanguagePreference
Reference: [ RFC-to-be ; Section 2.3.5 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: LinkResource
Reference: [ RFC-to-be ; Section 2.6.3 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: MediaResource
Reference: [ RFC-to-be ; Section 2.6.4 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: Name
Reference: [ RFC-to-be ; Section 2.2.2 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: NameComponent
Reference: [ RFC-to-be ; Section 2.2.2 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: NickName
Reference: [ RFC-to-be ; Section 2.2.3 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: Note
Reference: [ RFC-to-be ; Section 2.8.3 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: Number
Reference: [ RFC-to-be ; Section 1.4]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: OnlineService
Reference: [ RFC-to-be ; Section 2.3.2 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: Organization
Reference: [ RFC-to-be ; Section 2.2.4 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: OrgUnit
Reference: [ RFC-to-be ; Section 2.2.4 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: PartialDate
Reference: [ RFC-to-be ; Section 2.8.1 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: PatchObject
Reference: [ RFC-to-be ; Section 1.5.3 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: PersonalInfo
Reference: [ RFC-to-be ; Section 2.8.4 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: Phone
Reference: [ RFC-to-be ; Section 2.3.3 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: Pronouns
Reference: [ RFC-to-be ; Section 2.2.5 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: Relation
Reference: [ RFC-to-be ; Section 2.1.8 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: Resource
Reference: [ RFC-to-be ; Section 1.5.4 ]
Intended Usage: reserved
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: SchedulingAddress
Reference: [ RFC-to-be ; Section 2.4.2 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: SpeakToAs
Reference: [ RFC-to-be ; Section 2.2.5 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: StreetComponent
Reference: [ RFC-to-be ; Section 2.5.1 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: String
Reference: [ RFC-to-be ; Section 1.4 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: Timestamp
Reference: [ RFC-to-be ; Section 2.8.1 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: Title
Reference: [ RFC-to-be ; Section 2.2.6 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: UnsignedInt
Reference: [ RFC-to-be ; Section 1.5.2 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF

Type Name: UTCDateTime
Reference: [ RFC-to-be ; Section 1.5.5 ]
Intended Usage: common
Since Version: 1.0
Until Version:
Change Controller: IETF



IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If it needs a new page, does it also need a new category at http://www.iana.org/protocols (and if so, should the page and the category have the same name)?



Fourth, a new registry is to be created called the JSContact Enum Values registry. The new registry will have a set of subregistries for allowed values. IANA understands that the format IANA used for the JSCalendar Enum Values registry and its subregistries at

https://www.iana.org/assignments/jscalendar

is acceptable as the format for the registry and subregistries.

The new registry is to be managed via Expert Review as defined in RFC8126. There are initial registrations in the new registry as follows:

Property Name: kind
Context: Card
Reference: [ RFC-to-be; ]
Since Version: 1.0
Until Version:
Change Controller: IETF

Property Name: @version
Context: Card
Reference: [ RFC-to-be; ]
Since Version: 1.0
Until Version:
Change Controller: IETF

Property Name: contexts
Context: NickName, Pronouns, EmailAddress, OnlineService, Phone, ContactChannelPreference, LanguagePreference, CalendarResource, CryptoResource, DirectoryResource, LinkResource, MediaResource, SchedulingAddress
Reference: [ RFC-to-be; ]
Since Version: 1.0
Until Version:
Change Controller: IETF

Property Name: contexts
Context: Address
Reference: [ RFC-to-be; ]
Since Version: 1.0
Until Version:
Change Controller: IETF

Property Name: features
Context: Phone
Reference: [ RFC-to-be; ]
Since Version: 1.0
Until Version:
Change Controller: IETF

Property Name: type
Context: StreetComponent
Reference: [ RFC-to-be; ]
Since Version: 1.0
Until Version:
Change Controller: IETF

Property Name: type
Context: NameComponent
Reference: [ RFC-to-be; ]
Since Version: 1.0
Until Version:
Change Controller: IETF

Property Name: type
Context: Title
Reference: [ RFC-to-be; ]
Since Version: 1.0
Until Version:
Change Controller: IETF

Property Name: grammaticalGender
Context: SpeakToAs
Reference: [ RFC-to-be; ]
Since Version: 1.0
Until Version:
Change Controller: IETF

Property Name: preferredContactChannels
Context: Card
Reference: [ RFC-to-be; ]
Since Version: 1.0
Until Version:
Change Controller: IETF

Property Name: type
Context: CalendarResource
Reference: [ RFC-to-be; ]
Since Version: 1.0
Until Version:
Change Controller: IETF

Property Name: type
Context: DirectoryResource
Reference: [ RFC-to-be; ]
Since Version: 1.0
Until Version:
Change Controller: IETF

Property Name: type
Context: LinkResource
Reference: [ RFC-to-be; ]
Since Version: 1.0
Until Version:
Change Controller: IETF

Property Name: type
Context: MediaResource
Reference: [ RFC-to-be; ]
Since Version: 1.0
Until Version:
Change Controller: IETF

Property Name: type
Context: Anniversary
Reference: [ RFC-to-be; ]
Since Version: 1.0
Until Version:
Change Controller: IETF

Property Name: type
Context: OnlineService
Reference: [ RFC-to-be; ]
Since Version: 1.0
Until Version:
Change Controller: IETF

Property Name: type
Context: PersonalInfo
Reference: [ RFC-to-be; ]
Since Version: 1.0
Until Version:
Change Controller: IETF


For each of the property name/context pairs there is a sub-registry of allowed values:


JSContact Enum Values for kind (Context: Card)
Registration procedure: Expert review
Reference: [ RFC-to-be ]

Enum Value Reference or Description
---------------+--------------------------
individual [rfc-to-be; Section 2.1.4]
group [rfc-to-be; Section 2.1.4]
org [rfc-to-be; Section 2.1.4]
location [rfc-to-be; Section 2.1.4]
device [rfc-to-be; Section 2.1.4]
application [rfc-to-be; Section 2.1.4]


JSContact Enum Values for @version (Context: Card)
Registration procedure: Expert review
Reference: [ RFC-to-be ]

Enum Value Reference or Description
---------------+--------------------------
1.0 [rfc-to-be; Section 2.1.2]

JSContact Enum Values for contexts (Context: NickName, Pronouns, EmailAddress, OnlineService, Phone, ContactChannelPreference, LanguagePreference, CalendarResource, CryptoResource, DirectoryResource, LinkResource, MediaResource, SchedulingAddress)
Registration procedure: Expert review
Reference: [ RFC-to-be ]

Enum Value Reference or Description
---------------+--------------------------
private [rfc-to-be; Section 1.6.1]
work [rfc-to-be; Section 1.6.1]


JSContact Enum Values for contexts (Context: Address)
Registration procedure: Expert review
Reference: [ RFC-to-be ]

Enum Value Reference or Description
---------------+--------------------------
private [rfc-to-be; Section 1.6.1]
work [rfc-to-be; Section 1.6.1]
billing [rfc-to-be; Section 2.5.1]
delivery [rfc-to-be; Section 2.5.1]


JSContact Enum Values for features (Context: Phone)
Registration procedure: Expert review
Reference: [ RFC-to-be ]

Enum Value Reference or Description
---------------+--------------------------
voice [rfc-to-be; Section 2.3.3]
fax [rfc-to-be; Section 2.3.3]
pager [rfc-to-be; Section 2.3.3]
text [rfc-to-be; Section 2.3.3]
cell [rfc-to-be; Section 2.3.3]
textphone [rfc-to-be; Section 2.3.3]
video [rfc-to-be; Section 2.3.3]


JSContact Enum Values for type (Context: StreetComponent)
Registration procedure: Expert review
Reference: [ RFC-to-be ]

Enum Value Reference or Description
---------------+--------------------------
name [rfc-to-be; Section 2.5.1]
number [rfc-to-be; Section 2.5.1]
apartment [rfc-to-be; Section 2.5.1]
room [rfc-to-be; Section 2.5.1]
extension [rfc-to-be; Section 2.5.1]
direction [rfc-to-be; Section 2.5.1]
building [rfc-to-be; Section 2.5.1]
floor [rfc-to-be; Section 2.5.1]
postOfficeBox [rfc-to-be; Section 2.5.1]
separator [rfc-to-be; Section 2.5.1]
unknown [rfc-to-be; Section 2.5.1]


JSContact Enum Values for type (Context: NameComponent)
Registration procedure: Expert review
Reference: [ RFC-to-be ]

Enum Value Reference or Description
---------------+--------------------------
prefix [rfc-to-be; Section 2.2.2]
given [rfc-to-be; Section 2.2.2]
surname [rfc-to-be; Section 2.2.2]
middle [rfc-to-be; Section 2.2.2]
suffix [rfc-to-be; Section 2.2.2]
separator [rfc-to-be; Section 2.2.2]


JSContact Enum Values for type (Context: Title)
Registration procedure: Expert review
Reference: [ RFC-to-be ]

Enum Value Reference or Description
---------------+--------------------------
title [rfc-to-be; Section 2.2.6]
role [rfc-to-be; Section 2.2.6]


JSContact Enum Values for grammaticalGender (Context: SpeakToAs)
Registration procedure: Expert review
Reference: [ RFC-to-be ]

Enum Value Reference or Description
---------------+--------------------------
animate [rfc-to-be; Section 2.2.5]
female [rfc-to-be; Section 2.2.5]
inanimate [rfc-to-be; Section 2.2.5]
male [rfc-to-be; Section 2.2.5]
neuter [rfc-to-be; Section 2.2.5]


JSContact Enum Values for preferredContactChannels (Context: Card)
Registration procedure: Expert review
Reference: [ RFC-to-be ]

Enum Value Reference or Description
---------------+--------------------------
addresses [rfc-to-be; Section 2.3.4]
emails [rfc-to-be; Section 2.3.4]
onlineServices [rfc-to-be; Section 2.3.4]
phones [rfc-to-be; Section 2.3.4]


JSContact Enum Values for type (Context: CalendarResource)
Registration procedure: Expert review
Reference: [ RFC-to-be ]

Enum Value Reference or Description
---------------+--------------------------
calendar [rfc-to-be; Section 2.4.1]
freeBusy [rfc-to-be; Section 2.4.1]


JSContact Enum Values for type (Context: DirectoryResource)
Registration procedure: Expert review
Reference: [ RFC-to-be ]

Enum Value Reference or Description
---------------+--------------------------
directory [rfc-to-be; Section 2.6.2]
entry [rfc-to-be; Section 2.6.2]

JSContact Enum Values for type (Context: LinkResource)
Registration procedure: Expert review
Reference: [ RFC-to-be ]

Enum Value Reference or Description
---------------+--------------------------
contact [rfc-to-be; Section 2.6.3]


JSContact Enum Values for type (Context: MediaResource)
Registration procedure: Expert review
Reference: [ RFC-to-be ]

Enum Value Reference or Description
---------------+--------------------------
photo [rfc-to-be; Section 2.6.4]
sound [rfc-to-be; Section 2.6.4]
logo [rfc-to-be; Section 2.6.4]


JSContact Enum Values for type (Context: Anniversary)
Registration procedure: Expert review
Reference: [ RFC-to-be ]

Enum Value Reference or Description
---------------+--------------------------
birth [rfc-to-be; Section 2.8.1]
death [rfc-to-be; Section 2.8.1]
wedding [rfc-to-be; Section 2.8.1]


JSContact Enum Values for type (Context: OnlineService)
Registration procedure: Expert review
Reference: [ RFC-to-be ]

Enum Value Reference or Description
---------------+--------------------------
impp [rfc-to-be; Section 2.3.2]
uri [rfc-to-be; Section 2.3.2]
username [rfc-to-be; Section 2.3.2]


JSContact Enum Values for type (Context: PersonalInfo)
Registration procedure: Expert review
Reference: [ RFC-to-be ]

Enum Value Reference or Description
---------------+--------------------------
expertise [rfc-to-be; Section 2.8.4]
hobby [rfc-to-be; Section 2.8.4]
interest [rfc-to-be; Section 2.8.4]


The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-03-17):

From: The IESG
To: IETF-Announce
CC: calext-chairs@ietf.org, calsify@ietf.org, draft-ietf-calext-jscontact@ietf.org, francesca.palombini@ericsson.com, mglt.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (JSContact: A JSON representation of contact data) to Proposed Standard


The IESG has received a request from the Calendaring Extensions WG (calext)
to consider the following document: - 'JSContact: A JSON representation of
contact data'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-03-17. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This specification defines a data model and JSON representation of
  contact card information that can be used for data storage and
  exchange in address book or directory applications.  It aims to be an
  alternative to the vCard data format and to be unambiguous,
  extendable and simple to process.  In contrast to the JSON-based
  jCard format, it is not a direct mapping from the vCard data model
  and expands semantics where appropriate.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-calext-jscontact/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
yes

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
No

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

yes.
The document has an implementation section:
"""
3.  Implementation Status

  NOTE: Please remove this section and the reference to [RFC7942] prior
  to publication as an RFC.  This section records the status of known
  implementations of the protocol defined by this specification at the
  time of posting of this Internet-Draft, and is based on a proposal
  described in [RFC7942].  The description of implementations in this
  section is intended to assist the IETF in its decision processes in
  progressing drafts to RFCs.  Please note that the listing of any
  individual implementation here does not imply endorsement by the
  IETF.  Furthermore, no effort has been spent to verify the
  information presented here that was supplied by IETF contributors.
  This is not intended as, and must not be construed to be, a catalog
  of available implementations or their features.  Readers are advised
  to note that other implementations may exist.  According to
  [RFC7942], "this will allow reviewers and working groups to assign
  due consideration to documents that have the benefit of running code,
  which may serve as evidence of valuable experimentation and feedback
  that have made the implemented protocols more mature.  It is up to
  the individual working groups to use this information as they see
  fit".
"""

Other implementations have been mentioned on the mailing list.
from Joris Baum (audriga):
Hi Daniel,

regarding 4):

* we have implemented draft-ietf-calext-jscontact and draft-ietf-calext-jscontact-vcard in a new library used in https://github.com/audriga/roundcube-jmap . We are currently using that version in production at audriga. We did not implement the most current version of the spec though and have yet to publish our changes on GitHub.

* we also have plans to use said library in https://github.com/audriga/nextcloud-jmap/ .

Regards,

Joris

Fastmail:
While drafting the spec, I built an experimental implementation. We definitely will implement JSContact at Fastmail.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
No

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
we checked the ABNF syntax with the tool.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
N/A
8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

ABNF syntax has been checked
## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
Yes
10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
we are in the Application-layer purpose-specific data encoding: iCalendar, vCard, jCard, jCal. Since the document defines the format, I am not sure I understand the question bu I woudl say it is N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?
Standards Track is appropriated as interoperability is necessary.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
Both authors confirmed on the list they are not aware of any IPR

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
Both authors confirmed on the list they are willing to be authors

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
I think we are pretty fine.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
No
16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
None.
17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
No
18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
No
19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
No
20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

yes this is the purpose of the document.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The authors are good suggestions for expert review. They confirmed their willingness to become expert review.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
yes

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
No

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

yes.
The document has an implementation section:
"""
3.  Implementation Status

  NOTE: Please remove this section and the reference to [RFC7942] prior
  to publication as an RFC.  This section records the status of known
  implementations of the protocol defined by this specification at the
  time of posting of this Internet-Draft, and is based on a proposal
  described in [RFC7942].  The description of implementations in this
  section is intended to assist the IETF in its decision processes in
  progressing drafts to RFCs.  Please note that the listing of any
  individual implementation here does not imply endorsement by the
  IETF.  Furthermore, no effort has been spent to verify the
  information presented here that was supplied by IETF contributors.
  This is not intended as, and must not be construed to be, a catalog
  of available implementations or their features.  Readers are advised
  to note that other implementations may exist.  According to
  [RFC7942], "this will allow reviewers and working groups to assign
  due consideration to documents that have the benefit of running code,
  which may serve as evidence of valuable experimentation and feedback
  that have made the implemented protocols more mature.  It is up to
  the individual working groups to use this information as they see
  fit".
"""

Other implementations have been mentioned on the mailing list.
from Joris Baum (audriga):
Hi Daniel,

regarding 4):

* we have implemented draft-ietf-calext-jscontact and draft-ietf-calext-jscontact-vcard in a new library used in https://github.com/audriga/roundcube-jmap . We are currently using that version in production at audriga. We did not implement the most current version of the spec though and have yet to publish our changes on GitHub.

* we also have plans to use said library in https://github.com/audriga/nextcloud-jmap/ .

Regards,

Joris

Fastmail:
While drafting the spec, I built an experimental implementation. We definitely will implement JSContact at Fastmail.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
No

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
we checked the ABNF syntax with the tool.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
N/A
8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

ABNF syntax has been checked
## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
Yes
10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
we are in the Application-layer purpose-specific data encoding: iCalendar, vCard, jCard, jCal. Since the document defines the format, I am not sure I understand the question bu I woudl say it is N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?
Standards Track is appropriated as interoperability is necessary.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
Both authors confirmed on the list they are not aware of any IPR

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
Both authors confirmed on the list they are willing to be authors

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
I think we are pretty fine.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
No
16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
None.
17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
No
18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
No
19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
No
20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

yes this is the purpose of the document.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The authors are good suggestions for expert review. They confirmed their willingness to become expert review.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
yes

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
No

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

yes.
The document has an implementation section:
"""
3.  Implementation Status

  NOTE: Please remove this section and the reference to [RFC7942] prior
  to publication as an RFC.  This section records the status of known
  implementations of the protocol defined by this specification at the
  time of posting of this Internet-Draft, and is based on a proposal
  described in [RFC7942].  The description of implementations in this
  section is intended to assist the IETF in its decision processes in
  progressing drafts to RFCs.  Please note that the listing of any
  individual implementation here does not imply endorsement by the
  IETF.  Furthermore, no effort has been spent to verify the
  information presented here that was supplied by IETF contributors.
  This is not intended as, and must not be construed to be, a catalog
  of available implementations or their features.  Readers are advised
  to note that other implementations may exist.  According to
  [RFC7942], "this will allow reviewers and working groups to assign
  due consideration to documents that have the benefit of running code,
  which may serve as evidence of valuable experimentation and feedback
  that have made the implemented protocols more mature.  It is up to
  the individual working groups to use this information as they see
  fit".
"""

Other implementations have been mentioned on the mailing list.
from Joris Baum (audriga):
Hi Daniel,

regarding 4):

* we have implemented draft-ietf-calext-jscontact and draft-ietf-calext-jscontact-vcard in a new library used in https://github.com/audriga/roundcube-jmap . We are currently using that version in production at audriga. We did not implement the most current version of the spec though and have yet to publish our changes on GitHub.

* we also have plans to use said library in https://github.com/audriga/nextcloud-jmap/ .

Regards,

Joris

Fastmail:
While drafting the spec, I built an experimental implementation. We definitely will implement JSContact at Fastmail.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
No

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
we checked the ABNF syntax with the tool.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
N/A
8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

ABNF syntax has been checked
## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
Yes
10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
we are in the Application-layer purpose-specific data encoding: iCalendar, vCard, jCard, jCal. Since the document defines the format, I am not sure I understand the question bu I woudl say it is N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?
Standards Track is appropriated as interoperability is necessary.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
XXX Robert disclosed it on the mailing list.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
XXX, Robert confirmed on the list

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
I think we are pretty fine.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
No
16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
None.
17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
No
18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
No
19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
No
20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

yes this is the purpose of the document.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The authors are good suggestions for expert review.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/