Brian, Comments inline. Regards, Gustavo From: <gtld-tech-bounces@icann.org> on behalf of Brian Mountford via gtld-tech <gtld-tech@icann.org> Reply-To: Brian Mountford <mountford@google.com> Date: Friday, July 22, 2016 at 10:45 To: "gtld-tech@icann.org" <gtld-tech@icann.org> Subject: Re: [gtld-tech] gtld-tech Digest, Vol 39, Issue 5
Francisco,
I have questions about sections 1.5.14, 1.5.16 and 2.8.2. Profile Directive 1.5.14.
The domain object in the RDAP response MUST contain the following events:
* An event of eventAction type registration. * * An event of eventAction type expiration. * * An event of eventAction type last changed. The event of eventAction type last changed MUST be omitted if the domain name has not been updated since it was created. * * An event of eventAction type last update of RDAP database.
Is any particular ordering preferred in the results? Expiration will probably be later than last changed and last update. Should it come before or after the last changed and last update?
The RDAP profile does not define an order for elements.
Profile Directive 1.5.16. Entities MUST use jCard [RFC7095] structured addresses.
RFC 7095 defines two different types of structured address:
3.3.1.3. Structured Property Values
The vCard specification defines properties with structured values, for example, "GENDER" or "ADR". In vCard, a structured text value consists of one or multiple text components, delimited by the SEMICOLON character. Its equivalent in jCard is a structured property value, which is an array containing one element for each text component, with empty/missing text components represented by zero-length strings.
jCard Example:
["adr", {}, "text", [ "", "", "123 Main Street", "Any Town", "CA", "91921-1234", "U.S.A." ] ]
Some vCard properties, for example, ADR, also allow a structured value element that itself has multiple values. In this case, the element of the array describing the structured value is itself an array with one element for each of the component's multiple values.
jCard Example:
["adr", {}, "text", [ "", "", ["My Street", "Left Side", "Second Shack"], "Hometown", "PA", "18252", "U.S.A." ] ]
Which form is to be used in RDAP responses? If it is the first version (list of simple strings), what is to be done with addresses containing more than two street address lines?
Appendix C of RFC7483 provides an example of an structured address. Section 3.3.1.3 of RFC7095 provides an example (which you provided in this email and it¹s shown below) of an adr with multiple values in street. ["adr", {}, "text", [ "", "", ["My Street", "Left Side", "Second Shack"], "Hometown", "PA", "18252", "U.S.A." ] ] I think that these two examples (I.e. the example in RFC 7483 and the example in RFC 7095) provide guidance on how to represent the contact information in RDAP. Do you think that the profile should be updated to clarify? It's worth mentioning that RFC7483 is referenced from the profile.
Profile Directive 2.8.2. Registrar object lookup using an entity search on the fn element MUST be supported. RFC 7482 3.2.3. says: XXXX is a search pattern representing the "FN" property of an entity (such as a contact, registrant, or registrar) name as specified in Section 5.1 of [RFC7483].
This is straightforward enough when referring to contacts and registrants, but I am not sure how it applies to registrars. Our database stores registrars, which have a name, and also registrar contacts, which hang off registrars, and themselves also have names. Are you asking us to search by registrar name (which we would prefer), or by registrar contact name?
The search is by registrar name only. The profile is supporting the functionality defined in the Base Registry Agreement (see 1.6 of Section 4 of the Base Registry Agreement, https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved -09jan14-en.htm).
Thanks.
Brian