RE: [BXXPwg] Re: application/beep+xml

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@xxxxxxxxxxx>
<http://www.dankohn.com>  <tel:+1-650-327-2600>

-----Original Message-----
From: James Aylett [mailto:james-ietf@xxxxxxxxxxxx]
Sent: Friday, 2000-10-20 10:16
To: bxxpwg@xxxxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxx                                    www.footlights.org


_______________________________________________
BXXPwg mailing list
BXXPwg@xxxxxxxxxxxxxxxxxxx
http://lists.invisible.net/mailman/listinfo/bxxpwg