Re: [regext] Review of RDAP Profile & Implementation Guide

["Mack, Justin" <[e-mail]>]

Once we publish these documents to "the world", many registries and 
registrars will [loudly] give feedback about implementation difficulties 
with jCard.

My lead engineer today was unable to use a library to "marshall" the 
data into a suitable JSON object for the jCard data inside the RDAP 
object. This is due to requirements such as multiline addresses in 
array-only vs single-line non-array, various empty elements that must 
exist but are non-null (first two fields of the address), recent/future 
extensions such as "cc" (which I support but the country field should 
have allowed ISO 2-char to begin with), and the difficulty of inserting 
this block of jCard data embedded in a larger JSON document - which 
means at best we must "toString" the jCard data separately and insert it 
inside a more "pure" RDAP object, or simply print it out manually.

I hereby volunteer to co-author a future RFC for RDAP to deprecate jCard 
and output common key/value pairs of contact data in JSON, similar to 
the simple structure of WHOIS today. I'm withholding this time 
commitment until after the EPDP outcome and temp spec expiration so we 
can adapt to then-established policy, but I feel this effort will 
benefit the longevity of RDAP.  (Who thought WHOIS would last this long? 
Long live RDAP!)

Thanks.
  -justin



On 02/11/2019 07:59 AM, 'Hollenbeck, Scott' via RDAP Pilot WG wrote:
> It would be VERY helpful if people who are implementing the specifications send feedback to the IETF regext WG mailing list ([e-mail], cc'd here) noting the issues they're having. There's a much better chance of pushing back against the jCard stuff if we get multiple, independent reports of difficulty. As Gavin noted, it's NOT what we started with - we were strongly encouraged to include it in the spirit of reuse of existing standards, and we didn't have any strong reasons to push back.
>
> Scott
>
>> -----Original Message-----
>> From: [e-mail] <rdap-pilot-
>> [e-mail]> On Behalf Of Gavin Brown
>> Sent: Monday, February 11, 2019 9:12 AM
>> To: Richard Merdinger <[e-mail]>; Sarah Wyld
>> <[e-mail]>; [e-mail]
>> Subject: [EXTERNAL] Re: Review of RDAP Profile & Implementation Guide
>>
>> FWIW I always thought it was a mistake for RDAP to use jCard (I wish I'd said
>> something at the time).
>>
>> Earlier versions of the spec had a data format that was a lightweight encoding
>> of RFC 5733 (EPP) contact objects in JSON, which would have been an awful
>> lot easier for most domain registries and registrars to support. I think the
>> decision was ultimately not to reinvent the wheel, but instead of just using a
>> wheel, we got a Rube Goldberg contraption instead.
>>
>> jCard is an ugly mess, mainly because vCard is ugly, and cannot be concisely
>> encoded in JSON, and jCard has to maintain backwards compatibility.
>>
>> As far as I know there's almost nothing out there actually using jCard except
>> RDAP, and the implementations I've seen are quite immature.
>>
>> Maybe RDAP 2.0 will have its own native contact object representation :)
>>
>> G.
>>
>> On 11/02/2019 09:01, Richard Merdinger wrote:
>>> Rick and Sarah,
>>>
>>> Thanks for pushing the conversation forward.
>>>
>>>
>>>
>>> AS for #4 and the reliance on the existing RDAP constraints, I’m a
>>> little concerned that limitations of the existing RDAP RFC’s will
>>> limit the implementation that we put forward.  I’ve seen Scott talk
>>> about changes/extensions to the vCard implementation to help out, but
>>> I do wonder how we deal with policy recommendations that can’t be
>>> efficiently implemented in the current RFC’s.
>>>
>>>
>>>
>>> My position is that we must enhance the technical specifications to
>>> meet the policy, not restrict the policy to match the tech specs.
>>>
>>>
>>>
>>> --Rich
>>>
>>>
>>>
>>> Richard Merdinger
>>>
>>> VP, Domains
>>>
>>> [e-mail] <mailto:[e-mail]>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From: *<[e-mail]> on behalf of Sarah Wyld
>>> <[e-mail]>
>>> *Organization: *Tucows
>>> *Date: *Monday, February 11, 2019 at 6:59 AM
>>> *To: *<[e-mail]>
>>> *Subject: *Re: Review of RDAP Profile & Implementation Guide
>>>
>>>
>>>
>>> Thanks for the detailed review, Rick.
>>>
>>> This all seems reasonable/doable, I'll share with our team again and
>>> have any followup by tomorrow's call.
>>>
>>> --
>>>
>>> Sarah Wyld
>>>
>>> Domains Product Team
>>>
>>> Tucows
>>>
>>> +1.416 535 0123 Ext. 1392
>>>
>>>
>>>
>>>
>>>
>>> On 2/11/2019 7:54 AM, 'Wilhelm, Richard' via RDAP Pilot WG wrote:
>>>
>>>      Sarah, et al,
>>>
>>>
>>>
>>>      Thanks to the TuCows team for the review.   Having let this “soak”
>>>      on the list over the weekend, I thought it would be helpful to get
>>>      something out in case it got buried in others’ inboxes.
>>>
>>>
>>>
>>>      Happy to take input from others on these responses… with #3 and #4
>>>      likely to benefit most from further view
>>>
>>>
>>>
>>>      #1:  RP 2.7.5.3:  Good catch.  I inserted a Suggestion into RP
>>>      2.7.5.3 to include the words “substantially similar to”.
>>>
>>>
>>>
>>>      #2:  RP 2.7.6.1:  At present, the docs are targeted to implement the
>>>      Temp Spec.  If the EPDP changes this (or any other) policy that
>>>      needs to be reflected in the Profile docs, there would need to be an
>>>      iteration/revision at that time.  (Based on the direction of the
>>>      EPDP, it appears likely that there will be some sort of a revision
>>>      needed, but we will await finalization before undertaking that
>>>      activity.)
>>>
>>>
>>>
>>>      #3:  TIG 1.11.1:  Short answer:  No… the bootstrap file is for
>>>      registry RDAP servers, so accredited Registrars don’t appear there.
>>>      More detailed:  In reviewing the format of
>>>       https://urldefense.proofpoint.com/v2/url?u=https-3A__data.iana.org_rdap_dns.json&d=DwIFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=AG9XZF6h6bGkr7jkOsJt13dFth_3nZ0W8EKEBd3N1Q8&m=_EKyLM3BjG4r-UlZzBJjQ7cH1kPE5bUGiQwxcSoq3gg&s=v7bnaMwP7jL-0kokBLuVpL_qGURdGkyQwrrtxt9g-7w&e= there is one entry per TLD
>>>      which provides a TLD-to-URL mapping for authoritative services for
>>>      each TLD.  It is my understanding that only registry operator RDAP
>>>      services are listed here.  While the URL could be obtained
>>>      otherwise, a Registrar RDAP service URL is identified via a
>>>      reference received from a Registry RDAP service in response to a
>>>      query (e.g. a domain query).  That Registrar RDAP URL could be for
>>>      all TLDs for which a Registrar is accredited or it could be
>>>      TLD-specific.
>>>
>>>
>>>
>>>      Scott Hollenbeck and/or Marc Blanchet could likely express this in a
>>>      more articulate fashion.
>>>
>>>
>>>
>>>      #4:  TIG 3.4:  It is my understanding that the RDAP Profile is
>>>      (sorry for the odd phrasing here) constrained by the flexibility of
>>>      RFC 7095, which in 3.3.1.3, addresses the topic of address formatting.
>>>
>>>
>>>
>>>      Again, those with vCard/jCard experience, likely to add clarity here.
>>>
>>>
>>>
>>>      #5:  Conformance string:  As per RFC 7483 section 4.1, the
>>>      rdapConformance data structure is an array of strings.  It’s
>>>      structured to address situations where there are multiple
>>>      specifications used in construction of responses.  At present, the
>>>      two documents that comprised the RDAP Profile are separated with an
>>>      eye toward one that is heavily policy dependent (RP) and one that
>>>      aims to be policy neutral (TIG).  The goal is that as policy
>>>      changes, the TIG doc would be stable.  This is aimed to lead toward
>>>      more stable and structured implementations due to the “separation of
>>>      mechanism from policy” because when the policy changes, items
>>>      related to mechanism are not automatically opened up for review.
>>>      The use of the two rdapConformance members reflects this approach.
>>>
>>>
>>>
>>>      This is my summarization of the topic, but happy to have
>>>      comments/discussion.  And perhaps we can discuss on Tuesday.
>>>
>>>
>>>
>>>      Thanks
>>>
>>>
>>>
>>>      Rick
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>      *From: *<[e-mail]>
>>>      <mailto:[e-mail]> on behalf of Sarah Wyld
>>>      <[e-mail]> <mailto:[e-mail]>
>>>      *Organization: *Tucows
>>>      *Date: *Friday, February 8, 2019 at 4:40 PM
>>>      *To: *RDAP Pilot WG <[e-mail]>
>>>      <mailto:[e-mail]>
>>>      *Subject: *[EXTERNAL] Review of RDAP Profile & Implementation
>>> Guide
>>>
>>>
>>>
>>>      Hello Team,
>>>
>>>      To start your weekend off right, here are some notes from my RDAP
>>>      Development Lead's review of the Profile & Guide.
>>>
>>>
>>>
>>>      *_Response Profile_*
>>>
>>>      2.7.5.3 - The text says "the contact entity MUST include a remarks
>>>      element containing a title member with a value “REDACTED FOR
>>>      PRIVACY”". The Temp Spec section 2.2 says " Registrar and Registry
>>>      Operator MUST provide in the value section of the redacted field
>>>      text *substantially similar to the following*: "REDACTED FOR
>>>      PRIVACY"." (emphasis mine).
>>>
>>>      /Should the Profile be adjusted such that this requirement includes
>>>      the "substantially similar" text, to match the TempSpec? /
>>>
>>>
>>>
>>>      2.7.6.1 - The Profile says "The email property MUST be omitted", but
>>>      I believe there will be a Recommendation from the EPDP such that the
>>>      Registrant may opt-in to the publication of their email address.
>>>
>>>      /Should this be adjusted accordingly? /
>>>
>>>
>>>
>>>
>>>
>>>      *_Technical Implementation Guide_*
>>>
>>>      1.11.1 - The text says "The base URL of RDAP services MUST be
>>>      registered in the IANA's Bootstrap Service registry for Domain Name
>>>      Space (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_rdap-2Ddns_rdap-2Ddns.xhtml&d=DwIFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=AG9XZF6h6bGkr7jkOsJt13dFth_3nZ0W8EKEBd3N1Q8&m=_EKyLM3BjG4r-UlZzBJjQ7cH1kPE5bUGiQwxcSoq3gg&s=NG_anG0gIk5QeERnEgl5SF5wvtxkD_aROH8MEe_owOI&e=), as
>>>      described in RFC7484, through the IANA Root Zone Management system.
>>>      *A separate entry is required for each TLD."*
>>>
>>>      /Does this mean that we need a separate base URL for every TLD we
>>>      are accredited to offer as a registrar?/
>>>
>>>
>>>
>>>      3.4 -  I will not replicate the entire text here, but it talks about
>>>      structuring addresses as an array vs as a string. Here is feedback
>>>      from our team: "It is meaningfully more difficult to code if we have
>>>      to distinguish between single line addresses and multi-line
>>>      addresses. It is preferable, as a programmer, to always deal with
>>>      arrays, rather than have to figure out what type of item the street
>>>      is (string? or array of strings?). I would prefer that it always be
>>>      an array; or, that the “text” field be “array” instead, in cases
>>>      where it is an array".
>>>
>>>      /Is this something that can be adjusted in the requirements?/
>>>
>>>
>>>
>>>      *_Both together, just for fun_*
>>>
>>>      Response Profile 1.3 requires "icann_rdap_response_profile" in the
>>>      conformance member, while the Technical Implementation Guide
>>>      requires "icann_rdap_technical_implementation_guide". Do we indeed
>>>      require both?
>>>
>>>
>>>
>>>      Thanks,
>>>
>>>      --
>>>
>>>      Sarah Wyld
>>>
>>>      Domains Product Team
>>>
>>>      Tucows
>>>
>>>      +1.416 535 0123 Ext. 1392
>>>
>>>
>>>
>>>
>>>
>>>      --
>>>      You received this message because you are subscribed to the Google
>>>      Groups "RDAP Pilot WG" group.
>>>      To unsubscribe from this group and stop receiving emails from it,
>>>      send an email to [e-mail]
>>>      <mailto:[e-mail]>.
>>>      To post to this group, send email to [e-mail]
>>>      <mailto:[e-mail]>.
>>>      To view this discussion on the web visit
>>>      https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msgid_rdap-2Dpilot-2Dwg_97533706-2Dd60b-2D5409-2D&d=DwIFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=AG9XZF6h6bGkr7jkOsJt13dFth_3nZ0W8EKEBd3N1Q8&m=_EKyLM3BjG4r-UlZzBJjQ7cH1kPE5bUGiQwxcSoq3gg&s=re73H0NI6PaMOH-2gPIpQA_MXZGhPKi7YUAwCVa-LgM&e=
>> accf-139c02f64cae%40tucows.com
>>>      <https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msgid_rdap-2Dpilot-2Dwg_97533706-2Dd60b-2D&d=DwIFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=AG9XZF6h6bGkr7jkOsJt13dFth_3nZ0W8EKEBd3N1Q8&m=_EKyLM3BjG4r-UlZzBJjQ7cH1kPE5bUGiQwxcSoq3gg&s=YjBLzmEARn2UwV3FjSrL2Ll0IEpzL9MemgW9LtpwhL8&e=
>> 5409-accf-
>> 139c02f64cae%40tucows.com?utm_medium=email&utm_source=footer>.
>>>      For more options, visit https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=DwIFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=AG9XZF6h6bGkr7jkOsJt13dFth_3nZ0W8EKEBd3N1Q8&m=_EKyLM3BjG4r-UlZzBJjQ7cH1kPE5bUGiQwxcSoq3gg&s=wXlWWsKikjhvrSEF35UTvg3OZwiY2qRIk0QH1UUea14&e=.
>>>
>>>
>>>      --
>>>      You received this message because you are subscribed to the Google
>>>      Groups "RDAP Pilot WG" group.
>>>      To unsubscribe from this group and stop receiving emails from it,
>>>      send an email to [e-mail]
>>>      <mailto:[e-mail]>.
>>>      To post to this group, send email to [e-mail]
>>>      <mailto:[e-mail]>.
>>>      To view this discussion on the web visit
>>>      https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msgid_rdap-2Dpilot-2Dwg_B57A796C-2D180E-2D&d=DwIFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=AG9XZF6h6bGkr7jkOsJt13dFth_3nZ0W8EKEBd3N1Q8&m=_EKyLM3BjG4r-UlZzBJjQ7cH1kPE5bUGiQwxcSoq3gg&s=bWjumBmvM9iEsN0NvOVpqyP928bgdM5xOnwqfRwNMjw&e=
>> 473B-B3C2-DB84DC89A58A%40verisign.com
>>>      <https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msgid_rdap-2Dpilot-2Dwg_B57A796C-2D180E-2D&d=DwIFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=AG9XZF6h6bGkr7jkOsJt13dFth_3nZ0W8EKEBd3N1Q8&m=_EKyLM3BjG4r-UlZzBJjQ7cH1kPE5bUGiQwxcSoq3gg&s=bWjumBmvM9iEsN0NvOVpqyP928bgdM5xOnwqfRwNMjw&e=
>> 473B-B3C2-
>> DB84DC89A58A%40verisign.com?utm_medium=email&utm_source=footer>
>> .
>>>      For more options, visit https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=DwIFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=AG9XZF6h6bGkr7jkOsJt13dFth_3nZ0W8EKEBd3N1Q8&m=_EKyLM3BjG4r-UlZzBJjQ7cH1kPE5bUGiQwxcSoq3gg&s=wXlWWsKikjhvrSEF35UTvg3OZwiY2qRIk0QH1UUea14&e=.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "RDAP Pilot WG" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [e-mail]
>>> <mailto:[e-mail]>.
>>> To post to this group, send email to [e-mail]
>>> <mailto:[e-mail]>.
>>> To view this discussion on the web visit
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msgid_rdap-2Dpilot-2Dwg_5c8d6676-2D7241-2D0629-2D&d=DwIFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=AG9XZF6h6bGkr7jkOsJt13dFth_3nZ0W8EKEBd3N1Q8&m=_EKyLM3BjG4r-UlZzBJjQ7cH1kPE5bUGiQwxcSoq3gg&s=HhMLzX6LVU_ceJp6ppJZbdsvA0tv0RTMOoTyy9MS0Fo&e=
>> 84b
>>> c-2b003edae816%40tucows.com
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msgid_rdap-2Dpilot-2Dwg_5c8d6676-2D7241-2D0629-2D&d=DwIFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=AG9XZF6h6bGkr7jkOsJt13dFth_3nZ0W8EKEBd3N1Q8&m=_EKyLM3BjG4r-UlZzBJjQ7cH1kPE5bUGiQwxcSoq3gg&s=HhMLzX6LVU_ceJp6ppJZbdsvA0tv0RTMOoTyy9MS0Fo&e=
>> 84bc-
>> 2b003edae816%40tucows.com?utm_medium=email&utm_source=footer>.
>>> For more options, visit https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=DwIFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=AG9XZF6h6bGkr7jkOsJt13dFth_3nZ0W8EKEBd3N1Q8&m=_EKyLM3BjG4r-UlZzBJjQ7cH1kPE5bUGiQwxcSoq3gg&s=wXlWWsKikjhvrSEF35UTvg3OZwiY2qRIk0QH1UUea14&e=.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "RDAP Pilot WG" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [e-mail]
>>> <mailto:[e-mail]>.
>>> To post to this group, send email to [e-mail]
>>> <mailto:[e-mail]>.
>>> To view this discussion on the web visit
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msgid_rdap-2Dpilot-2Dwg_3F48A445-2D1998-2D4B73-2D&d=DwIFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=AG9XZF6h6bGkr7jkOsJt13dFth_3nZ0W8EKEBd3N1Q8&m=_EKyLM3BjG4r-UlZzBJjQ7cH1kPE5bUGiQwxcSoq3gg&s=Qi15aEY1GmgKWza3VOd2rMS7PVYgAyAwqj39vSXQvhk&e=
>> AA6
>>> E-021164297CA7%40godaddy.com
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msgid_rdap-2Dpilot-2Dwg_3F48A445-2D1998-2D4B73-2D&d=DwIFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=AG9XZF6h6bGkr7jkOsJt13dFth_3nZ0W8EKEBd3N1Q8&m=_EKyLM3BjG4r-UlZzBJjQ7cH1kPE5bUGiQwxcSoq3gg&s=Qi15aEY1GmgKWza3VOd2rMS7PVYgAyAwqj39vSXQvhk&e=
>> AA6E-
>> 021164297CA7%40godaddy.com?utm_medium=email&utm_source=footer>.
>>> For more options, visit https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=DwIFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=AG9XZF6h6bGkr7jkOsJt13dFth_3nZ0W8EKEBd3N1Q8&m=_EKyLM3BjG4r-UlZzBJjQ7cH1kPE5bUGiQwxcSoq3gg&s=wXlWWsKikjhvrSEF35UTvg3OZwiY2qRIk0QH1UUea14&e=.
>> --
>> Gavin Brown
>> Chief Technology Officer
>> CentralNic Group plc (LSE:CNIC)
>> Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private
>> domain name registries https://urldefense.proofpoint.com/v2/url?u=https-3A__www.centralnic.com_&d=DwIFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=AG9XZF6h6bGkr7jkOsJt13dFth_3nZ0W8EKEBd3N1Q8&m=_EKyLM3BjG4r-UlZzBJjQ7cH1kPE5bUGiQwxcSoq3gg&s=jVgo3AacqcMi5azubvBMrqsvluNCj32ShZCH1MLg7n8&e=
>> +44.7548243029
>>
>> CentralNic Group plc is a company registered in England and Wales with
>> company number 8576358. Registered Offices: 35-39 Moorgate, London,
>> EC2R 6AR.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "RDAP Pilot WG" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [e-mail].
>> To post to this group, send email to [e-mail].
>> To view this discussion on the web visit
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msgid_rdap-2Dpilot-2Dwg_dc689f69-2D89f8-2D10bb-2D&d=DwIFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=AG9XZF6h6bGkr7jkOsJt13dFth_3nZ0W8EKEBd3N1Q8&m=_EKyLM3BjG4r-UlZzBJjQ7cH1kPE5bUGiQwxcSoq3gg&s=Y7_a4ijb9dRLkmUYHZG_hQ1hQoOrRrvF7N3EAln-bg4&e=
>> 8cd4-54eef5b519bb%40centralnic.com.
>> For more options, visit https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=DwIFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=AG9XZF6h6bGkr7jkOsJt13dFth_3nZ0W8EKEBd3N1Q8&m=_EKyLM3BjG4r-UlZzBJjQ7cH1kPE5bUGiQwxcSoq3gg&s=wXlWWsKikjhvrSEF35UTvg3OZwiY2qRIk0QH1UUea14&e=.