Subject: [apps-discuss] WEIRDS WG report

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Mar 2014 21:41:44 +0000

WEIRDS met today and discussed what we believe are its remaining issues.

The group discussed the outcome of a design team meeting that tried to
address two issues at once: the issue an imposed URI structure
(draft-nottingham-uri-get-off-my-lawn) and the methodology by which to find
an authoritative registry that can further delegate.  Both issues are being
addressed by allowing a key-value table that supports longest-match lookups
resulting in  URI templates that are then used to construct a query that
will either return an answer or a redirection.  The WG will continue this
discussion on its mailing list and select a path forward.  Participants
were asked to open tracker items for any remaining issues on the open
documents (query, redirection, bootstrapping) so they can be driven to
resolution.

The discussion of the publication of the table (IANA being the logical
point) ventured into the complications that come with the IETF creating
domain registries and imposing policies potentially outside of its
purview.  This issue has not been completely resolved but we believe there
are ways forward through careful crafting of the language and keeping the
IANA section to an absolute minimum.

Finally, a report was given of interoperability tests performed prior to
the IETF meeting.  No specification issues were discovered and a fair
number of server as well as client implementations interoperate.  A couple
of issues were identified and we are at or close to consensus on resolution.

The chairs believe that the work of the group may conclude between now and
Toronto, so this may have been our final meeting.

-MSK and Olaf, co-chairs, WEIRDS

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 05 Mar 2014 14:22:52 +0900

> documents (query, redirection, bootstrapping) so they can be driven to

Regarding this point, Mark sent a mail to the W3C TAG (Technical 
Architecture Group) a while ago, at 
http://lists.w3.org/Archives/Public/www-tag/2014Feb/0068.html, and I 
replied at
http://lists.w3.org/Archives/Public/www-tag/2014Feb/0079.html, switching 
to defend the (former?) WEIRDS position. There was only one reply, 
agreeing with me
(http://lists.w3.org/Archives/Public/www-tag/2014Feb/0080.html) but 
probably better worded.

Looking at the above "key-value table that supports longest-match 
lookups resulting in URI templates that are then used to construct a 
query that will either return an answer or a redirection", this to me 
smells like over-engineering even just when reading it (not to speak of 
having to implement it).

Of course, if the WEIRDS WG is happy with that, I won't complain any 
further, but I just wanted to mention this because I earlier supported 
Mark and Tim on this list (and would still continue to do that if there 
were no indirection at all in WEIRDS, i.e. if e.g. WEIRDS was requiring 
top-level directories with fixed names).

Regards,   Martin.

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: "John Levine" <[email-masked]>
Date: 5 Mar 2014 15:07:13 -0000

>Of course, if the WEIRDS WG is happy with that, ...

Not particularly, but our preferred solution, a fixed URL suffix
syntax that we append to a per-thing (domain, IP range, etc.) prefix
is apparently forbidden to us.

The redirects have been there all along to provide a less broken
version of what thin WHOIS does now.

R's,
John

---

From: Andrew Newton <[email-masked]>
Date: Thu, 6 Mar 2014 07:58:44 +0000

My major objection to URI templates was the extra retrieval of the
template, but that is solved with their inclusion in the bootstrap.

However, looking at a real world extension to one of the existing RDAP
queries I am beginning to wonder if URI templates are more of a
liability. Currently /domain/example.com returns the relevant domain
registration, info about DNSSEC, nameservers, contacts, etc... For
/domain/136.192.in-addr.arpa there may sometimes be a need to add in
related network registration information (actually, RIPE and ARIN do
this today with their custom REST interfaces). To signal this a client
could optionally add the query parameter ?needNets=true.

If the first URI template is http://service/domain/{domain} and the
RIRs modify their templates to
http://service/domain/{domain}?needNets={needNets}, clients unaware of
the extension will not know to substitute anything for "needNets".
Simple substitution, as proposed at the meeting, does not work here.

Should we move beyond the simple URI templates form, I believe John is
absolutely right about the complexity. It will be too much.

-andy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 6 Mar 2014 08:53:22 +0000

> Simple substitution, as proposed at the meeting, does not work here.
If constrained to prefix URIs only and thus limited to search-and-replace,
how would a client tell an RIR that it wants to set the needNets flag?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 6 Mar 2014 09:07:40 +0000

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 6 Mar 2014 10:36:12 +0000

What about a client that doesn't know what CONTEXT to use?

If the answer to that is that a client always has to fill in two variables
instead of one, then you're basically doing templates.

On Thu, Mar 6, 2014 at 10:31 AM, James Mitchell <
[email-masked]> wrote:

> What if the registry contains a base URL for the composition of RDAP paths?
>
> e.g.
> {
>         ³com² : ³rdap.verisign.com²,
>         ³au² : ³rdap.ausregistry.net.au/CONTEXT/ROOT²
> }
>
> A client would append ³/domain/<<domain-name>>², e.g.
> rdap.verisign.com/domain/example.com and
> rdap.ausregistry.net.au/CONTEXT/ROOT/domain/example.com.au. Allows servers
> to place a registry-selector in the path name while keeping the whole
> thing pretty simple.
>
> Thanks,
> James
>
> On 6/03/2014 9:24 am, "Hollenbeck, Scott" <[email-masked]>
> wrote:
>
> >> -----Original Message-----
> >> From: weirds [mailto:[email-masked]] On Behalf Of Andrew
> >> Newton
> >> Sent: Thursday, March 06, 2014 2:59 AM
> >> To: John Levine; [email-masked]
> >> Cc: [email-masked]
> >> Subject: Re: [weirds] [apps-discuss] WEIRDS WG report
> >
> >[SAH]
> >
> >Are you suggesting a move back to what we had in the document prior to
> >the change to .well-known, and no template(s)?
> >
> >Scott
> >
> >weirds mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/weirds
>
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds
>

---

From: "John R Levine" <[email-masked]>
Date: 6 Mar 2014 10:51:52 +0000

> how would a client tell an RIR that it wants to set the needNets flag?

If it were me, I'd have an IANA registry of fixed prefixes for queries, 
so whatever it was, it'd be in the registry.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: "John R Levine" <[email-masked]>
Date: 6 Mar 2014 10:56:56 +0000

> to place a registry-selector in the path name while keeping the whole

That was more or less the original plan.  That came up in the design team 
meeting and I think that Mark said that they'd tell us that was not good 
practice but they'd probably let us do it.

Given the range of questions that people might ask, if we go the template 
route I don't see much alternative to an explosion of NxM templates (N 
query types and M domains, IPs, etc.)  I suppose we could try three 
metatemplates and a registry, but ugh.

R's,
John

---

From: Tony Hansen <[email-masked]>
Date: Thu, 06 Mar 2014 05:56:58 -0500

> Simple substitution, as proposed at the meeting, does not work here.

I disagree. The rule for such options should be that

*) any parameters that are unknown SHOULD be removed, as in "?needNets=" 
from the previous example
*) the server MUST handle extension parameters that are empty
*) the server MUST treat extension parameters with an unexpanded value 
such as "{needNets}" as if it were empty

In other words, if the server receives "?needNets={needNets}" OR 
"?needNets=" it needs to do the right thing.

And the "simple" sed script mentioned in the room that does expansion 
just needs an additional -e 's/{[^}]*}//g'.

     Tony Hansen

---

From: Graham Klyne <[email-masked]>
Date: Thu, 06 Mar 2014 14:50:34 +0000

I chimed in earlier on this discussion, and listened in on the WG meeting 
discussions this week.

TL;DR: I'm thinking that the use of URI templates in the registry (bootstrap) is 
the worst kind of compromise, and I think this might be a case where the current 
non-templated solution is appropriate (but should be explained why it is).

...

In my view, there are two distinct but related reasons to favour using templates:

1. the "get-off-my-lawn" argument, in that it allows services total control over 
the allocation and use of their URI space, and reduces the constraints on how 
the service may be deployed.

2. Long term flexibility, ala REST style (cf. Roy Fielding's
"software design on a scale of decades" - 
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724). 
  I mention this because there was an explicit mention in the WG meeting of a 
desire for flexibility/extensibility.   I see using service-provided URI 
templates is *a* way to achieve this:  coupling between the server and client is 
dramatically reduced, and as long as clients follow the appropriate procedures, 
the service can change and rearrange its URI space (effectively, its API) to 
meet evolving needs.

    But this comes at a cost.  As Roy notes "Many of the [REST] constraints are 
directly opposed to short-term efficiency" (ibid.).  The cost here is the extra 
round trip.  I see that as the cost of long term flexibility, but I can't judge 
if that cost is too high (taking into account appropriate use of web cacheing, etc.)

    The other cost is client complexity.  In my experience, the development 
overhead (complexity) of using URI Templates is non-zero, but is not great, 
given the range of libraries available.  YMMV.

The current WEIRDS document says:

    "The goal of this document is to tie
    together usage patterns of HTTP into a common profile applicable to the
    various types of Directory Services serving Registration Data using
    RESTful practices."

If you are serious about following RESTful practices, then I think the cost of 
the extra round trip must be accepted.  Otherwise, I'd urge deleting the 
qualification "using RESTful practices" (again, see the blog post and comments 
cited above).

...

Thus, the main problem I see is the extra round trip that may be needed to fully 
realize the benefit of using templates.  I can't judge if this is acceptable, 
but I note that the protocol design already anticipates additional round trips 
in the form of HTTP redirects.

The problem I see with putting URI templates in the bootstrap (which some 
comments in the meeting noted could lead to their being hard-coded in client 
applications) is that we are not significantly better off than the current 
prefix-based solution, but with the added complexity of having to deal with (or 
circumvent) the use of URI templates.  It also introduces the spectre of NxM 
entries in the bootstrap registry as John has noted.  Further, how would it work 
with redirects to a different server that might use a different URI sub-structure?

If the primary concern is the "get-off-my-lawn" argument, then I think the 
prefix solution is probably good enough, but if adopted I think it would be 
appropriate to include some commentary addressing the concerns of 
http://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn (specifically 
sections 1 and 2.3).  A wider concern is that publication of this as a standard 
might be seen as a precedent to doing it in situations where the detrimental 
impact of constraints on URI patterns would be more severe.

I think such commentary might include mention of the fact that the service is 
not for general deployment, but is expected to be fielded by specific 
organizations for quite specific purposes, and that the bootstrap prefix 
mechanism means that clients can be told to use a different part of the 
service's URI space if operational circumstances change.  Thus, the need to 
retain compatibility with properly implemented clients does not completely block 
changes to the service provision environment.

...

HTH

#g
--

---

From: Andrew Newton <[email-masked]>
Date: Thu, 6 Mar 2014 14:57:57 +0000

Thanks Tony, I think that answers my question.

-andy

On Thu, Mar 6, 2014 at 10:56 AM, Tony Hansen <[email-masked]> wrote:
> *) the server MUST treat extension parameters with an unexpanded value such
> as "{needNets}" as if it were empty
>
> And the "simple" sed script mentioned in the room that does expansion just
> needs an additional -e 's/{[^}]*}//g'.
>
>     Tony Hansen
>
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 6 Mar 2014 15:36:04 +0000

On Thu, Mar 6, 2014 at 2:50 PM, Graham Klyne <[email-masked]> wrote:

> Thus, the main problem I see is the extra round trip that may be needed to
> fully realize the benefit of using templates.  I can't judge if this is
> acceptable, but I note that the protocol design already anticipates
> additional round trips in the form of HTTP redirects.
>

One of the original concerns we had with using URI templates was the two
round trips: one to get the template, one to execute the template.  If the
template is stored in the bootstrap table, one of those round trips is
replaced by a local filesystem operation, and we're left with just the
query, which we have to make under any model.

> comments in the meeting noted could lead to their being hard-coded in
> client applications) is that we are not significantly better off than the
> current prefix-based solution, but with the added complexity of having to
> deal with (or circumvent) the use of URI templates.  It also introduces the
> spectre of NxM entries in the bootstrap registry as John has noted.
>  Further, how would it work with redirects to a different server that might
> use a different URI sub-structure?
>

I don't believe either of those are particularly ugly impositions, unless
one considers anything with non-zero cost to be ugly.  If the registry has
NxM entries and is expressed in (say) JSON, the JSON parser will still make
extraction of the desired values easy.  Nobody has argued (yet) that doing
the bootstrap table in JSON is a problem, so I'm assuming for the sake of
argument that that's given.

If we use templates instead of prefixes, then there needs to be a function
of some kind to make the substitutions, and it's a question of whether
that's something like "sed" or something that implements full template
expansion.  Having tried both under the REPUTE work, my experience suggests
that they are actually of almost equal complexity.

Also, the following two things are, to me, logically equivalent:

1) Take URI prefix "X", append "/domain/", then append the domain name
you're interested in.  Query the result.

2) Take URI template "X/domain/{domain}", and replace "{domain}" with the
domain name you're interested in.  Query the result.

If you buy that argument, then we're really arguing about whether a string
append operation is substantially more complex than a substring replace
operation.  There are ample implementations of both, so I don't believe
that's an issue.  Since people like to use the shell script as the
baseline, this amounts to a call to "sed" (available, and free), or a call
to a different tool (available, and free) that can expand templates.

Also in either approach, we need to enumerate all the supported
substitutions for a given query type and what values should be used in
those substitutions.  There's no added documentation burden there.

> http://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn(specifically sections 1 and 2.3).  A wider concern is that publication of
> this as a standard might be seen as a precedent to doing it in situations
> where the detrimental impact of constraints on URI patterns would be more
> severe.
>
> I think such commentary might include mention of the fact that the service
> is not for general deployment, but is expected to be fielded by specific
> retain compatibility with properly implemented clients does not completely
> block changes to the service provision environment.
>

Yes, this was the sentiment at the end of the design team meeting; using
prefixes in the registry instead of templates would probably skate by the
get-off-my-lawn-draft, and the burden would be on us to explain why that's
so.

-MSK

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 6 Mar 2014 09:24:41 +0000

[SAH]

> absolutely right about the complexity. It will be too much.

Are you suggesting a move back to what we had in the document prior to the change to .well-known, and no template(s)?

Scott

---

From: James Mitchell <[email-masked]>
Date: Thu, 6 Mar 2014 10:31:00 +0000

e.g.
{

Thanks,
James

---

From: James Mitchell <[email-masked]>
Date: Thu, 6 Mar 2014 10:58:22 +0000

The /CONTEXT/ROOT is to be provided by whomever is requesting the entry into the registry thus hard-coded into the registry. To use the registry clients only need the ability to append the WERIDS specification defined path (and query strings when relevant) to the relevant value.

Perhaps the use of /CONTEXT/ROOT was misleading?

From: "Murray S. Kucherawy" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 6 March 2014 10:36 am
To: James Mitchell <[email-masked]<mailto:[email-masked]>>
Cc: "Hollenbeck, Scott" <[email-masked]<mailto:[email-masked]>>, Andrew Newton <[email-masked]<mailto:[email-masked]>>, John Levine <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [weirds] [apps-discuss] WEIRDS WG report

If the answer to that is that a client always has to fill in two variables instead of one, then you're basically doing templates.

On Thu, Mar 6, 2014 at 10:31 AM, James Mitchell <[email-masked]<mailto:[email-masked]>> wrote:
What if the registry contains a base URL for the composition of RDAP paths?

e.g.
{
        ³com² : ³rdap.verisign.com<http://rdap.verisign.com>²,
        ³au² : ³rdap.ausregistry.net.au/CONTEXT/ROOT<http://rdap.ausregistry.net.au/CONTEXT/ROOT>²
}

A client would append ³/domain/<<domain-name>>², e.g.
rdap.verisign.com/domain/example.com<http://rdap.verisign.com/domain/example.com> and
rdap.ausregistry.net.au/CONTEXT/ROOT/domain/example.com.au<http://rdap.ausregistry.net.au/CONTEXT/ROOT/domain/example.com.au>. Allows servers
to place a registry-selector in the path name while keeping the whole
thing pretty simple.

Thanks,
James

On 6/03/2014 9:24 am, "Hollenbeck, Scott" <[email-masked]<mailto:[email-masked]>> wrote:

>> From: weirds [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andrew
>> Newton
>> To: John Levine; [email-masked]<mailto:[email-masked]>
>> Cc: [email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>

_______________________________________________
weirds mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/weirds