> 2. Distribution.
> a) DNS (with HTTP proxy for those with firewalls)
> b) NNTP, or at least a minor variation on it. (with HTTP proxy again)
> c) HTTP with mirroring (as CDDB does now)
Aren't there are two parts to this---the query-answering part and the
database replication part?
2a. Answering queries
a) HTTP
b) DNS
c) Other (UDP and telnet have been mentioned briefly)
I think it is widely agreed that we MUST have an HTTP query mode, even
if it is not the primary one. I like the DNS idea, because it spreads
the load out and already exists, but I'm not quite sure how feeding the
information in at the root is supposed to work. It seems to me that
we need a layer of root servers to collate submissions and pass stuff
around amongst themselves with some other protocol, before they feed
the digested results in to the DNS system. So there is this other
layer to talk about:
2b. Database distribution
a) NNTP-like
b) DNS
c) Trusted web (like irc/existing cddb)
d) Informal web
I haven't seen anyone really tackle the details of these. d) would be
nice if we could figure out how to do it, but I suspect that c) will
win for simplicity.
> 3. Server.
Whatever the implemetor fancies if it can produce the output required
(either answers to queries or the DNS root files).
On a related note, it would be good to define a neutral file format for
archiving and bootstrap purposes.
> 4. Submission.
> a) Fixed format Email
> b) Simple one way protocol - like a form submission on the web
> c) More complex protocol with provision for feedback from the server
> d) NNTP post, assuming we go for the NNTP model
For a relational database to really work well, links between identities
need to be set up. This is hard to do with free-format text fields,
where a space or capital letter may or may not be significant.
> 5. Genres.
This is a similar issue to ``1. Protocol'' and gets a similar answer:
extensible with a small standard set.
> 6. Licensing.
Licensing applies separately to client code, server code and database
(the protocols can't have and don't need protection).
6a. Client code. Having a completely free, basic client reference
implementation seems like a good idea to encourage the widest adoption.
If some authors want to take it further, it's up to them how liberal
they want to be.
6b. Server code. Surely GPL?
6c. Database. May not be protectable with the law anyway, so protect
it practically by replication.
> 7. Conflict resolution.
> a) Latest entry rules.
> b) Most common entry rules
> c) PGP signed submissions - so the submitter is accountable in case
> of spam
You missed:
d) Hash-signed submissions - so the submitter can later prove they
are the submitter
> (I have to admit [PGP] seems like overkill. Spamming a free
> music database seems an awful lot like pissing in your own pool to me)
It's somebody else's pool from an outsider's point of view. I agree that
c) is too heavy to be a requirement. But with the extensible database
those interested and equipped to do so can sign their entries in an
optional field.
I don't like solutions which depend on centralised control. This is a
grass-roots effort and should do its own moderation in that style.
> 8. Mailing lists :-)
> a) cdin.org
> b) bigred.lcs.mit.edu
> c) freeamp.org
I have only posted to and read freeamp.org. cdin's web archive is nice,
but I assume that someone will eventually feed it all the messages from
the other lists anyway, so I won't CC there.
> 9. A few points that everyone seems to agree on (yes, there are some):
> * Use of UTF-8 (Unicode) to allow foreign character sets
> * Allow current CDDB clients to access this new service by providing
> some sort of portal.
I agree:-)
> Personally, My opinion would be to go for the single server, receiving email
> submission, processes it to handle conflicts, and then pops it out to DNS
> for replication, which is then queried by the clients (either directly or
> via an HTTP proxy).
I don't like the single server, but I could live with the rest.
Robin.
-- R.M.O'Leary <robin nospam at acm.org> +44 7010 7070 44, PO Box 20, Swansea SA2 8YB, UK