vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP)
draft-hollenbeck-vcarddav-icann-rdap-extensions-01
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
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 |