Actually, I would argue that the suggestion for application/beep+xml is
remarkably similar to the existing MIME type message/http, defined in
Section 19.1 of RFC 2616. <http://www.normos.org/ietf/rfc/rfc2616.txt>
I thought of suggesting message/beep+xml, but section 5.2.4 of RFC 2046 says
that:
Future subtypes of "message" intended for use with email should be
restricted to "7bit" encoding. A type other than "message" should be
used if restriction to "7bit" is not possible.
It isn't actually clear that the second sentence's prohibition of message
types for binary content is intended to apply outside of email, but
application/beep+xml seems the more conservative approach.
- dan
--
Dan Kohn <mailto:dan(_at_)dankohn(_dot_)com>
<http://www.dankohn.com> <tel:+1-650-327-2600>
-----Original Message-----
From: James Aylett [mailto:james-ietf(_at_)tartarus(_dot_)org]
Sent: Friday, 2000-10-20 10:16
To: bxxpwg(_at_)lists(_dot_)invisibleworlds(_dot_)com
Subject: Re: [BXXPwg] Re: application/beep+xml
On Fri, Oct 20, 2000 at 07:52:37AM -0700, Marshall Rose wrote:
1. text/xml isn't the right tag to use for xml-based profiles
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...
I'm probably being stupid, but the way I see it, the protocol
exchanges that BEEP uses are actually reaching the limit of what MIME
types can sensibly be used to classify.
I think that Marshall's "these aren't documents" can be rephrased as
"these aren't MIME entities". They certainly don't have the same
function as MIME entities in anything else I can think of (although
they can often act as transport for a contained entity).
So, as far as we need some sort of MIME type indication, the opaque
application/xml is probably the best solution.
(I hesitate, but think it perhaps worth pointing to:
draft-eastlake-cturi-00.txt gives a mapping between content types and
URIs. I don't think it's even vaguely sensible to use the content type
obtained by mapping the URI of the profile register here, but I
thought I'd point it out in case anyone disagreed.)
Cheers,
James
--
/--------------------------------------------------------------------------\
James Aylett www.zap.uk.eu.org
james(_at_)tartarus(_dot_)org
www.footlights.org
_______________________________________________
BXXPwg mailing list
BXXPwg(_at_)lists(_dot_)invisible(_dot_)net
http://lists.invisible.net/mailman/listinfo/bxxpwg