draft-ietf-weirds-json-response-12.txt   draft-ietf-weirds-json-response-13.txt 
Network Working Group A. Newton Network Working Group A. Newton
Internet-Draft ARIN Internet-Draft ARIN
Intended status: Standards Track S. Hollenbeck Intended status: Standards Track S. Hollenbeck
Expires: May 23, 2015 Verisign Labs Expires: June 5, 2015 Verisign Labs
November 19, 2014 December 2, 2014
JSON Responses for the Registration Data Access Protocol (RDAP) JSON Responses for the Registration Data Access Protocol (RDAP)
draft-ietf-weirds-json-response-12 draft-ietf-weirds-json-response-13
Abstract Abstract
This document describes JSON data structures representing This document describes JSON data structures representing
registration information maintained by Regional Internet Registries registration information maintained by Regional Internet Registries
(RIRs) and Domain Name Registries (DNRs). These data structures are (RIRs) and Domain Name Registries (DNRs). These data structures are
used to form Registration Data Access Protocol (RDAP) query used to form Registration Data Access Protocol (RDAP) query
responses. responses.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 23, 2015. This Internet-Draft will expire on June 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 16, line 13 skipping to change at page 16, line 13
embedded: embedded:
{ {
"rdapConformance" : "rdapConformance" :
[ [
"rdap_level_0" "rdap_level_0"
], ],
"notices" : "notices" :
[ [
{ {
"title" : "Content Redacted", "title" : "Content Removed",
"description" : "description" :
[ [
"Without full authorization, content has been redacted.", "Without full authorization, content has been removed.",
"Sorry, dude!" "Sorry, dude!"
], ],
"links" : "links" :
[ [
{ {
"value" : "http://example.net/ip/192.0.2.0/24", "value" : "http://example.net/ip/192.0.2.0/24",
"rel" : "alternate", "rel" : "alternate",
"type" : "text/html", "type" : "text/html",
"href" : "http://www.example.com/redaction_policy.html" "href" : "http://www.example.com/redaction_policy.html"
} }
skipping to change at page 60, line 33 skipping to change at page 60, line 33
* Description: The information of the object instance is not * Description: The information of the object instance is not
designated for public consumption. This is most commonly designated for public consumption. This is most commonly
applied to entities. applied to entities.
* Registrant Name: IESG * Registrant Name: IESG
* Registrant Contact Information: iesg@ietf.org * Registrant Contact Information: iesg@ietf.org
8. 8.
* Value: redacted * Value: removed
* Type: status * Type: status
* Description: Some of the information of the object instance * Description: Some of the information of the object instance
has not been made available. This is most commonly applied has not been made available and has been removed. This is
to entities. most commonly applied to entities.
* Registrant Name: IESG * Registrant Name: IESG
* Registrant Contact Information: iesg@ietf.org * Registrant Contact Information: iesg@ietf.org
9. 9.
* Value: obscured * Value: obscured
* Type: status * Type: status
skipping to change at page 71, line 44 skipping to change at page 71, line 44
Internationalized Domain Names (IDNs) are denoted in this Internationalized Domain Names (IDNs) are denoted in this
specification by the separation of DNS names in LDH form and Unicode specification by the separation of DNS names in LDH form and Unicode
form (see Section 3). Representation of IDNs in registries is form (see Section 3). Representation of IDNs in registries is
described by the "variants" object in Section 5.3 and the suggested described by the "variants" object in Section 5.3 and the suggested
values listed in Section 10.2.5. values listed in Section 10.2.5.
13. Privacy Considerations 13. Privacy Considerations
This specification suggests status values to denote contact and This specification suggests status values to denote contact and
registrant information that has been marked as private and/or has registrant information that has been marked as private and/or has
been redacted or obscured. See Section 10.2.2 for the list of status been removed or obscured. See Section 10.2.2 for the complete list
values. See Appendix A.1 on guidance to apply those values to
contacts and registrants.
This specification suggests status values to denote contact and
registrant information that has been marked as private and/or has
been redacted or obscured. See Section 10.2.2 for the complete list
of status values. A few of the status values indicate that there are of status values. A few of the status values indicate that there are
privacy concerns associated with the object instance. For the privacy concerns associated with the object instance. The following
following status codes, the RECOMMENDED actions include: status codes SHOULD be used to describe data elements of a response
when appropriate:
private - The object is not be shared in query responses, unless private - The object is not be shared in query responses, unless
the user is authorized to view this information. the user is authorized to view this information.
redacted - Data elements within the object have been collected, removed - Data elements within the object have been collected, but
but have been omitted from the response. This option can be used have been omitted from the response. This option can be used to
to prevent unauthorized access to associated object instances prevent unauthorized access to associated object instances without
without the need to mark them as private. the need to mark them as private.
obscured - Data elements within the object have been collected, obscured - Data elements within the object have been collected,
but the response value has been altered so that values are not but the response value has been altered so that values are not
easily discernible. A value changed from "1212" to "XXXX" is an easily discernible. A value changed from "1212" to "XXXX" is an
example of obscured data. This option may reveal privacy example of obscured data. This option may reveal privacy
sensitive information and should only be used when data sensitive information and should only be used when data
sensitivity does not require a more protective option like sensitivity does not require a more protective option like
"private" or "redacted". "private" or "removed".
See Appendix A.1 for an example applying those values to contacts and See Appendix A.1 for an example applying those values to contacts and
registrants. registrants.
14. Contributing Authors and Acknowledgements 14. Contributing Authors and Acknowledgements
This document is derived from original work on RIR responses in JSON This document is derived from original work on RIR responses in JSON
by Byron J. Ellacott, Arturo L. Servin, Kaveh Ranjbar, and Andrew by Byron J. Ellacott, Arturo L. Servin, Kaveh Ranjbar, and Andrew
L. Newton. Additionally, this document incorporates work on DNR L. Newton. Additionally, this document incorporates work on DNR
responses in JSON by Ning Kong, Linlin Zhou, Jiagui Xie, and Sean responses in JSON by Ning Kong, Linlin Zhou, Jiagui Xie, and Sean
skipping to change at page 74, line 11 skipping to change at page 74, line 8
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
January 2014. January 2014.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014. Interchange Format", RFC 7159, March 2014.
[I-D.ietf-weirds-using-http] [I-D.ietf-weirds-using-http]
Newton, A., Ellacott, B., and N. Kong, "HTTP usage in the Newton, A., Ellacott, B., and N. Kong, "HTTP usage in the
Registration Data Access Protocol (RDAP)", draft-ietf- Registration Data Access Protocol (RDAP)", draft-ietf-
weirds-using-http-14 (work in progress), October 2014. weirds-using-http-15 (work in progress), November 2014.
[I-D.ietf-weirds-rdap-query] [I-D.ietf-weirds-rdap-query]
Newton, A. and S. Hollenbeck, "Registration Data Access Newton, A. and S. Hollenbeck, "Registration Data Access
Protocol Query Format", draft-ietf-weirds-rdap-query-16 Protocol Query Format", draft-ietf-weirds-rdap-query-16
(work in progress), October 2014. (work in progress), October 2014.
[I-D.ietf-weirds-rdap-sec] [I-D.ietf-weirds-rdap-sec]
Hollenbeck, S. and N. Kong, "Security Services for the Hollenbeck, S. and N. Kong, "Security Services for the
Registration Data Access Protocol", draft-ietf-weirds- Registration Data Access Protocol", draft-ietf-weirds-
rdap-sec-10 (work in progress), October 2014. rdap-sec-11 (work in progress), November 2014.
[ISO.3166.1988] [ISO.3166.1988]
International Organization for Standardization, "Codes for International Organization for Standardization, "Codes for
the representation of names of countries, 3rd edition", the representation of names of countries, 3rd edition",
ISO Standard 3166, August 1988. ISO Standard 3166, August 1988.
15.2. Informative References 15.2. Informative References
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
September 2004. September 2004.
skipping to change at page 91, line 17 skipping to change at page 91, line 17
'href' is now the only MUST in the a link. 'href' is now the only MUST in the a link.
-11 -11
Changes to address IETF Last Call comments. Changes to address IETF Last Call comments.
-12 -12
Changes to address IESG comments. Changes to address IESG comments.
-13
Changes to address Alyssa's DISCUSS.
'redacted' status changed to 'removed'
Authors' Addresses Authors' Addresses
Andrew Lee Newton Andrew Lee Newton
American Registry for Internet Numbers American Registry for Internet Numbers
3635 Concorde Parkway 3635 Concorde Parkway
Chantilly, VA 20151 Chantilly, VA 20151
US US
Email: andy@arin.net Email: andy@arin.net
URI: http://www.arin.net URI: http://www.arin.net
 End of changes. 14 change blocks. 
25 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/