search

core-wg / rd-dns-sd

CoRE Resource Directory: DNS-SD mapping
Other
1 stars 0 forks source link

Service name collisions #5

Open chrysn opened 6 years ago

chrysn commented 6 years ago

The current text proposes exporting rt="X.Y" as Y._sub._X._udp.

Given that there is one registry for all rt values, and another one for DNS-SD services, I think (and will propose a text to) we should rather do the following:

rt="X.Y" maps to X.Y._sub._coap._udp

(We might need to replace the dot, but maybe we can keep it because dots are legal in DNS-SD as names are never shown in dotted domain notation anyway).

We can allow other mappings for resource types that explicitly have an own DNS-SD type -- so for example if dali not only registers dali.* in the Resource Type subregistry but also _dali._udp in the DNS-SD registry, they can in their respective entries say that rt=dali.X should be mapped to X._sub._dali._udp for CoAP resources.

I think that the latter would work especially well with non-CoAP protocols registered as alternative addresses in the RD. For example, if a vendor has always used HTTP and DNS-SD to announce services as _vnd._tcp, they could state that ;exp;rt=vnd links with http URIs can be mapped to _vnd._tcp with the rest of our mechanisms. An HC proxy that the RD is aware of would then do wonders.

chrysn commented 6 years ago

(To emphasize my point about mappings needing per-vendor definition: Another vendor "vxr" might define _vxr._tcp to not use HTTP but CoAP-over-TCP; whatever scheme we come up with that is not specific per resource type can not cover all possibly desired behaviors).

chrysn commented 6 years ago

During the IEFT100 meeting, Dave Thaler noted that multiple dots in the name could be an issue.

While dots can be represented in the sub-type, the DNS-SD mapper would still need to know on which of the dots to split.

chrysn commented 6 years ago

During the IETF100 meeting, Tim Carey suggested that if the origin server needs to cooperate anyway, it could just as well publish the service name.

That would be an alternative solution to this issue.

A possible syntax and mapping could be an "sd-type" and an "sd-sub" target attribute; the rt would not be considered any more then at all. Those parameters might remove the need for an "exp" parameter.

kerlyn-bsd3 commented 6 years ago

What the -00 draft fails to make clear (because it has been stripped of rationale) is that the Y._sub.X.<_transport> form makes it possible to implement federated namespaces. The "X" label is registered in the DNS-SD registry and the SDO that has "ownership" of that label is free to assign "Y" labels, which it defines internally.

I am not in favor of X == _coap nor of embedding '.' in labels. I've always considered the <_transport> label as a vestige of how SRV RRs were defined back at the dawn of time. In the event, DNS is the only service I'm aware of (so far) that has both a TCP and UDP binding. (Note that DNS is a service, whereas CoAP is a transport). If we somehow have a need to search DNS for services on a particular stack arrangement, I think we should discuss that as a separate issue.

chrysn commented 6 years ago

How would you propose to deal with the registry conflation? (Leaving it as is would need to make IANA block everything from 1password to yakumo for rt= values, and introduce core, oic, bbf and oma into the DNS-SD registry).

My current personal favorite is Tim's suggestion of having an explicit link property rather than assuming that relying on rt to be usable -- that'd work without having _coap around and without placing dots within DNS labels.