[avahi] Re: [avahi-commits] r637 -
marc at apple.com
Tue Sep 27 22:07:18 PDT 2005
On Sep 27, 2005, at 8:01 AM, Lennart Poettering wrote:
> Our list is not intended as an official service type list like the one
> you maintain on http://www.dns-sd.org/ServiceTypes.html
> Instead this is used execlusively for improving user experience in
> network browsing tools. "Web Service" is easier to understand from a
> user perspective than "_http._tcp." Our list handles i18n and doesn't
> contain any information about TXT records. It's not a documenation for
> developers but only service type translaton table for user
> interfaces. Due to this the wording is not the same as in your
> list. e.g. in your list we find the description "IPP (Internet
> Printing Protocol)" for _ipp._tcp. In our list this is available as
> "Internet Printer". When compiling Avahi the list is converted into to
> a gdbm file, and installed that way. To say it in FHS terms: the list
> is installed to /usr/share/avahi/ and not to /usr/share/doc/avahi.
> Our list is only updated when someone comes across a service not yet
> contained in the list in the first place.
OK, cool. Just send me an e-mail anytime you need to add a new type
to the list, and I'll add it right away.
> We could certainly agree on moving this list out of the scope of Avahi
> to something more global, like dns-sd.org.
>> I'm also wondering what you mean by the comment that says dns-sd.org
>> "is not a source that complies with the criterion". The list on dns-
>> sd.org doesn't really have a license because it's just a list of
>> service types. If you feel like you can't use this list, then I'm
>> sure we'd be willing to slap a BSD style license header to the top of
>> this page.
> Yes, A BSD license would be nice for that. Does the list exist in a
> form that is more easily parsed for generating a gdbm file?
Yeah, we've had requests for this. Just haven't gotten around to it
> In case you make the list available under BSD we would surely copy it
> from time to time into our database.
>> Regarding the RSS types, I'm wondering why we need two different
>> types for this. Wouldn't "_rss._tcp" be enough? Can't the protocol
>> figure out what version to use?
>> As an example, we don't have an _http10 and _http11 type, and there's
>> ssh version 1 and version 2, but we only have a single _ssh type.
>> I think RSS is important enough that we should think about this a
>> little first, because whatever we decide, it will be in use for many
>> years, and it's always a pain if applications that used to browse for
>> the *wrong* type then have to transition to the new type by browsing
>> for both for a little while. I hate it when that happens. :-)
> Hmm, HTTP 1.0/1.1 are completely upwards and downwards compatible as
> far as I know. However this is not true for RSS 0.91 vs. RSS
> 2.0. That's why I used different service types for them.
I pretty much know nothing about RSS, but according to this site.
"The elements defined in this document are not themselves members of
a namespace, so that RSS 2.0 can remain compatible with previous
versions in the following sense -- a version 0.91 or 0.92 file is
also a valid 2.0 file. If the elements of RSS 2.0 were in a
namespace, this constraint would break, a version 0.9x file would not
be a valid 2.0 file. "
So it sounds like a client that understands RSS 2.0 feeds will also
understand RSS 0.9.x feeds. This means that older RSS clients
browsing for "_rss" might discover newer 2.0 feeds that they wouldn't
be able to parse. I'll bet that if a customer came across a feed
that they couldn't read, they would quickly replace their out-dated
RSS client with a newer version, so this problem solves itself.
> I actually introduced this service type because someone on IRC showed
> interested in adding support for it to some RSS aggregator app. We
> quickly agreed that _http-rss091._tcp, _http-rss20._tcp and finally
> _http-atom._tcp would make some sense. Since we couldn't find a trace
> of a RSS DNS-SD type on the internet yet, we simply went on and added
> it to our list.
> Using just "_rss._tcp" instead of "_rss-http._tcp" doesn't look
> logical to me, since the protocol used IS actually HTTP, only the
> resource referred to is RSS. This is somewhat similar to
> "_ssh-sftp._tcp" i guess.
Actually, it's "sftp-ssh". The only reason we did that was because
the IANA protocol list already had an "sftp", Simple File Transfer
Protocol, so we had to pick something else.
We decided on "SFTP over SSH", or "sftp-ssh". Similar sounding to
"TCP over IP" or "TCP/IP". I guess since RSS could use a different
transport protocol, then it might make sense to call it "RSS over
> What do you think about this? We can certainly agree on a common name,
> since there is no real softwaring actually using it available yet.
> BTW: May I politely ask you to add a link to Avahi on either
> dns-sd.org or multicastdns.org, the way you already added a link to
> those Java, Ruby or Python implementations?
No problem. I added a link for you.
More information about the avahi