[gtld-tech] gtld-tech Digest, Vol 39, Issue 5
Gustavo Lozano
gustavo.lozano at icann.org
Sat Jul 23 01:09:52 UTC 2016
Brian,
My reading of RFC7095 is that there is only one type of structured address,
an example of an structured address is found in Appendix C of RC7483.
RFC7095 provides two examples of structured addresses, and one of the
examples shows a street JSON element that contains several data elements.
The example showing (see below) several data elements is the expected output
when two or more <contact:street> elements exists in the contact object.
["adr", {}, "text",
[
"", "",
["My Street", "Left Side", "Second Shack"],
"Hometown", "PA", "18252", "U.S.A."
]
]
Regards,
Gustavo
From: Brian Mountford <mountford at google.com>
Date: Friday, July 22, 2016 at 12:53
To: Gustavo Lozano <gustavo.lozano at icann.org>
Cc: "gtld-tech at icann.org" <gtld-tech at icann.org>
Subject: Re: [gtld-tech] gtld-tech Digest, Vol 39, Issue 5
> 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/20160723/dc432cbc/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/20160723/dc432cbc/smime-0001.p7s>
More information about the gtld-tech
mailing list