[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

MIME types for presence



There is a mailing list discussing XML and MIME types:

To: ietf-xml-mime@xxxxxxx
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@xxxxxxx?body=subscribe>

I have cross-posted to that list.

Regards,   Martin.

At 19:41 1999/11/08 +0100, owner-ietf-types@xxxxxxxxxxxxxxxx wrote:

> Date: Fri, 05 Nov 1999 16:18:52 +0100
> From: Christophe Vermeulen <christophe.vermeulen@xxxxxxxxxx>

> To: ietf-types@xxxxxxxx
> CC: impp@xxxxxxxxxxx
> Subject: Registration of MIME media type presence/xml
> List-Unsubscribe: <mailto:ietf-types-request@xxxxxxxxxxxxx?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.Vermeulen@xxxxxxxxxx>
> 
> 
> 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.Vermeulen@xxxxxxxxxx
>                          http://www.rc.bel.alcatel.be/~meulenc (Intranet)
> ------------------------------------------------------------------------ 
> 
> 


#-#-#  Martin J. Du"rst, World Wide Web Consortium
#-#-#  mailto:duerst@xxxxxx   http://www.w3.org