Re: [Acme] Message Type/Version Identifiers

+1

We are doing an IETF spec, not a W3C spec.

I have a lot of experience in using URIs as protocol identifiers, I
originally proposed using them in the PICS spec them and I don't think they
work at all. In the PICS spec the specific objective was to drive a wedge
between the Dworkin/Mackinon supporters of censorship and the Religious
Right supporters. If there had been one control lever they would have been
forced to work together to agree on its use. Giving each their own lever
collapsed their coalition.

In that particular instance it was essential to provide a mechanism that
allowed anyone to fork at any time. So it could not use a protocol registry.

Here we have a Web Service spec and the objective is to end up with a
common spec. So the starting point should be an IANA registration. Since we
are doing Web Services, the obvious registry is the SRV registry. It would
also be rather convenient to have a .well-known default URI.

I see no reason not to use the prefix ACME for both. So initial discovery
would be via SRV record:

_acme._ws.example.com SRV 1 1 443 acmehost.example.com

The host is acmehost.example.com, so the service URI is:

http://acmehost.example.com/.well-known/acme/

That leaves two other questions, one is protocol version and the other is
service feature set. These are independent. There might be a 1.0 service
that supports the issue of both server and client certs and a 3.0 service
that only supports server.

We discussed this earlier, but one of the features many folk have suggested
for the ACME protocol is a mechanism that allows a client to interrogate it
to ask what it supports. I think this can be described as an instance of a
general mechanism that can be copied by other specs.

For versioning, the usual Major.Minor convention works fine.
For feature sets, an IANA registry of text keywords using the RFC20 subset
of UTF8 (as we now refer to US-ASCII).

So I would see a conversation of the following sort:

http/1.1 GET http://acmehost.example.com/.well-known/acme/
.. headers ..

{ "Describe" {} }

Responses might be

{ "Versions" : ["1.0"] }

{ "Versions" :["1.0"],
  "Supports" : [
     {"ACME" : ["Server", "Client"] }] }

{ "Versions" : ["1.0", "2.0"]
  "Supports" : [
     {"ACME" : ["Server"] },
     { "Versions" :["2.0"], "ACME" : ["Server", "Client"] }] }

So the first only supports the default features. The second supports Client
and Server cert issue. The third supports the 2.0 version of the protocol
as well as 1.0 but only supports client cert issue for 2.0.

Specifying the Feature and Version numbers as strings allows for a lot of
flexibility. So for example, a service might support version 1.0 and 3.0
but not 2.0 which turned out to be a doofus version (think X.509v2 certs).

If we do this in a well defined fashion we can eventually push the same
attributes out into the DNS as part of the service registration interface
and publish them via some new RR that is TBS which would allow them to be
used for host selection.

Using the SRV/WKS label for the features tag identifies these as attributes
that would be defined in the ACME registry. this allows for better reuse of
code points in the case that we were to use this for other negotiation
dimensions.

An ACME service that does not support the Describe method would only
support the 0.0 version of the service by definition.

Like the signature scheme outlined earlier, this is a module that can be
reused very easily.

On Thu, Dec 18, 2014 at 2:53 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:
>
> On 18 December 2014 at 03:08, Anders Rundgren
> <anders.rundgren.net@gmail.com> wrote:
> > I have "backported" these things to JSON because I think they were
> good.  A
> > system like
> > ACME could also use such a scheme since there will undoubtedly be
> revisions
> > over time.
>
> I can appreciate the attraction, but this is a big "no" for me.
> Absence of these features is one of the reasons that JSON has proven
> successful over XML.
>
> If you need versioning at that level, I'd recommend defining a content
> type instead.
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>