[elvin-discuss] Re: Elvin spec

[Matthew Phillips]

On 05/01/2007, at 4:24 PM, Ian Lister wrote:
> On Wed, 3 Jan 2007, 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.
>
> 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.

Alright, but for neatness sake it might be nice to use a prefix for  
capability fields, e.g. "Capability.Subscribe", "Capability.Quench",  
etc. Doesn't fit with how it's done in Supported-Key-Schemes, but...

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

Not sure what the difference is? Either a request is recognised but  
not supported or it's a protocol violation surely?

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

Hmm, I have no idea what any of that means :) But it's an opportunity  
to point out that I'm thinking that advertising the router using mDNS  
(Bonjour) might be a useful thing to do. Any opinions?

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

Yes, I think that was also the gist of my response too.

>> but i guess we should consider what you'd like to do with Avis, Matt?
>
> Ship it!
>
> Oh, sorry... :-)

Would love to ;) And in fact I think it's very close. Just need to  
clear up this issue and get in a little more field-testing with the  
deployment packages and then I'll qualify for my Ship It! award.

Matt.