[elvin-discuss] Re: Elvin spec
matt at mattp.name
Tue Jan 2 21:35:23 CST 2007
On 03/01/2007, at 1:17 PM, David Arnold wrote:
> On 28/12/2006, at 2:50 PM, Matthew Phillips wrote:
>> On 28/12/2006, at 9:28 AM, David Arnold wrote:
>> Actually, now I think about it, one minor thing that I would like
>> to add is a "not implemented" NACK code for use by implementations
>> that do a subset of the spec. Or perhaps a way to indicate that
>> via connection options, similar to "Supported-Key-Schemes". e.g.
>> "Supported-Protocol-Subsets: A, B".
> yeah. i'd like to do both, actually.
> most important is the NACK code, i think. there's not much
> alternative for a client library than passing back a NOT_SUPPORTED
> to the application, but given it's allowable to have routers
> without quench, etc, it's gotta be reported somehow.
Yep. I've made up an error code for now that je4 seems to handle OK,
which at least allows Sticker's setup wizard to work (it uses quench
to guess what presence groups are active). But that this works is
obviously more by luck than by design. And I don't know how the other
client libraries will deal with it either...
> of course, it'd also be good to have this advertised in the
> ConnRply options so the client's options callback can reject the
You mean the client would request certain capabilities in the
connection options and the router would ACK/NACK them? Or just that
the server sends to client what it can do same as "Supported-Key-
> as it happens, this ties in nicely with some work we did in 4.4 to
> deal with authorisation: it's possible to disallow clients access
> to subscription or quench (or notification). that ended up being
> advertised using named options.
> i'm not sure whether to try to push those options back in the 4.0
> protocol spec, or not. it's tempting though ... ?
> we still have to add the extra packet from the 4.1 protocol, and
> then the authentication support from 4.4 ... i'd prefer to put that
> into subsequent spec versions (and get 4.0 finished), but i guess
> we should consider what you'd like to do with Avis, Matt?
Since Avis 1.0 will do the A & B subsets, the only remaining basic
requirement for getting to release stage now is to just have a
sensible way to advertise that, and be able to bounce C-level stuff
So, if it's possible to back-port to 4.0 an extendable subset of
whatever will be in 4.4 for indicating what capabilities a client can
exercise with the router, that would seem like a sensible approach.
Then the development path would be for subsequent Avis releases to
track spec updates.
Enjoy the beach!
More information about the elvin-discuss