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

[Brian Mountford]

So when you specify that the vCard addresses must be structured, it is up
to the RDAP server to choose whichever of the two structured formats they
would like to use. Is that correct?

On Fri, Jul 22, 2016 at 3:47 PM, Gustavo Lozano <gustavo.lozano at icann.org>
wrote:

> 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/43ea5dcc/attachment-0001.html>