Please feel free to discuss them here, however, given that the
industry has been shipping Bonjour products based on the spec for 5
years, we'd like to avoid making any changes that would break
backward compatibility.
I wouldn't dare propose a modification that would break things.
Besides, Bonjour is pretty much perfect the way it is! :)
The change I want to propose in your I-D is about DNS-SD's
interpretation of the transport labels in the service instance names
(i.e., "_tcp" or "_udp").
Current interpretation of _tcp/_udp in DNS-SD
----------------------------------------------
Section 7 of draft-cheshire-dnsext-dns-sd.txt states:
The "_tcp" or "_udp" should be regarded as little more than
boilerplate text, and care should be taken not to attach too much
importance to it. Some might argue that the "_tcp" or "_udp"
should not be there at all, but this format is defined by RFC
2782, and that's not going to change. In addition, the presence
of "_tcp" has the useful side-effect that it provides a convenient
delegation point to hand off responsibility for service discovery
to a different DNS server, if so desired.
The web site for DNS-SD service type registration also says:
Protocols that can run over either UDP or TCP (e.g. NFS) are
usually advertised using whichever transport is considered the
'normal' or 'primary' mode of operation (and clients should
attempt communication with the service using either or both
transports, as appropriate for the client).
What I'd like to propose
-------------------------
Somewhere along the line of: "The transport labels ("_tcp", "_udp" or
"_sctp", for example) in the service instance name SHOULD be regarded
as an indication of the transport protocol desired by the
advertiser. If the advertiser supports multiple protocols, it MAY
either publish multiple services with corresponding transport labels
or publish the service under one 'primary' protocol if such a
designation is clear."
Note that this does not invalidate the existing behavior. Service
protocols are still allowed to ignore the transport label and get
that info through some other means. I'm proposing that you don't
state it as the way it should be (as the I-D does now). Instead, you
should recommend that the transport labels should be taken to mean
the desired transport protocol (this complies with RFC 2782).
Ultimately the application protocol still has the freedom to
determine the transport protocol in however way it sees fit. I just
don't see any reason for DNS-SD to go out of its way to deviate from
RFC 2782.
Why it matters to me
---------------------
We wrote an I-D specifying how SIP user agents should advertise
themselves and how they should process the discovered peers. Since
SIP currently supports 3 transport protocols (tcp, udp and sctp) and
there is really no notion of a 'primary' one, designating one for the
purpose of DNS-SD announcement isn't very palatable.
Moreover, SIP already uses SRV records in its traditional client/
server settings (documented in RFC 3263). And in those settings, a
transport label means the desired transport protocol. It would have
been unacceptably confusing and inconsistent for us to specify that
the transport labels in SRV records should be ignored in the Zeroconf
setting, while the same thing is crucial in the traditional client/
server setting. These concerns are discussed in Section 7 of our I-D
(http://tools.ietf.org/html/draft-lee-sip-dns-sd-uri-00#section-7).
+++
Sorry for a long post. I feel that this change is not a big one. It
allows application protocols such as SIP that supports multiple
transports without favoring one to implement DNS-SD in a natural way
without deviating from the spec. I hope you take this request under
consideration.
Thank you.
Sincerely,
Jae Lee
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bonjour-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/bonjour-dev/email@hidden
