Skip to main content

vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP)
RFC 8605

Revision differences

Document history

Date Rev. By Action
2019-05-14
01 (System)
Received changes through RFC Editor sync (created alias RFC 8605, changed title to 'vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol …
Received changes through RFC Editor sync (created alias RFC 8605, changed title to 'vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP)', changed abstract to 'This document defines extensions to the vCard data format for representing and exchanging contact information used to implement the Internet Corporation for Assigned Names and Numbers (ICANN) operational profile for the Registration Data Access Protocol (RDAP).  The property and parameter defined here are used to add values to RDAP responses that are consistent with ICANN policies.', changed pages to 7, changed standardization level to Informational, changed state to RFC, added RFC published event at 2019-05-14, changed IESG state to RFC Published)
2019-05-14
01 (System) RFC published
2019-05-09
01 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2019-05-09
01 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2019-05-06
01 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2019-05-06
01 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2019-04-18
01 (System) RFC Editor state changed to EDIT
2019-04-18
01 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2019-04-18
01 (System) Announcement was received by RFC Editor
2019-04-18
01 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2019-04-17
01 (System) IANA Action state changed to Waiting on Authors from In Progress
2019-04-15
01 (System) IANA Action state changed to In Progress
2019-04-15
01 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2019-04-15
01 Cindy Morgan IESG has approved the document
2019-04-15
01 Cindy Morgan Closed "Approve" ballot
2019-04-12
01 Amy Vezza Ballot approval text was generated
2019-04-12
01 Roman Danyliw [Ballot comment]
Thank you for addressing my Comment.
2019-04-12
01 Roman Danyliw Ballot comment text updated for Roman Danyliw
2019-04-12
01 Alexey Melnikov IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed
2019-04-12
01 Scott Hollenbeck New version available: draft-hollenbeck-vcarddav-icann-rdap-extensions-01.txt
2019-04-12
01 (System) New version approved
2019-04-12
01 (System) Request for posting confirmation emailed to previous authors: Scott Hollenbeck , Roger Carney
2019-04-12
01 Scott Hollenbeck Uploaded new revision
2019-04-11
00 Cindy Morgan IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from Waiting for Writeup
2019-04-11
00 Benjamin Kaduk
[Ballot comment]
Two addresses are used in the examples for the CC parameter; the first (TYPE=work)
seems to be a real address (a Verisign office) …
[Ballot comment]
Two addresses are used in the examples for the CC parameter; the first (TYPE=work)
seems to be a real address (a Verisign office) whereas the second (TYPE=home)
appears to be dummy data.  I don't know if there's a desire or need to make the
examples consistently real or consistently fake (though putting someone's real
home address in an RFC is perhaps unwise).
2019-04-11
00 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2019-04-10
00 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2019-04-10
00 Alissa Cooper
[Ballot comment]
Section 5 says:

"The CONTACT-URI value is purposefully intended to be a publicly
  visible contact reference, and as such, it cannot require …
[Ballot comment]
Section 5 says:

"The CONTACT-URI value is purposefully intended to be a publicly
  visible contact reference, and as such, it cannot require privacy
  protection."

The publication of the URI itself makes sense, but this makes it sound as if the URI scheme chosen has no privacy implications. Surely if the point of supporting this is to protect people's privacy, than an HTTPS CONTACT-URI is preferable to an HTTP one. I would suggest modifying this text to make that more clear.
2019-04-10
00 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2019-04-10
00 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2019-04-10
00 Roman Danyliw [Ballot comment]
An ABNF documentation nit, consider adding references inline for the component parts:

; pref-param from RFC 6350
; uri from RFC 3986
2019-04-10
00 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2019-04-10
00 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2019-04-10
00 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2019-04-09
00 Adam Roach [Ballot Position Update] New position, Yes, has been recorded for Adam Roach
2019-04-08
00 Warren Kumari
[Ballot comment]
Just a small nit:

While reading this I kept stumbling over "Namespace: " -- it really looks like the authors forgot to fill …
[Ballot comment]
Just a small nit:

While reading this I kept stumbling over "Namespace: " -- it really looks like the authors forgot to fill in this section, and I had to go look at the Registry and RFC 6350 to confirm that this is an empty value.
As a courtesy to future readers I think it would be helpful to include a sentence saying that the Namespace: attributes are intentionally blank (kind of like "This page intentionally left blank." :-))
2019-04-08
00 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2019-04-07
00 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2019-04-05
00 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2019-04-02
00 Mirja Kühlewind
[Ballot comment]
Looking at RFC6350, was this step followed:
"The registration procedure begins when a completed registration
  template, defined in the sections below, …
[Ballot comment]
Looking at RFC6350, was this step followed:
"The registration procedure begins when a completed registration
  template, defined in the sections below, is sent to vcarddav@ietf.org
  and iana@iana.org."
?
2019-04-02
00 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2019-03-29
00 Alexey Melnikov Ballot has been issued
2019-03-29
00 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2019-03-29
00 Alexey Melnikov Created "Approve" ballot
2019-03-29
00 Alexey Melnikov Ballot writeup was changed
2019-03-11
00 Alexey Melnikov Placed on agenda for telechat - 2019-04-11
2019-03-11
00 Alexey Melnikov Changed consensus to Yes from Unknown
2019-02-27
00 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-02-26
00 Shwetha Bhandari Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Shwetha Bhandari. Sent review to list.
2019-02-25
00 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2019-02-25
00 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-hollenbeck-vcarddav-icann-rdap-extensions-00. 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-hollenbeck-vcarddav-icann-rdap-extensions-00. If any part of this review is inaccurate, please let us know.

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

First, in the vCard Properties registry on the vCard Elements registry page located at:

https://www.iana.org/assignments/vcard-elements/

a single, new registration is to be made as follows:

Namespace:
Property: CONTACT-URI
Reference: [ RFC-to-be; Section 2.1 ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the vCard Parameters registry also on the vCard Elements registry page located at:

https://www.iana.org/assignments/vcard-elements/

a single, new registration is to be made as follows:

Namespace:
Property: CC
Reference: [ RFC-to-be; Section 3.1 ]

As this also requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

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.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-02-07
00 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Derrell Piper.
2019-02-05
00 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Shwetha Bhandari
2019-02-05
00 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Shwetha Bhandari
2019-02-04
00 Roni Even Request for Last Call review by GENART Completed: Ready. Reviewer: Roni Even.
2019-01-31
00 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2019-01-31
00 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2019-01-31
00 Tero Kivinen Request for Last Call review by SECDIR is assigned to Derrell Piper
2019-01-31
00 Tero Kivinen Request for Last Call review by SECDIR is assigned to Derrell Piper
2019-01-30
00 Cindy Morgan IANA Review state changed to IANA - Review Needed
2019-01-30
00 Cindy Morgan
The following Last Call announcement was sent out (ends 2019-02-27):

From: The IESG
To: IETF-Announce
CC: alexey.melnikov@isode.com, draft-hollenbeck-vcarddav-icann-rdap-extensions@ietf.org, rwilhelm@verisign.com
Reply-To: ietf@ietf.org
Sender:
Subject: …
The following Last Call announcement was sent out (ends 2019-02-27):

From: The IESG
To: IETF-Announce
CC: alexey.melnikov@isode.com, draft-hollenbeck-vcarddav-icann-rdap-extensions@ietf.org, rwilhelm@verisign.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (vCard Format Extensions: Internet Corporation for Assigned Names and Numbers (ICANN) Extensions for the Registration Data Access Protocol (RDAP)) to Informational RFC


The IESG has received a request from an individual submitter to consider the
following document: - 'vCard Format Extensions: Internet Corporation for
Assigned Names and
  Numbers (ICANN) Extensions for the Registration Data Access
  Protocol (RDAP)'
  as Informational
  RFC

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
ietf@ietf.org mailing lists by 2019-02-27. 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 document defines extensions to the vCard data format for
  representing and exchanging contact information used to implement the
  Internet Corporation for Assigned Names and Numbers (ICANN)
  operational profile for the Registration Data Access Protocol (RDAP).
  The property and parameter defined here are used to add values to
  RDAP responses that are consistent with ICANN policies.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-hollenbeck-vcarddav-icann-rdap-extensions/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-hollenbeck-vcarddav-icann-rdap-extensions/ballot/


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




2019-01-30
00 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2019-01-30
00 Alexey Melnikov Last call was requested
2019-01-30
00 Alexey Melnikov Last call announcement was generated
2019-01-30
00 Alexey Melnikov Ballot approval text was generated
2019-01-30
00 Alexey Melnikov Ballot writeup was generated
2019-01-30
00 Alexey Melnikov IESG state changed to Last Call Requested from AD Evaluation
2019-01-30
00 Alexey Melnikov IESG state changed to AD Evaluation from Publication Requested
2019-01-30
00 Alexey Melnikov Assigned to Applications and Real-Time Area
2019-01-30
00 Alexey Melnikov Intended Status changed to Informational
2019-01-30
00 Alexey Melnikov IESG process started in state Publication Requested
2019-01-30
00 Alexey Melnikov Shepherding AD changed to Alexey Melnikov
2019-01-30
00 Alexey Melnikov
1.  Summary

The document shepherd is Richard Wilhelm.  The responsible Area Director is Alexey Melnikov.

The document defines extensions to the vCard data format for …
1.  Summary

The document shepherd is Richard Wilhelm.  The responsible Area Director is Alexey Melnikov.

The document defines extensions to the vCard data format for representing and exchanging contact information used to implement the Internet Corporation for Assigned Names and Numbers (ICANN) operational profile for the Registration Data Access Protocol (RDAP).  The property and parameter defined here are used to add values to RDAP responses that are consistent with ICANN policies.


2.  Review and Consensus

The extensions to the vcard Data format, both the property and the parameter, were the topic of discussion on the ICANN RDAP Pilot Working Group mailing list and on regularly scheduled teleconferences of ICANN RDAP Pilot Working Group members.  The topic was available for discussion at face-to-face meetings of the ICANN RDAP Pilot Working Group, but did not merit material discussion.

There was consistent and broad consensus among the RDAP Pilot Working Group to make the changes described in the document.

While these discussions were not part of the IETF REGEXT Working Group, there was considerable overlap between members of the RDAP Pilot Working Group and the REGEXT Working Group throughout the period of these discussions.


3.  Intellectual Property

The author has confirmed conformance with BCP 78/79.  There are no IPR disclosures on the document.

4.  Other Points

As RDAP implementations evolve and ICANN policies evolve, the RDAP community expects a period of transition that may result in other vCard extensions of a similar sort.
2019-01-30
00 Alexey Melnikov Notification list changed to Richard Wilhelm <rwilhelm@verisign.com>
2019-01-30
00 Alexey Melnikov Document shepherd changed to Richard Wilhelm
2019-01-30
00 Alexey Melnikov Stream changed to IETF from None
2018-11-07
00 Scott Hollenbeck New version available: draft-hollenbeck-vcarddav-icann-rdap-extensions-00.txt
2018-11-07
00 (System) New version approved
2018-11-07
00 Scott Hollenbeck Request for posting confirmation emailed  to submitter and authors: Scott Hollenbeck , Roger Carney
2018-11-07
00 Scott Hollenbeck Uploaded new revision