Subject: [apps-discuss] .well-known as a one stop shopping location for Web Services identifiers

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 13 Feb 2013 11:28:28 -0500

I would like to set up a 'one stop shopping service' for protocol
identifiers. The idea being that registration of application layer
protocols is an application layer concern alone. It should not be necessary
to have multiple levels of review to register a single protocol. That is
wasteful of time for both the applicant and the reviewers.

In particular, we would like to encourage applications to have a consistent
approach to discovery and to use of URIs. This is best achieved if using
facilities like application specific URIs to identify end points and SRV
prefixes are the easiest path rather than the hardest.

Looking through the existing infrastructure, I believe this can be achieved
as follows:

*1) Reuse the existing .well-known registry to assign the unique token.*

This registry is specification required which might be a bug. But could be
changed if necessary. While many consider the .well-known approach to
specify the URI path as something of a 'hack' (as I do actually), having a
default path is actually quite useful even if we eventually end up with a
discovery protocol that makes the .well-known prefix redundant.

The main use for a non default port configuration is to facilitate
deployment and debugging. HTTP has supported ports other than 80 from the
start. But the fact that port 80 traffic is almost certainly some sort of
Web traffic is still useful to know.

Example: Registered service identifier is 'foo'
Default service path is /.well-known/foo/

*2) Register the _wk or _well-known SRV prefix as a service*

RFC 6335 does not really describe the definition of service schemes that
are not in _tcp or _udp but the original need for the identifiers came from
the fact that SRV was re-using the existing well known port list and some
services allowed either transport.

If we are going to re-use the .well-known registry in the same way, the
logical approach would be to do the same thing and reserve a label for the
purpose.

Example: Foo service prefix is _foo._wk, service at example.com is
advertised thus:

_foo._wk.example.com SRV 1 1 80 foo1.example.com

*3) Register the wk: URI scheme*

When the entities being referenced are entities that are constructed by a
protocol, the most natural means of identifying them is a protocol specific
URI.

Exchanging http:// format URIs to identify protocol specific information is
pulls us down to the wrong level of abstraction. A http URI is not very
useful in protocol negotiation as we don't know what the type of service it
is unless we try to

Example: Reserved URI space is wk:foo:

The uri for the service endpoint at example.com would be wk:foo:example.com

So now imagine that we had a service offering geographic information that
specified the following as service endpoints:

wk:foo:example.com
wk:bar:example.com
wk:fooplus:example.com

I think it is pretty clear that trying to deal with this type of endpoint
in a mashup would be rather easier than the traditional http variety.

Note that since the registration for .well known is already a URI
registration (of sorts) this automatic registration should not entail
different considerations.

Note also that the default mapping of the wk:foo:example.com/xxx URI would
be to http://example.com/.well-known/foo/xxx but we might define a
discovery mechanism that would change this default in the future.

*4: Register the wk= Content Type parameter*

One of the perennial arguments in Web Services is how to label the content
in MIME. I don't think there is a good answer.

We already have application/json and application/xml. And it is entirely
possible that people will continue to write protocols that are coding
agnostic between JSON and XML. My Protogen compiler supports either
encoding without any extra effort beyond setting a flag.

So it seems like any information to indicate which protocol the messages
are encoding has to be relegated to a parameter.

Example:

XML protocol messages:  application/xml; wk=foo
JSON protocol messages:  application/json; wk=foo

Next steps:

1) Request reservation of the code points specified above
2) RFC to describe implications for .well-known registrations
3) RFC with informative 'how to guide' describing acceptable precedents

The idea in 3 is not to be unnecessarily restrictive. Applying a design
template from the guide should be a sufficient but not a necessary
criteria.

A requirement for expert review of an application protocol specification is
in a sense a failure. If the Internet protocols are not sufficiently robust
that they can be used without risk to the Internet then we should be fixing
the lower Internet protocol layers. If there are subtleties that are not
immediately apparent, well that's a documentation failure. If the developer
is a clod who doesn't care about getting it right they are going to ignore
the expert review anyway.

-- 
Website: http://hallambaker.com/

---

From: Dave Cridland <[email-masked]>
Date: Sat, 16 Feb 2013 08:35:40 +0000

Can I just check I understand your idea correctly?

You're suggesting a device (or other consumer) is fed a URI of the form
wk:foo:example.com, and resolves this by:

1) Performing a SRV lookup on _foo._wk.example.com to find a hostname (eg,
server.example.com).

2) Forming an HTTP URI from this to the .well-known space formed from the
service name on that host (eg, http://server.example.com/.well-known/foo)

3) Performing requests on that, expecting to obtain a Content-Type header
reading "application/json; wk=foo" and processing accordingly.

If all this is correct, I think the basic mechanism is solid and should
work, and would give strong benefits if widely deployed.

At the risk of sounding frivolous, though, I suspect "wk" is not going to
gain as much traction as, say "api". I appreciate that the moment I send
this mail, there'll be a concurrent spluttering of morning coffee across
the world, but please bear in mind that a protocol mechanism designed for a
wide appeal needs some effort putting into its name. It doesn't matter if
".well-known" exists behind the scenes, but I don't think it'll resonate
with the bulk of web developers we'd be targetting.

Dave.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Feb 2013 11:15:39 +1100

... and furthermore, you actually get some evidence that such web developers would actually use and like such a mechanism before squatting on such valuable namespace.

Cheers,

On 16/02/2013, at 7:35 PM, Dave Cridland <[email-masked]> wrote:

> You're suggesting a device (or other consumer) is fed a URI of the form wk:foo:example.com, and resolves this by:
> 
> 1) Performing a SRV lookup on _foo._wk.example.com to find a hostname (eg, server.example.com).
> 
> 2) Forming an HTTP URI from this to the .well-known space formed from the service name on that host (eg, http://server.example.com/.well-known/foo)
> 
> 3) Performing requests on that, expecting to obtain a Content-Type header reading "application/json; wk=foo" and processing accordingly.
> 
> If all this is correct, I think the basic mechanism is solid and should work, and would give strong benefits if widely deployed.
> 
> At the risk of sounding frivolous, though, I suspect "wk" is not going to gain as much traction as, say "api". I appreciate that the moment I send this mail, there'll be a concurrent spluttering of morning coffee across the world, but please bear in mind that a protocol mechanism designed for a wide appeal needs some effort putting into its name. It doesn't matter if ".well-known" exists behind the scenes, but I don't think it'll resonate with the bulk of web developers we'd be targetting.
> 
> Dave.
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham   http://www.mnot.net/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 17 Feb 2013 19:32:11 -0500

On Sun, Feb 17, 2013 at 7:15 PM, Mark Nottingham <[email-masked]> wrote:

> ... and furthermore, you actually get some evidence that such web
> developers would actually use and like such a mechanism before squatting on
> such valuable namespace.
>
> Cheers,

I don't think that should be a problem.

There are two separate ideas here

1) One stop shopping for identifiers
2) Better discovery via SRV/URI/New RR

The two are orthogonal. If you get /.well-known/foo then you might or might
not want to use _foo._wk for SRV discovery but you certainly would not want
it to be used for anything else.

Now the argument for the API: or WS: (Web Service) method is a lot harder,
I agree. But given that it is prime real estate, doesn't it make best sense
to share it equitably?

> > 2) Forming an HTTP URI from this to the .well-known space formed from
> the service name on that host (eg,
> http://server.example.com/.well-known/foo)
> >
> > 3) Performing requests on that, expecting to obtain a Content-Type
> header reading "application/json; wk=foo" and processing accordingly.
> >
> > At the risk of sounding frivolous, though, I suspect "wk" is not going
> to gain as much traction as, say "api". I appreciate that the moment I send

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Feb 2013 12:07:23 +1100

On 18/02/2013, at 11:32 AM, Phillip Hallam-Baker <[email-masked]> wrote:

> Now the argument for the API: or WS: (Web Service) method is a lot harder, I agree. But given that it is prime real estate, doesn't it make best sense to share it equitably?

*If* your proposal for how to use it is, as I said, actually useful and attractive to web developers. 

Cheers,