[elvin-discuss] Re: Elvin spec

Ian Lister ilister at mantara.com
Sun Apr 15 23:04:04 CDT 2007


On 16/04/2007, at 1:12 PM, David Arnold wrote:
> -->"Ian" == Ian Lister <ilister at mantara.com> writes:
[On 3 Jan 2007, David 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.

[On 5 Jan 2007, Ian wrote:]
>>>> 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.

[On 5 Jan 2007, Matthew wrote:]
>>> Not sure what the difference is? Either a request is recognised
>>> but not supported or it's a protocol violation surely?

[On 8 Jan 2007, Ian wrote:]
>   Ian> If the lack of support is local (e.g. your client library
>   Ian> implementation doesn't support quench) there's no request at  
> all.
>
> except that NO_ROUTER_SUPPORT and NOT_SUPPORTED are Mantara-specific,
> libelvin error codes, not protocol NACK error codes.

I think we've already been through this in your mail of 11 Jan and my  
reply of the same day, but the point was that the reference to  
NOT_SUPPORTED (and, subsequently, NO_ROUTER_SUPPORT) was in the  
context of "a client library passing back a NOT_SUPPORTED to the  
application" i.e. an API level error code. This is of course all  
fairly tangential to the topic at hand, which was the protocol Nack  
code, but I believe you raised it in the paragraph at the top of this  
mail because the protocol needs to be able to identify the error  
specifically in order for the API to be able to.

> in this case, i think the error should be treated similarly to a
> subscription language syntax error: the state machines are still in
> sync, it's just that a requested feature is unavailable from the  
> current
> router.

Yep.

> on that basis, i think error code 2007 would be appropriate?  and,
> assuming existing client libraries are correctly implemented, they
> should cope nicely.

Yep. As per my reply to a subsequent email on 11 Jan in which you  
proposed this, I have no problem with that.

> IPv4LL is about automatic address assignment in the absence of a DHCP
> server.  i think it's irrelevant to an Elvin router implemention.

Yes.

> mDNS is multicast DNS resolution.  in itself, i think it's irrelevant
> also (but see below).

Yes.

> DNS-SD is the interesting bit of Bonjour as far as service discovery
> goes.  IIRC (i haven't looked at it for a while), it uses a DNS  
> name of
> the form _service._protocol.local to identify the target service, and
> mDNS resolve the query.

The .local suffix ties it to mDNS, but it is also designed to be used  
with existing domains and normal, unicast DNS.

> i think the service bit uses the IANA-assigned name for the protocol.
> in the case of Elvin clients, that should be  
> 'elvin_client' (although i
> *think* underscore is illegal in DNS names, so not sure what's going
> on there).

It's illegal in host names and mail domains, but DNS itself is happy  
with just about anything as a label.

> the protocol bit should be '_tcp' for TCP-based services.
>
> this is all just my recollection.
>
> Stuart Cheshire has a fairly helpful web site for all the specs,  
> links,
> etc.

And, for those interested, it's at: http://www.dns-sd.org/

Cheers,

Ian


More information about the elvin-discuss mailing list