On 6/5/18 8:39 AM, Hollenbeck, Scott wrote:
-----Original Message-----
From: Adam Roach <[email protected]>
Sent: Monday, June 04, 2018 7:32 PM
To: [email protected]; [email protected]
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.
/a
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
