Given that all beep protocol exchanges are either channel setup or beep
profile exchanges, it seems like application/beep+xml could still be a good
choice. Just say in the registration that the DTD used is either the one in
the beep framework document or a specific beep profile as specified by the
profile entity URL.
I definitely agree, though, that each beep profile should not need it's own
MIME type.
In general, the MIME concept of taxonomy has seemed to work quite well (I
realize I'm preaching to the choir here), and the subset of documents that
are beep or beep profiles seems much, much smaller than the set of all XML
documents.
- dan
--
Dan Kohn <mailto:dan(_at_)dankohn(_dot_)com>
<http://www.dankohn.com> <tel:+1-650-327-2600>
-----Original Message-----
From: Marshall Rose
[mailto:mrose+mtr(_dot_)netnews(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us]
Sent: Friday, 2000-10-20 07:53
To: Dan Kohn; bxxpwg(_at_)lists(_dot_)invisibleworlds(_dot_)com
Cc: ietf-xml-mime(_at_)imc(_dot_)org; Marshall Rose
Subject: Re: application/beep+xml
hi. i think you raise three issues:
1. text/xml isn't the right tag to use for xml-based profiles
2. rfc1982 on sequence number arithmetic should be referenced, e.g.,
Consult Sections 2 through 5 of [8] for a discussion of the arithmetic
properties of sequence numbers.
3. the "URL:" in things like "<URL:http://iana.org/>" should be removed
2 & 3 are editorial, and probably not all that controversial. if anyone
objects to making these changes, speak up.
the first issue requires more discussion.
i'll agree that text/xml isn't optimal for the reasons you suggest (e.g.,
not intended for display to humans).
so, if text/xml is out, what should we use instead?
the things being moved around in the xml-based profiles described in beep
are protocol exchanges, not documents. when a channel is started, a
negotiation process is used to determine which profile is bound to the
channel. the registration for this profile defines what the exchanges look
like.
so, having each profile register its own mime type is at best redundant.
worse, since the whole point of using URIs to identify profiles was to get
away from a centralized registry, a mime type per profile negates this
property.
this leaves application/xml, which is as good a choice as any, i guess...
/mtr