[gtld-tech] gtld-tech Digest, Vol 39, Issue 5

[Gustavo Lozano]

Brian,

Comments inline.

Regards,
Gustavo

From:  <gtld-tech-bounces at icann.org> on behalf of Brian Mountford via
gtld-tech <gtld-tech at icann.org>
Reply-To:  Brian Mountford <mountford at google.com>
Date:  Friday, July 22, 2016 at 10:45
To:  "gtld-tech at icann.org" <gtld-tech at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20160722/29a815d7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4701 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20160722/29a815d7/smime-0001.p7s>