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

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

> -----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.

> 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".

> --------------------------------------------------------------------------
> -
>
> 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"."

Scott