[avahi] Re: [avahi-commits] r637 - /trunk/service-type-database/service-types

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  
yet.

> 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.

<http://blogs.law.harvard.edu/tech/rss>

"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.

<http://www.iana.org/assignments/port-numbers>

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  
HTTP", "rss-http".

> 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.

cool.

> 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.

-Marc