Re: [regext] AD Review: draft-ietf-regext-rdap-object-tag

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: Adam Roach <[e-mail]>
> Sent: Tuesday, June 05, 2018 6:37 PM
> To: Hollenbeck, Scott <shollenbeck=[e-mail]>;
> '[e-mail]' <[e-mail]>; 'draft-ietf-regext-rdap-object-
> [e-mail]' <[e-mail]>
> Subject: [EXTERNAL] Re: [regext] AD Review: draft-ietf-regext-rdap-object-
> tag
>
> On 6/5/18 8:39 AM, Hollenbeck, Scott wrote:
> >> -----Original Message-----
> >> From: Adam Roach <[e-mail]>
> >> Sent: Monday, June 04, 2018 7:32 PM
> >> To: [e-mail]; [e-mail]
> >> Subject: [EXTERNAL] AD Review: draft-ietf-regext-rdap-object-tag
> >>
> >> I've reviewed the document draft-ietf-regext-rdap-object-tag in
> >> preparation for placing it into IETF last call. The mechanism and
> >> document generally look good and useful; however, I have some
> >> concerns about its URL synthesis.
> >>
> >> The mechanical synthesis of URLs as described in this document
> >> contravenes the requirements of BCP 190, section 2.3. Ordinarily, I
> >> would consider this a showstopper and ask the working group to adjust
> >> handling to match BCP 190 requirements (e.g., using RFC 6570 URI
> >> Templates). Because this specification simply builds upon RFC 7484
> >> techniques for performing URI synthesis, however, forcing such a
> >> change would result in an incongruity that I understand might cause
> deployment issues.
> > Thanks for the review, Adam. I'm a little confused, though. RFC 7484
> doesn't talk about URI synthesis - it describes registries and
> registration practices for data that can be used by RDAP clients to find
> servers. RFC 7482 describes how the URLs for RDAP queries are structured.
> My document includes the URLs and path segments from 7482 only as
> examples.
>
> Apologies -- I meant RFC 7482 rather than 7484.
>
> >
> >> Nonetheless, I request that the working group consider whether the
> >> use of something like RFC 6570 would be appropriate for the mechanism
> >> described this document. Please also understand that other area
> >> directors may note and object to this type of URL synthesis during IESG
> processing. Chairs:
> >> please let me know when you believe working group consideration of
> >> this issue is complete.
> > Maybe I'm missing something, but since this document isn't focused on
> URI synthesis I don't see how 6570 is applicable *unless* we're revisiting
> 7482. What this document describes is a practice for RDAP entity
> identifier construction so that clients can use information contained in
> that structure to bootstrap entity queries. That is, "when you create
> entity identifiers you should stick this thing on the end to make it
> easier for clients to find the associated server".
>
> Okay, that makes sense. I had read this document as specifying the
> concatenation, but your explanation that it is simply specifying
> identifiers for use with 7482 makes sense.
>
> >
> >> -----------------------------------------------------------------------
> ---
> >> -
> >>
> >> I also have one question about an example in section 2:
> >>
> >>   >  For example, if the base RDAP URL
> >>   >  "https://example.com/rdap/" is associated with service provider
> >>>   "YYYY" in an IANA registry, an RDAP client will parse a tagged
> entity
> >>>   identifier "XXXX-YYYY" into distinct handle ("XXXX") and service
> >>>   provider ("YYYY") identifiers.  The service provider identifier
> >>>   "YYYY" is used to query an IANA registry to retrieve the base RDAP
> >>>   URL "https://example.com/rdap/".  The base RDAP URL is concatenated
> >>>   to the entity handle to create a complete RDAP query path segment of
> >>>   "https://example.com/rdap/entity/XXXX-YYYY".
> >> I read the text as calling for implementors to concatenate "XXXX-YYYY"
> >> to the
> >> end of the IANA-registered base URL ("https://example.com/rdap/"),
> >> resulting in "https://example.com/rdap/XXXX-YYYY". The example instead
> >> shows "https://example.com/rdap/entity/XXXX-YYY". Is the inclusion of
> >> "entity/" in this example an error?
> > No, it's not an error. That’s the path segment that 7482 describes for
> entity queries. I can see how my text above might be confusing, though, so
> how about this wording instead?
> >
> > OLD:
> > "The base RDAP URL is concatenated to the entity handle to create a
> complete RDAP query path segment of "https://example.com/rdap/entity/XXXX-
> YYYY""
> >
> > NEW:
> > "The RDAP query URL is formed using the base RDAP URL and entity path
> segment described in Section 3.1.5 of RFC 7482, using "XXXX-YYY" as the
> value of the handle identifier. The complete RDAP query URL becomes
> "https://example.com/rdap/entity/XXXX-YYYY"."
>
> That seems good.
>
> Thanks for the explanations. Based on what you've said, I think this is
> ready for IETF last call -- you can treat my comment for clarification
> of the example as an IETF last call comment, and address it along with
> any other feedback you receive during last call.

Will do - thanks!

Scott