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

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>