JSContact: A JSON representation of contact data
draft-ietf-calext-jscontact-17
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-05-07
|
(System) | Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-calext-jscontact and RFC 9553, changed IESG state to RFC … Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-calext-jscontact and RFC 9553, changed IESG state to RFC Published) |
|
2024-04-19
|
17 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2024-04-19
|
17 | (System) | RFC Editor state changed to AUTH48 from AUTH48-DONE |
2024-04-09
|
17 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2024-03-06
|
17 | (System) | RFC Editor state changed to AUTH48 |
2024-03-04
|
17 | Robert Stepanek | New version available: draft-ietf-calext-jscontact-17.txt |
2024-03-04
|
17 | Robert Stepanek | New version accepted (logged-in submitter: Robert Stepanek) |
2024-03-04
|
17 | Robert Stepanek | Uploaded new revision |
2024-02-14
|
16 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2023-11-13
|
16 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2023-11-09
|
16 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2023-11-09
|
16 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2023-11-09
|
16 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2023-11-09
|
16 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2023-11-08
|
16 | Robert Stepanek | New version available: draft-ietf-calext-jscontact-16.txt |
2023-11-08
|
16 | Robert Stepanek | New version accepted (logged-in submitter: Robert Stepanek) |
2023-11-08
|
16 | Robert Stepanek | Uploaded new revision |
2023-10-31
|
15 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2023-10-31
|
15 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2023-10-27
|
15 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2023-10-25
|
15 | (System) | RFC Editor state changed to EDIT |
2023-10-25
|
15 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2023-10-25
|
15 | (System) | Announcement was received by RFC Editor |
2023-10-24
|
15 | (System) | IANA Action state changed to In Progress |
2023-10-24
|
15 | (System) | Removed all action holders (IESG state changed) |
2023-10-24
|
15 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2023-10-24
|
15 | Cindy Morgan | IESG has approved the document |
2023-10-24
|
15 | Cindy Morgan | Closed "Approve" ballot |
2023-10-24
|
15 | Cindy Morgan | Ballot approval text was generated |
2023-10-24
|
15 | Roman Danyliw | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2023-10-24
|
15 | Barry Leiba | Request closed, assignment withdrawn: Martin Dürst Last Call ARTART review |
2023-10-24
|
15 | Barry Leiba | Closed request for Last Call review by ARTART with state 'Overtaken by Events': Document has finished IESG processing |
2023-10-22
|
15 | Lars Eggert | [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). … [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 |
2023-10-22
|
15 | Lars Eggert | Ballot comment text updated for Lars Eggert |
2023-10-19
|
15 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation |
2023-10-18
|
15 | Paul Wouters | [Ballot comment] I reviewed the changes since the last IESG round. Thanks for adding internationalization support. One nit: Implementations MUST NOT … [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? |
2023-10-18
|
15 | Paul Wouters | [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters |
2023-10-17
|
15 | Éric Vyncke | [Ballot comment] Thanks to the authors for addressing all my comments on -08 and thanks to Roman for the 2nd IETF Last Call. |
2023-10-17
|
15 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2023-10-17
|
15 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2023-10-17
|
15 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2023-10-17
|
15 | Francesca Palombini | [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 … [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. |
2023-10-17
|
15 | Francesca Palombini | [Ballot Position Update] New position, Yes, has been recorded for Francesca Palombini |
2023-10-16
|
15 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2023-10-14
|
15 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2023-10-13
|
15 | Lars Eggert | [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). … [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 |
2023-10-13
|
15 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2023-10-12
|
15 | Jim Guichard | [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard |
2023-10-12
|
15 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2023-10-12
|
15 | Roman Danyliw | [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 … [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. |
2023-10-12
|
15 | Roman Danyliw | Ballot comment text updated for Roman Danyliw |
2023-10-12
|
15 | Roman Danyliw | [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw |
2023-10-12
|
15 | Roman Danyliw | Created "Approve" ballot |
2023-10-12
|
15 | Roman Danyliw | Closed "Approve" ballot |
2023-10-12
|
15 | Roman Danyliw | Ballot has been issued |
2023-10-12
|
15 | Roman Danyliw | Ballot writeup was changed |
2023-10-12
|
15 | Roman Danyliw | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2023-10-12
|
15 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2023-10-11
|
15 | Roman Danyliw | Telechat date has been changed to 2023-10-19 from 2023-04-13 |
2023-10-11
|
15 | (System) | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2023-10-11
|
15 | David Dong | (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 … (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 |
2023-09-29
|
15 | Barry Leiba | Request for Last Call review by ARTART is assigned to Martin Dürst |
2023-09-28
|
15 | Cindy Morgan | 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 … 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. |
2023-09-28
|
15 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2023-09-28
|
15 | Roman Danyliw | Last call was requested |
2023-09-28
|
15 | Roman Danyliw | IESG state changed to Last Call Requested from IESG Evaluation::AD Followup |
2023-09-28
|
15 | Roman Danyliw | Last call announcement was changed |
2023-09-28
|
15 | Roman Danyliw | Last call announcement was generated |
2023-09-18
|
15 | Robert Stepanek | New version available: draft-ietf-calext-jscontact-15.txt |
2023-09-18
|
15 | Robert Stepanek | New version accepted (logged-in submitter: Robert Stepanek) |
2023-09-18
|
15 | Robert Stepanek | Uploaded new revision |
2023-08-31
|
14 | Robert Stepanek | New version available: draft-ietf-calext-jscontact-14.txt |
2023-08-31
|
14 | Robert Stepanek | New version accepted (logged-in submitter: Robert Stepanek) |
2023-08-31
|
14 | Robert Stepanek | Uploaded new revision |
2023-08-29
|
13 | Roman Danyliw | Discussion of issues identified by the the ARTART review which occurred after IESG review continues at https://mailarchive.ietf.org/arch/msg/art/WxMhQOuODz3MSVomrM6N5LajbMc/ |
2023-08-29
|
13 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to Yes from No Objection |
2023-08-29
|
13 | Roman Danyliw | [Ballot comment] Thank you to Derek Atkins for the SECDIR review. Thank your for addressing my DISCUSS and COMMENT feedback. |
2023-08-29
|
13 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2023-07-24
|
13 | Robert Stepanek | New version available: draft-ietf-calext-jscontact-13.txt |
2023-07-24
|
13 | Robert Stepanek | New version accepted (logged-in submitter: Robert Stepanek) |
2023-07-24
|
13 | Robert Stepanek | Uploaded new revision |
2023-07-03
|
12 | Paul Wouters | [Ballot comment] Thanks for addressing DISCUSS and comments. I've updated my ballot to Yes. |
2023-07-03
|
12 | Paul Wouters | [Ballot Position Update] Position for Paul Wouters has been changed to Yes from Discuss |
2023-07-03
|
12 | Robert Stepanek | New version available: draft-ietf-calext-jscontact-12.txt |
2023-07-03
|
12 | (System) | New version approved |
2023-07-03
|
12 | (System) | Request for posting confirmation emailed to previous authors: Mario Loffredo , Robert Stepanek |
2023-07-03
|
12 | Robert Stepanek | Uploaded new revision |
2023-06-02
|
11 | Robert Stepanek | New version available: draft-ietf-calext-jscontact-11.txt |
2023-06-02
|
11 | Robert Stepanek | New version accepted (logged-in submitter: Robert Stepanek) |
2023-06-02
|
11 | Robert Stepanek | Uploaded new revision |
2023-05-02
|
10 | Éric Vyncke | [Ballot comment] Thank you for addressing my DISCUSS and COMMENT points in https://mailarchive.ietf.org/arch/msg/calsify/Y2Evi7HdbiTkj-nW1gkO2z2c2eM/ Regards -éric |
2023-05-02
|
10 | Éric Vyncke | [Ballot Position Update] Position for Éric Vyncke has been changed to No Objection from Discuss |
2023-04-28
|
10 | Roman Danyliw | [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 … [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). |
2023-04-28
|
10 | Roman Danyliw | [Ballot comment] Thank you to Derek Atkins for the SECDIR review. Thank your for addressing my COMMENT feedback. |
2023-04-28
|
10 | Roman Danyliw | Ballot comment and discuss text updated for Roman Danyliw |
2023-04-21
|
10 | Martin Dürst | Request for Last Call review by ARTART Completed: Not Ready. Reviewer: Martin Dürst. Sent review to list. |
2023-04-19
|
10 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
2023-04-19
|
10 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2023-04-19
|
10 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2023-04-19
|
10 | Robert Stepanek | New version available: draft-ietf-calext-jscontact-10.txt |
2023-04-19
|
10 | Robert Stepanek | New version accepted (logged-in submitter: Robert Stepanek) |
2023-04-19
|
10 | Robert Stepanek | Uploaded new revision |
2023-04-13
|
09 | (System) | Changed action holders to Roman Danyliw, Robert Stepanek, Mario Loffredo (IESG state changed) |
2023-04-13
|
09 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2023-04-13
|
09 | Andrew Alston | [Ballot Position Update] New position, No Objection, has been recorded for Andrew Alston |
2023-04-12
|
09 | Murray Kucherawy | [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..." … [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. |
2023-04-12
|
09 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2023-04-12
|
09 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2023-04-12
|
09 | Zaheduzzaman Sarker | [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 … [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? |
2023-04-12
|
09 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2023-04-12
|
09 | Éric Vyncke | [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 … [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). |
2023-04-12
|
09 | Éric Vyncke | [Ballot comment] # COMMENTS (non blocking) ## Why not YANG ? Is there a reason why YANG was not used as the data model language … [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 ? ;-) |
2023-04-12
|
09 | Éric Vyncke | [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke |
2023-04-12
|
09 | Lars Eggert | [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). … [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 |
2023-04-12
|
09 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2023-04-12
|
09 | Robert Wilton | [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 … [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 |
2023-04-12
|
09 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2023-04-11
|
09 | Paul Wouters | [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: … [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? |
2023-04-11
|
09 | Paul Wouters | [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 … [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. |
2023-04-11
|
09 | Paul Wouters | [Ballot Position Update] New position, Discuss, has been recorded for Paul Wouters |
2023-04-10
|
09 | Roman Danyliw | [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 … [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? |
2023-04-10
|
09 | Roman Danyliw | [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 … [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. |
2023-04-10
|
09 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2023-04-10
|
09 | Roman Danyliw | Changed action holders to Roman Danyliw (Responsible AD change) |
2023-04-10
|
09 | Jim Guichard | [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard |
2023-04-08
|
09 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2023-04-06
|
09 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2023-04-05
|
09 | Roman Danyliw | Ballot approval text was generated |
2023-04-05
|
09 | Roman Danyliw | Shepherding AD changed to Roman Danyliw |
2023-04-05
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2023-04-05
|
09 | Robert Stepanek | New version available: draft-ietf-calext-jscontact-09.txt |
2023-04-05
|
09 | Robert Stepanek | New version accepted (logged-in submitter: Robert Stepanek) |
2023-04-05
|
09 | Robert Stepanek | Uploaded new revision |
2023-04-05
|
09 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2023-03-25
|
08 | Cindy Morgan | Placed on agenda for telechat - 2023-04-13 |
2023-03-25
|
08 | Francesca Palombini | Ballot has been issued |
2023-03-25
|
08 | Francesca Palombini | [Ballot Position Update] New position, Yes, has been recorded for Francesca Palombini |
2023-03-25
|
08 | Francesca Palombini | Created "Approve" ballot |
2023-03-25
|
08 | Francesca Palombini | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2023-03-22
|
08 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Derek Atkins. Submission of review completed at an earlier date. |
2023-03-17
|
08 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2023-03-16
|
08 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Derek Atkins. |
2023-03-15
|
08 | Reese Enghardt | Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Reese Enghardt. Sent review to list. |
2023-03-15
|
08 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2023-03-15
|
08 | David Dong | (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 … (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 |
2023-03-15
|
08 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': not enough time before end of LC |
2023-03-13
|
08 | Robert Stepanek | New version available: draft-ietf-calext-jscontact-08.txt |
2023-03-13
|
08 | Robert Stepanek | New version accepted (logged-in submitter: Robert Stepanek) |
2023-03-13
|
08 | Robert Stepanek | Uploaded new revision |
2023-03-12
|
07 | Niclas Comstedt | Assignment of request for Last Call review by OPSDIR to Niclas Comstedt was rejected |
2023-03-10
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Niclas Comstedt |
2023-03-09
|
07 | Barry Leiba | Request for Last Call review by ARTART is assigned to Martin Dürst |
2023-03-09
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Derek Atkins |
2023-03-09
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Reese Enghardt |
2023-03-03
|
07 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2023-03-03
|
07 | Cindy Morgan | 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 … 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. |
2023-03-03
|
07 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2023-03-03
|
07 | Francesca Palombini | Last call was requested |
2023-03-03
|
07 | Francesca Palombini | Last call announcement was generated |
2023-03-03
|
07 | Francesca Palombini | Ballot approval text was generated |
2023-03-03
|
07 | Francesca Palombini | AD review posted: https://mailarchive.ietf.org/arch/msg/calsify/ndRG1EQiVMtGIWzPBSS14fmC8cc/ |
2023-03-03
|
07 | Francesca Palombini | IESG state changed to Last Call Requested from AD Evaluation |
2023-02-07
|
07 | Francesca Palombini | Tag Doc Shepherd Follow-up Underway cleared. |
2023-02-07
|
07 | (System) | Changed action holders to Francesca Palombini (IESG state changed) |
2023-02-07
|
07 | Francesca Palombini | IESG state changed to AD Evaluation from Publication Requested |
2023-02-07
|
07 | Francesca Palombini | Ballot writeup was changed |
2023-01-10
|
07 | Daniel Migault | # 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 … # 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/ |
2023-01-10
|
07 | Daniel Migault | Responsible AD changed to Francesca Palombini |
2023-01-10
|
07 | Daniel Migault | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2023-01-10
|
07 | Daniel Migault | IESG state changed to Publication Requested from I-D Exists |
2023-01-10
|
07 | Daniel Migault | Document is now in IESG state Publication Requested |
2023-01-10
|
07 | Daniel Migault | # 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 … # 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/ |
2023-01-10
|
07 | Robert Stepanek | New version available: draft-ietf-calext-jscontact-07.txt |
2023-01-10
|
07 | Robert Stepanek | New version accepted (logged-in submitter: Robert Stepanek) |
2023-01-10
|
07 | Robert Stepanek | Uploaded new revision |
2023-01-04
|
06 | Daniel Migault | # 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 … # 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/ |
2022-12-20
|
06 | Daniel Migault | Notification list changed to mglt.ietf@gmail.com because the document shepherd was set |
2022-12-20
|
06 | Daniel Migault | Document shepherd changed to Daniel Migault |
2022-12-20
|
06 | Daniel Migault | Tag Doc Shepherd Follow-up Underway set. |
2022-12-20
|
06 | Daniel Migault | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2022-12-09
|
06 | Robert Stepanek | New version available: draft-ietf-calext-jscontact-06.txt |
2022-12-09
|
06 | Robert Stepanek | New version accepted (logged-in submitter: Robert Stepanek) |
2022-12-09
|
06 | Robert Stepanek | Uploaded new revision |
2022-11-25
|
05 | Robert Stepanek | New version available: draft-ietf-calext-jscontact-05.txt |
2022-11-25
|
05 | Robert Stepanek | New version accepted (logged-in submitter: Robert Stepanek) |
2022-11-25
|
05 | Robert Stepanek | Uploaded new revision |
2022-11-08
|
04 | Bron Gondwana | Added to session: IETF-115: calext Tue-1630 |
2022-10-24
|
04 | Robert Stepanek | New version available: draft-ietf-calext-jscontact-04.txt |
2022-10-24
|
04 | Robert Stepanek | New version accepted (logged-in submitter: Robert Stepanek) |
2022-10-24
|
04 | Robert Stepanek | Uploaded new revision |
2022-07-11
|
03 | Robert Stepanek | New version available: draft-ietf-calext-jscontact-03.txt |
2022-07-11
|
03 | Robert Stepanek | New version accepted (logged-in submitter: Robert Stepanek) |
2022-07-11
|
03 | Robert Stepanek | Uploaded new revision |
2022-04-11
|
02 | Robert Stepanek | New version available: draft-ietf-calext-jscontact-02.txt |
2022-04-11
|
02 | (System) | New version accepted (logged-in submitter: Robert Stepanek) |
2022-04-11
|
02 | Robert Stepanek | Uploaded new revision |
2022-03-07
|
01 | Bron Gondwana | Changed consensus to Yes from Unknown |
2022-03-07
|
01 | Bron Gondwana | Intended Status changed to Proposed Standard from None |
2022-03-07
|
01 | Robert Stepanek | This document now replaces draft-stepanek-jscontact, draft-ietf-jmap-jscontact instead of draft-stepanek-jscontact |
2022-03-07
|
01 | Robert Stepanek | New version available: draft-ietf-calext-jscontact-01.txt |
2022-03-07
|
01 | (System) | New version accepted (logged-in submitter: Robert Stepanek) |
2022-03-07
|
01 | Robert Stepanek | Uploaded new revision |
2020-01-17
|
00 | Robert Stepanek | This document now replaces draft-stepanek-jscontact instead of None |
2020-01-17
|
00 | Robert Stepanek | New version available: draft-ietf-calext-jscontact-00.txt |
2020-01-17
|
00 | (System) | New version accepted (logged-in submitter: Robert Stepanek) |
2020-01-17
|
00 | Robert Stepanek | Uploaded new revision |