[elvin-discuss] Re: Elvin spec

[Ian Lister]

On Fri, 5 Jan 2007, Matthew Phillips wrote:
> On 05/01/2007, at 4:24 PM, Ian Lister wrote:
>> On Wed, 3 Jan 2007, David Arnold wrote:
>>> 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?

If the lack of support is local (e.g. your client library implementation 
doesn't support quench) there's no request at all.

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

Yes, Bonjour consists of IPv4LL (addressing), mDNS (naming) and DNS-SD 
(discovery). ERDP is the existing Elvin Router Discovery Protocol.

Cheers,

Ian