ietf-xml-mime
[Top] [All Lists]

MIME types for presence

1999-11-08 21:36:50
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

<Prev in Thread] Current Thread [Next in Thread>
  • MIME types for presence, Martin J. Duerst <=