rfc3994 indication of message composition for instant messaging.txt

有关IMS SIP及Presence应用的RFC文档包

4.  Using the Status Message

   The isComposing status message can be used with either page mode or
   session mode, although session mode is a more natural fit.  In
   session mode, the status message is sent as part of the messaging
   stream.  Its usage is negotiated just like any other media type in
   that stream, with details depending on the session mode protocol.

   Sending the status messages within the session-mode messaging stream
   has at least three benefits.  First, it ensures proper ordering and
   synchronization with the actual content messages being composed.  In
   messaging systems that guarantee in-order delivery of messages, this
   approach avoids having an active indication appear at the receiver
   after the actual message has been delivered, due to message
   reordering across two delivery mechanisms.

   Secondly, end-to-end security can be applied to the messages.
   Thirdly, session negotiation mechanisms can be used to turn it on and
   off at any time, and even to negotiate its use in a single direction
   at a time.





Schulzrinne                 Standards Track                     [Page 7]

RFC 3994                      isComposing                   January 2005


   Usage with page mode is also straightforward: The status message is
   carried as the body of a page mode message.  In SIP-based IM, The
   composer MUST cease transmitting status messages if the receiver
   returned a 415 status code (Unsupported Media Type) in response to a
   MESSAGE request containing the status indication.

   The sender cannot be assured that the status message is delivered
   before the actual content being composed arrives.  However, SIP page
   mode is limited to one unacknowledged message, so out-of-order
   delivery is unlikely, albeit still possible if proxies are involved.

5.  Examples

   <?xml version="1.0" encoding="UTF-8"?>
   <isComposing xmlns="urn:ietf:params:xml:ns:im-iscomposing"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="urn:ietf:params:xml:ns:im-composing
   iscomposing.xsd">
     <state>active</state>
     <contenttype>text/plain</contenttype>
     <refresh>90</refresh>
   </isComposing>

   <?xml version="1.0" encoding="UTF-8"?>
   <isComposing xmlns="urn:ietf:params:xml:ns:im-iscomposing"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="urn:ietf:params:xml:ns:im-composing
   iscomposing.xsd">
     <state>idle</state>
     <lastactive>2003-01-27T10:43:00Z</lastactive>
     <contenttype>audio</contenttype>
   </isComposing>

6.  XML Document Format

   An isComposing document is an XML document that MUST be well formed
   and SHOULD be valid.  isComposing documents MUST be based on XML 1.0
   and MUST be encoded by using UTF-8.  This specification makes use of
   XML namespaces for identifying isComposing documents.  The namespace
   URI for elements defined for this purpose is a URN using the
   namespace identifier 'ietf'.  This URN is:

      urn:ietf:params:xml:ns:im-iscomposing








Schulzrinne                 Standards Track                     [Page 8]

RFC 3994                      isComposing                   January 2005


6.1.  XML Schema

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:im-iscomposing"
     elementFormDefault="qualified"
     attributeFormDefault="unqualified"
     xmlns:xs="http://www.w3.org/2001/XMLSchema"
     xmlns:tns="urn:ietf:params:xml:ns:im-iscomposing">
     <xs:element name="isComposing">
       <xs:complexType>
         <xs:sequence>
           <xs:element name="state" type="xs:string"/>
           <xs:element name="lastactive" type="xs:dateTime"
             minOccurs="0"/>
           <xs:element name="contenttype" type="xs:string"
             minOccurs="0"/>
           <xs:element name="refresh" type="xs:positiveInteger"
             minOccurs="0"/>
           <xs:any namespace="##other" processContents="lax"
             minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
       </xs:complexType>
     </xs:element>
   </xs:schema>

7.  Security Considerations

   The isComposing indication provides a fine-grained view of the
   activity of the entity composing and thus deserves particularly
   careful confidentiality protection so that only the intended
   recipient of the message will receive the isComposing indication.

   Since the status messages are carried by using the IM protocol
   itself, all security considerations of the underlying IM protocol
   also apply to the isComposing status messages.

   There are potential privacy issues in sending isComposing status
   messages before an actual conversation has been established between
   the communicating users.  A status message may be sent even if the
   user later abandons the message.  It is RECOMMENDED that isComposing
   indications in page mode are only sent when a message is being
   composed as a reply to an earlier message.  This document does not
   prescribe how an implementation detects whether a message is in
   response to an earlier one in page mode, but elapsed time or user
   interface behavior might be used as hints.






Schulzrinne                 Standards Track                     [Page 9]

RFC 3994                      isComposing                   January 2005


8.  IANA Considerations

8.1.  Content-Type Registration for 'application/im-iscomposing+xml'

   To: [e-mail]
   Subject: Registration of MIME media type application/
      im-iscomposing+xml
   MIME media type name: application
   MIME subtype name: im-iscomposing+xml
   Required parameters: (none)
   Optional parameters: charset; Indicates the character encoding of
      enclosed XML.  Default is UTF-8.
   Encoding considerations: Uses XML, which can employ 8-bit characters,
      depending on the character encoding used.  See RFC 3023 [4],
      section 3.2.
   Security considerations: This content type is designed to carry
      information about current user activity, which may be considered
      private information.  Appropriate precautions should be adopted to
      limit disclosure of this information.
   Interoperability considerations: This content type provides a common
      format for exchange of composition activity information.
   Published specification: RFC 3994
   Applications which use this media type: Instant messaging systems.
   Additional information: none
   Person & email address to contact for further information: Henning
      Schulzrinne, [e-mail]
   Intended usage: LIMITED USE
   Author/Change controller: This specification is a work item of the
      IETF SIMPLE working group, with the mailing list address
      [e-mail].
   Other information: This media type is a specialization of
      application/xml RFC 3023 [4], and many of the considerations
      described there also apply to application/im-iscomposing+xml.


















Schulzrinne                 Standards Track                    [Page 10]

RFC 3994                      isComposing                   January 2005


8.2.  URN Sub-Namespace Registration for
      'urn:ietf:params:xml:ns:im-iscomposing'

   URI: urn:ietf:params:xml:ns:im-iscomposing
   Description: This is the XML namespace for XML elements defined by
      RFC 3994 to describe composition activity by an instant messaging
      client using the application/im-iscomposing+xml content type.
   Registrant Contact: IETF, SIMPLE working group, [e-mail],
      Henning Schulzrinne, [e-mail]
   XML:

    BEGIN
      <?xml version="1.0"?>
      <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
      "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
      <html xmlns="http://www.w3.org/1999/xhtml">
      <head>
           <meta http-equiv="content-type"
           content="text/html;charset=iso-8859-1"/>
           <title>Is-composing Indication for Instant Messaging</title>
      </head>
      <body>
          <h1>Namespace for SIMPLE iscomposing extension</h1>
          <h2>urn:ietf:params:xml:ns:im-composing</h2>
          <p>See <a href="[URL of published RFC]">RFC3994</a>.</p>
       </body>
       </html>
      END

8.3.  Schema Registration

   This section registers a new XML schema per the procedures in [5].

   URI: urn:ietf:params:xml:schema:im-composing
   Registrant Contact: IETF, SIMPLE working group, ([e-mail]),
      Henning Schulzrinne ([e-mail]).

   The XML for this schema can be found as the sole content of Section
   6.1.

9.  Acknowledgements

   Ben Campbell, Miguel Garcia, Scott Hollenbeck, Christian Jansson,
   Cullen Jennings, Hisham Khartabil, Allison Mankin, Aki Niemi,
   Jonathan Rosenberg, and Xiaotao Wu provided helpful comments.






Schulzrinne                 Standards Track                    [Page 11]

RFC 3994                      isComposing                   January 2005


10.  References

10.1.  Normative References

   [1]  Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and
        Instant Messaging", RFC 2778, February 2000.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [3]  Klyne, G. and D. Atkins, "Common Presence and Instant Messaging
        (CPIM): Message Format", RFC 3862, August 2004.

   [4]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC
        3023, January 2001.

   [5]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
        2004.

10.2.  Informative References

   [6]  Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
        J. Peterson, "Presence Information Data Format (PIDF)", RFC
        3863, August 2004.

   [7]  Rosenberg, J., "Advanced Instant Messaging Requirements for the
        Session Initiation Protocol  (SIP)", Work in Progress, February
        2004.

Author's Address

   Henning Schulzrinne
   Columbia University
   Department of Computer Science
   450 Computer Science Building
   New York, NY  10027
   US

   Phone: [phone]
   EMail: [e-mail]
   URI:   http://www.cs.columbia.edu/~hgs










Schulzrinne                 Standards Track                    [Page 12]

RFC 3994                      isComposing                   January 2005


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   [e-mail].

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Schulzrinne                 Standards Track                    [Page 13]