[icecast] a new directory service

[rillian]

Forgive the lack of antecendents. I just now joined the list, but will 
respond generally to what I saw in the list archives.

I think jack's suggestion of distinguishing between static and 
time-depended data is a smart one. I would also suggest that many of the 
ranking issues people are concerned about can be addressed through the 
description field. Punting things like 'now playing' to a metadata 
stream seems like a good idea. Directory servers can watch this directly 
and add it to their displays if they think that's worthwhile.

The ttl field does provides some time-dependence capabilities, and it 
can be abused by setting it too short as well as too long. The latter 
case can be solved though a no-ping expiry policy on the directory 
server as jack suggested. Probably we should just design so '0' is also 
an acceptable setting, and let individual maintainers decide on a 
minimum individually.

The ttl field in dns is mostly there to control propagation through a 
distributed cache. Are we planning something like that for the icecast 
directory(ies)?

> auth
>         authorization string. this is a md5sum of of some
>         random data.
>         ex.: echo 'jack at xiph.org|Jack Moffitt|password' | md5sum

As written, this adds little security over sending the password in 
plaintext. Some folks at mit recently wrote a nice summary of how to do 
secure auth over the web:

     http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf

Unfortunately, anything more secure requires a shared secret, and thus 
and ssl-connection over which to send it. For example, running the 
contents of the update through the hash in addition to the password 
would let the server verify each update directly and block replay 
attacks. Of course, this assumes the connection in between is more 
vulnerable than the server and/or the client's machine, so perhaps in 
practice it's so much better. Still, I think it's worth trying to do 
this right.

> We could add a second tag 'rate', which could be in kHz for audio, and
> in fps for video based streams. We could also add a 'channels' to
> describe the number of audio channels (it's not unlikely we will see
> surround sound Ogg streams) and maybe a 'size' for picture size (ex.:
> 160x120).

I think a separate table is needed with stream urls and this specific 
metadata, all of which sits under the more general data like stream 
name, homepage and description. That easily takes care of both mirrors 
and alternate bitrate versions of the same content.

All the extra bits get complicated fast, but bitrate, samplerate, number 
of channels, and size seem like a good starting point. Maybe 'size' 
should be replaced by 'format' which can be the resolution/aspect ratio 
for video and the surround format for audio.

You might also want some sort of sub-description that could say things 
like 'Pacific Mirror'.

Otherwise, the general layout looks good. Program 'guides' for a 
particular station with scheduled programming is another nice feature, 
but it's somewhat orthogonal to what jack has suggested. I do think it's 
perfectly reasonable for the same software to support it, but we should 
think about it as a separate piece of information. Anybody know if 
here's an xml working group for program listings? :)

IMHO,
  -r

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to 'icecast-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.