[elvin-discuss] Re: Elvin spec

Ian Lister ilister at mantara.com
Thu Jan 4 23:54:34 CST 2007

On Wed, 3 Jan 2007, David Arnold wrote:
> i *think* (bear with me, i'm at the beach, and recall is not at its best :-) 
> that the major remaining issue is tidying up the error codes.  there's a few 
> non-standard numbers, etc, that have crept into Mantara's elvind, and i'd 
> like to make sure the spec covers the errors in use, and that they've got 
> sane numbers.


>> 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.

FWIW I dislike the "Protocol-Subset: A" business. I'd much rather 
something more like what we do for authorisation in 4.4 e.g. 
"Supports-Subscription: 1" (or just "Can-Subscribe: 1") or whatever.

> 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.

NO_ROUTER_SUPPORT, of course. If you got a NOT_SUPPORTED (implying the 
lack of support is local) you'd just give up and go home, but with 
NO_ROUTER_SUPPORT it's worth continuing to try other routers.

> of course, it'd also be good to have this advertised in the ConnRply options 
> so the client's options callback can reject the connection.

And in real service discovery too: ERDP (if we continue to develop it), a 
standard DNS TXT format (for DNS-SD), and whatever else.

> 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 ... ?

Resist! :-)

They're an extra feature that's only just now being deployed and can be 
added to the spec later without breakage.

(Although if there's some incompatibility potentially caused by adding it 
later we should change the 4.0 draft spec to remove that and allow us to 
add the feature to the spec later without incompatibility, of course)

> 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),

Good plan :-)

>                                       but i guess we should consider what 
> you'd like to do with Avis, Matt?

Ship it!

Oh, sorry... :-)



More information about the elvin-discuss mailing list