There is a mailing list discussing XML and MIME types:
To: ietf-xml-mime(_at_)imc(_dot_)org
List-Archive: <http://www.imc.org/ietf-xml-mime/mail-archive/>
List-ID: <ietf-xml-mime.imc.org>
List-Subscribe: <mailto:ietf-xml-mime-request(_at_)imc(_dot_)org?body=subscribe>
I have cross-posted to that list.
Regards, Martin.
At 19:41 1999/11/08 +0100, owner-ietf-types(_at_)dokka(_dot_)maxware(_dot_)no
wrote:
Date: Fri, 05 Nov 1999 16:18:52 +0100
From: Christophe Vermeulen <christophe(_dot_)vermeulen(_at_)alcatel(_dot_)be>
To: ietf-types(_at_)iana(_dot_)org
CC: impp(_at_)iastate(_dot_)edu
Subject: Registration of MIME media type presence/xml
List-Unsubscribe:
<mailto:ietf-types-request(_at_)alvestrand(_dot_)no?body=unsubscribe>
Dear sirs,
Recent discussions inside the Instant Messaging and Presence
Protocol (IMPP) WG did show that the presence information
may need the registration of a new MIME type. However, it
is not clear to the group which MIME type should be pursued,
in order to avoid future inter-operability problems.
In particular, while the WG wants to focus on only one format
for presence, the prior existence of several Instant Messaging
systems and protocols, that may use various mix of technologies
and formattings such as attribute:value, vCard, ASN.1 or XML,
brought some of us to think that asking for the registration of
one subtype such as application/presence may be very shortsighted.
Could you tell me what your first impression is on such a
draft request, as include below, so that the Workgroup may
get a clearer idea on how to proceed further ?
You may recognize that some parts of this draft are literally
copied from the XML Media Types RFC, as XML is also proposed
as the subtype in this draft proposal.
Please note that this mail and the following draft registration
form are neither endorsed by the WorkGroup, nor a formal request
to register the proposed MIME type, but only a personal request
that may serve as basis for discussion.
Thanks in advance.
-- Begin Draft
MIME media type name: presence
MIME subtype name: xml
Required parameters: none
Optional parameters: charset
"UTF-8" [RFC-2279] is the recommended value, representing
the UTF-8 charset. If absent, US-ASCII has to be assumed as
of [RFC-2046].
Encoding considerations:
This media type MAY be encoded as appropriate for the charset and
the capabilities of the underlying MIME transport. For 7-bit
transports, data in both UTF-8 and UTF-16 is encoded in quoted-
printable or base64. For 8-bit clean transport (e.g., ESMTP,
8BITMIME, or NNTP), UTF-8 is not encoded, but UTF-16 is base64
encoded. For binary clean transports (e.g., HTTP or the upcoming
IMPP), no content-transfer-encoding is necessary.
Security considerations:
To be provided.
Interoperability considerations:
The major reason to request this registration as presence/xml,
instead of say, application/presence, is that many different
encodings may be used for presence information, e.g. based on
vCard or ASN.1. While the workgroup does neither intend to
registrate
nor to design those alternatives for the moment being, their
likelihood
in the future would create interoperability problems if this
registration was using a subtype of text or application instead.
Published specification: Not available yet.
Applications which use this media type:
This media type is primarily intended to be transported on top
of the Instant Messaging and Presence Protocol, currently
being defined by the IETF IMPP WG. However, the adoption of
MIME as the encapsulation mechanism for presence information
was partly dictated by the wish to have a transport-independent
presence information specification, so that HTTP, SMTP or other
protocols may be used.
Additional information:
Although no byte sequences can be counted on to always be present,
XML entities in ASCII-compatible charsets (including UTF-8) often
begin with hexadecimal 3C 3F 78 6D 6C ("<?xml"). For more
information, see Appendix F of [REC-XML].
File extension(s): .xml
Macintosh File Type Code(s): "TEXT"
Person & email address to contact for further information:
Christophe Vermeulen <Christophe(_dot_)Vermeulen(_at_)alcatel(_dot_)be>
Intended usage: COMMON
Author/Change controller:
To be provided
-- End Draft
Christophe.
------------------------------------------------------------------------
Statutory Disclaimer: The above is not necessarily an Alcatel position.
------------------------------------------------------------------------
_ Christophe Vermeulen
V Security Specialist, Service Deployment Project
.-----------------. Alcatel Bell, Research Division DS9 F/C0
| A L C A T E L | Fr. Wellesplein 1 - B-2018 Antwerp - Belgium
'-----------------' Phone: +32 3 240 8942 - Fax: +32 3 240 8485
mailto:Christophe(_dot_)Vermeulen(_at_)alcatel(_dot_)be
http://www.rc.bel.alcatel.be/~meulenc (Intranet)
------------------------------------------------------------------------
#-#-# Martin J. Du"rst, World Wide Web Consortium
#-#-# mailto:duerst(_at_)w3(_dot_)org http://www.w3.org