Subject: [apps-discuss] RFC 5785: registering well-known URIs

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 16 Aug 2013 21:16:59 -0600

RFC 5785 provides a way to register well-known URIs. It seems to me that
there are gaps in the spec regarding the registration procedures. As an
example, consider the recently-approved specification for Enrollment
over Secure Transport:

https://datatracker.ietf.org/doc/draft-ietf-pkix-est/

That specification registers a URI suffix of "est" but in fact defines
and uses a number of well-known URIs, such as:

/.well-known/est/cacerts
/.well-known/est/simpleenroll
/.well-known/est/csrattrs
/.well-known/est/serverkeygen

How is IANA supposed to know whether it needs to also register all of
those well-known URIs? Is IANA supposed to disallow future registration
requests that begin with "est"? (For example, is it expected that IANA
will deny a request to register "/.well-known/estimation" since "est" is
a registered suffix?)

RFC 5785 tries to cover these issues by saying the following:

   Typically, a registration will reference a specification that defines
   the format and associated media type to be obtained by dereferencing
   the well-known URI.

   It MAY also contain additional information, such as the syntax of
   additional path components, query strings and/or fragment identifiers
   to be appended to the well-known URI, or protocol-specific details
   (e.g., HTTP [RFC2616] method handling).

However, at least in the case of the EST spec the registration request
doesn't contain enough information for the IANA to really know what to do:

   IANA is to update the well-known URI registry with the following
   filled-in template from [RFC5785].

      URI suffix: est

      Change controller: IETF

I'm of the opinion that RFC 5785 is missing some details here, however
if I'm the only one who finds it lacking then I won't pursue the issue
further and will leave it up to the designated expert for the well-known
URI registry to handle things on a case-by-case basis.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: SM <[email-masked]>
Date: Fri, 16 Aug 2013 21:38:18 -0700

Hi Peter,
>will deny a request to register "/.well-known/estimation" since "est" is

RFC 5785 says that:

   "Well-known URIs are registered on the advice of one or more
    Designated Experts (appointed by the IESG or their delegate)"

To answer the above question, IANA asks the Designated Expert.  What 
I need to know is why I am seeing a "/.well-known/est/cacerts" 
request in my web server logs.  If the information is available 
through the relevant registry it is not a problem.

>    (e.g., HTTP [RFC2616] method handling).

My reading of the above is that the information can listed there.  I 
would say that it is unclear to the person asking for registration as 
the submission template only mentions citations in that field.

Regards,
-sm

---

From: Graham Klyne <[email-masked]>
Date: Mon, 19 Aug 2013 08:10:07 +0100

On 17/08/2013 05:38, SM wrote:
> To answer the above question, IANA asks the Designated Expert.  What I need to
> know is why I am seeing a "/.well-known/est/cacerts" request in my web server
> logs.  If the information is available through the relevant registry it is not a
> problem.

Without taking a view on the broader question, I don't think this really answers 
the issue raised.  As designated reviewer for two other registries, I regard my 
role is not to make technical judgements so much as to provide a cross-check 
that the intent of the registration rules is being followed.  As such, I rely 
quite heavily on the registration procedure documents to help me separate my own 
technical preferences from the requirements set out in the registration 
procedures.  Where there is lack of clarity in the registration procedure, that 
makes my job harder.

And a thought: updating a registration RFC is relatively hard work.  Something 
that might be useful is an IETF wiki somewhere which can be used to collect 
registration guidance notes, based on conversations between the designated 
expert, IANA and other interested parties.  We've discussed something vaguely 
along these lines previously, but that effort sort of fizzled out.  So what I 
suggest here is to use a wiki in a very lightweight way to act as a kind of 
"group memory" for issues like this as they are raised and resolved, so we have 
a better chance of maintaining consistency over time and changes of peropkle 
involved.

#g
--

> My reading of the above is that the information can listed there.  I would say
> that it is unclear to the person asking for registration as the submission
> template only mentions citations in that field.
>
> Regards,
> -sm
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Barry Leiba <[email-masked]>
Date: Mon, 19 Aug 2013 16:09:12 +0200

> will deny a request to register "/.well-known/estimation" since "est" is

There are two issues here: how to handle the "est" situation, and how
to deal with the situation in general.

My view of the first is that this should be clearly specified in the
document that does the registration; it should clearly say that it is
registering "est" and reserves the entire hierarchy below that, if
that's what it means to do.

For the second, we do have an open question.  The intent of RFC 5785
is to provide, with .well-known, an entry point for a particular
purpose.  Using that thinking, the "est" document should register four
well-known URIs, not just one.  And if someone should want to use
"/est/banana" later, that should have to be separately registered.
It's certainly easy to argue that this is a better approach.  If we
allow it to be open-ended, then the "est" document theoretically
reserves "/est/banana" and "/est/apple", but doesn't define their uses
or meanings.

There's also the issue of how to handle existing registrations.  Are
we now saying that "/caldav/office", "/core/sensors", and
"/webfinger/author" are reserved?  If so, what do they mean?  Do they
make sense without a specification?  If they don't, then why not just
have them reserved by a new specification when they're needed?

On the other hand, if a specification such as "est" expects extensions
and wants to reserve the namespace -- "/est/banana" isn't defined, but
can only be reserved by an "est" extension -- perhaps it should be
reasonable for it to be able to do that.

I think if we want that feature, we can decide that it's how this case
will work, and then submit a document that updates 5785 to generalize
it.

Barry

---

From: Tim Bray <[email-masked]>
Date: Mon, 19 Aug 2013 07:21:16 -0700

Hm, I could imagine a situation in which I register /.well-known/foo and
all URIs that begin that way, but if I did that I think I’d have to provide
rules on how they’re constructed and use. So, failing that... what Barry
said
 -T