Re: [Acme] Message Type/Version Identifiers

[Phillip Hallam-Baker <[e-mail]>]

On Fri, Dec 19, 2014 at 1:34 PM, Richard Barnes <[e-mail]> wrote:
>
>
>
> On Fri, Dec 19, 2014 at 1:12 PM, Martin Thomson <[e-mail]>
> wrote:
>>
>> On 18 December 2014 at 21:07, Anders Rundgren
>> <[e-mail]> wrote:
>> > 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.
>>
>> I think that you are both over-engineering it.  Identify this as
>> "acme".  If you need to make changes that aren't backward compatible,
>> call it "acmi".
>>
>
> And then, "acmii", "acmiii", "acmiv", ...?  :)
>
> I think the idea of separating things by URI is the right track.  That
> punts the versioning question to discovery/configuration.
>

Noooooo

The URI that the Web Service is provided from has no connection to the
unique identifier for the specification.

I am not wedged on the Major.Minor version thing. We could just as easily
use keywords for both and that is a little simpler. We very rarely make
backwards incompatible changes in any case and we don't add features
monotonically so minor version numbers don't add anything that can't be
said in a feature tag.


SMTP has worked fine with a Feature tag approach. We have POP3 and IMAP4.

Whether we structure them as tags or URIs the structure is exactly the
same. The URI is an opaque identifier. Defining semantics on the internal
syntax of a URI is bad juju.


So the difference is

POP3
urn:ietf:service-names-port-numbers:TCP:POP3


The second does not provide anything the first does not. All it does is
make the protocol longer and harder to read.