One document matched: draft-camarillo-sip-accept-disposition-00.txt

SIP Working Group                                           G. Camarillo
Internet-Draft                                                  Ericsson
Expires: June 2, 2005                                   December 2, 2004


 The Session Initiation Protocol (SIP) Accept-Disposition Header Field
             draft-camarillo-sip-accept-disposition-00.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 2, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document defines the SIP Accept-Disposition header field.  User
   agents use this header field to indicate the disposition types they
   support.








Camarillo                 Expires June 2, 2005                  [Page 1]

Internet-Draft      Accept-Disposition Header Field        December 2004


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.   The Accept-Disposition Header Field  . . . . . . . . . . . . . 4
   4.   User Agent Behavior  . . . . . . . . . . . . . . . . . . . . . 4
   5.   Security Considerations  . . . . . . . . . . . . . . . . . . . 5
   6.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 5
   7.   Normative References . . . . . . . . . . . . . . . . . . . . . 5
        Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
        Intellectual Property and Copyright Statements . . . . . . . . 7








































Camarillo                 Expires June 2, 2005                  [Page 2]

Internet-Draft      Accept-Disposition Header Field        December 2004


1.  Introduction

   SIP [5] messages consist of an initial line (request line in requests
   and status line in responses) a set of header fields and an optional
   message body.  The message body of a SIP message can be divided into
   various body parts and is encoded using the MIME (Multipurpose
   Internet Mail Extensions) [1] format.  Body parts are described using
   header fields such as Content-Disposition, Content-Encoding, and
   Content-Type, which provide information on the contents of a
   particular body part.

   In particular, the Content-Disposition header field, defined in RFC
   2183 [3] and extended by RFC 3261 [5], describes how to handle an
   individual body part.  Examples of disposition types used in SIP in
   the Content-Disposition header field are 'session' and 'render'.

   RFC 3204 [4] defines the 'handling' parameter for the
   Content-Disposition header field.  From Section 6 of RFC 3204:

      "This document also defines a Content Disposition parameter,
      "handling".  The handling parameter, handling-parm, describes how
      the UAS should react if it receives a message body whose content
      type or disposition type it does not understand.  If the parameter
      has the value "optional", the UAS MUST ignore the message body; if
      it has the value "required", the UAS MUST return 415 (Unsupported
      Media Type).  If the handling parameter is missing, the value
      "required" is to be assumed."

   RFC 3204 identifies two situations where a UAS (User Agent Server)
   needs to reject a request with a body part whose handling is
   required:

   1.  if it has an unknown content type.
   2.  if it has an unknown disposition type.

   If the UAS did not understand the content type of the body part, it
   can add a Accept header field to its 415 (Unsupported Media Type)
   response listing the content types that the UAS does understand.
   Nevertheless, there is no way for a UAS that does not understand the
   disposition type of a body part to inform the UAC (User Agent Client)
   about the disposition types that are understood by the UAS.

   This document defines the Accept-Disposition header field, whose
   semantics and associated protocol behavior is similar to those of the
   Accept header field, but applies to disposition types instead of to
   content types.





Camarillo                 Expires June 2, 2005                  [Page 3]

Internet-Draft      Accept-Disposition Header Field        December 2004


      Note that the same content type can be associated to different
      disposition types in different body parts.  A UAS may support a
      particular content type but only a subset of all the disposition
      types that are associated to it.

2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119 [2] and indicate requirement levels for
   compliant implementations.

3.  The Accept-Disposition Header Field

   The Accept-Disposition header field can appear in requests and in
   responses.  When it appears in a request, this header field contains
   the disposition types supported by the UAC.  When it appears in a
   response, this header field contains the disposition types supported
   by the UAS.  The following is the ABNF (augmented Backus-Naur Form)
   for the Accept-Disposition header field:

    Accept-Disposition = "Accept-Disposition" HCOLON
                         [ disposition-type *(COMMA disposition-type) ]
    disposition-type   = disp-type *( SEMI disp-param )

   Section 25.1 of RFC 3261 provides the ABNF for 'disp-type' and
   'disp-param'.  The IANA registers values for these parameters under
   the registry for Mail Content Disposition Values and Parameters.

   An empty Accept-Disposition header field means that no disposition
   types are acceptable.

   The following is an example of an Accept-Disposition header field:

    Accept-Disposition: render, session


4.  User Agent Behavior

   UACs and UASs MAY add an Accept-Disposition header field to their
   requests and responses to inform the other end of the disposition
   types they support.

   UASs generating a 415 (Unsupported Media Type) because a body whose
   handling was required and had an unknown disposition type MUST return
   a list of acceptable content types using the Accept-Disposition
   header field.



Camarillo                 Expires June 2, 2005                  [Page 4]

Internet-Draft      Accept-Disposition Header Field        December 2004


   A UAC that receives a 415 (Unsupported Media Type) response with an
   Accept-Disposition header field SHOULD retry sending the request only
   using disposition types listed in the Accept-Disposition header
   field.

5.  Security Considerations

   Attackers may attempt to add or remove Accept-Disposition header
   fields, or modify their contents.  UAs receiving a request or a
   response modified in such a way by an attacker may be fooled to
   believe that the other end does not support a particular disposition
   type.  In this case, the UA would refrain from using a service that
   is actually available.  Receivers of such messages may also be fooled
   to believe that the other end supports a disposition type that is not
   really supported.  In this case, the UA would attempt to use a server
   that is not available and therefore will fail, wasting resources
   unnecessary.

   It is therefore RECOMMENDED that integrity protection be applied to
   the contents of the Accept-Disposition header field.  RFC 3261
   describes how to integrity-protect header fields using S/MIME.

6.  IANA Considerations

   This document defines a new SIP header field: Accept-Disposition.
   This header field needs to be registered by the IANA in the SIP
   Parameters registry under the Header Fields subregistry.

7  Normative References

   [1]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part One: Format of Internet Message Bodies",
        RFC 2045, November 1996.

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

   [3]  Troost, R., Dorner, S. and K. Moore, "Communicating Presentation
        Information in Internet Messages: The Content-Disposition Header
        Field", RFC 2183, August 1997.

   [4]  Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,
        Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG
        Objects", RFC 3204, December 2001.

   [5]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.



Camarillo                 Expires June 2, 2005                  [Page 5]

Internet-Draft      Accept-Disposition Header Field        December 2004


Author's Address

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   EMail: Gonzalo.Camarillo@ericsson.com










































Camarillo                 Expires June 2, 2005                  [Page 6]

Internet-Draft      Accept-Disposition Header Field        December 2004


Intellectual Property Statement

   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 procedures with respect to rights in RFC 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-ipr@ietf.org.


Disclaimer of Validity

   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.


Copyright Statement

   Copyright (C) The Internet Society (2004).  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.


Acknowledgment

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




Camarillo                 Expires June 2, 2005                  [Page 7]