Other parts of this protocol not supported

wesleytodd commented 8 years ago

Other PR coming your way:

There are three other parts of the dns service name not supported in this module:

._tcp . . . . ._tcp . . . _{._sub . ._tcp . . .

The first example shows the name used for PTR queries. The second shows a Service Instance Name, i.e., the name of the service's SRV and TXT records. The third shows a subtype browsing name, i.e., the name of a PTR record pointing to a Service Instance Name}

Not currently supported:

Service Instance names
The service domain
The parent domain

The changes I was thinking of are as follows:

The object form of stringify should take an object of the form: {instance: <String>, name: <String>, protocol: <String>, subtypes: <Array>, serviceDomain: <String>, parentDomain: <String>}
The argument form of stringify should be dropped. With such a complicated set of params this would be a horrible api
The parse method would add matching keys on the returned object

The subtypes is already a breaking change, so my thought is a 2.0 with this and the subtypes would be a good idea. Thoughts?

watson commented 8 years ago

@wesleytodd I can't find any documentation on the difference between service and parent domains. Where did you find info on this?

wesleytodd commented 8 years ago

https://tools.ietf.org/html/rfc6763#section-7.2

watson commented 8 years ago

@wesleytodd I was reading that before but didn't really get that much wiser :wink: Reading it again now I think I interpret it like the following:

<parentdomain>

Required
If using the local link it's local.
It can be set to another domain that is "controlled" by the user, e.g. company-name.com

<servicedomain>

Optional
It's mostly used in large organisations that need to subdivide services into groups, e.g. building-12, orlando-office or accounting

Is that how you interpret it as well?

wesleytodd commented 8 years ago

yes mostly, but my assumption was that company-name was intended to be the service domain because otherwise it would be pretty hard to decide if the second part after the . is the service domain or part of the parent domain. Not that that is necessarily that the spec intends, but that any other way would be hard to parse.

watson commented 8 years ago

Just re-read this from the RFC:

[...] This leaves 100 bytes to accommodate the organization's existing domain name <parentdomain>. When used with Multicast DNS, <parentdomain> is "local.", which easily fits.

From this I gather that when using DNS-SD together with mDNS, the <parentdomain> is always local.. But apparently you can use DNS-SD in non-mDNS environments as well in which case "the organization's existing domain name" will be the <parentdomain>. And "existing domain" sounds to me like it's company-name.com, no?

watson commented 8 years ago

I think the algorithm for detecting this would be something like this:

If the full domain ends in local. this will be the <parentdomain>
If the full domain doesn't end in local. the <parentdomain> will include the stuff before the last period as well, e.g. whatever.tld
The domain contains a <servicedomain> if the part before the <parentdomain> isn't either _tcp or _udp

wesleytodd commented 8 years ago

And "existing domain" sounds to me like it's company-name.com, no?

Yep, didn't see that part, totally agree. So for something like this _http._tcp.foo.example.com what do we get? Seems like this would make foo the service domain?

If the full domain ends in local. this will be the <parentdomain>

So I tried getting local. to work, but for some reason only local worked when I actually registered my services on the network. Not sure why since the spec is pretty clear, but it didnt work for me.

watson commented 8 years ago

And "existing domain" sounds to me like it's company-name.com, no?

Yep, didn't see that part, totally agree. So for something like this _http._tcp.foo.example.com what do we get? Seems like this would make foo the service domain?

Yes

If the full domain ends in local. this will be the <parentdomain>

So I tried getting local. to work, but for some reason only local worked when I actually registered my services on the network. Not sure why since the spec is pretty clear, but it didnt work for me.

Are you referring to the trailing period after "local"? I've been meaning to debug why that's not working. As you say the RFC is pretty clear on that so it should work. It could be a bug in the multicast-dns module - but for now I've just left it out since that seems to work ok without it.

wesleytodd commented 8 years ago

but for now I've just left it out since that seems to work ok without it

exactly what I did.

Ok, probably this weekened I will take a look at my changes and make sure they incorporate these notes. Thanks!

watson commented 8 years ago

@wesleytodd I'll hopefully get through my backlog of issues and pull requests over the weekend as well :smile:

mafintosh / multicast-dns-service-types

Other parts of this protocol not supported #5