Re: [Acme] Message Type/Version Identifiers

On 2014-12-18 22:43, Phillip Hallam-Baker wrote:
> +1
>

Just for the record, service discovery will in your opinion eliminate the
need for explicit version information at the message object level (because this is
really what I'm asking for)?

I prefer URIs but of course traditional minor.major works as well.

Anders

> 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 <http://ws.example.com> SRV 1 1 443 acmehost.example.com <http://acmehost.example.com>
>
>
> The host is acmehost.example.com <http://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 <mailto:martin.thomson@gmail.com>> wrote:
>
>     On 18 December 2014 at 03:08, Anders Rundgren
>     <anders.rundgren.net@gmail.com <mailto: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 <mailto:Acme@ietf.org>
>     https://www.ietf.org/mailman/listinfo/acme
>