[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Internet Engineering Task Force                    Individual Submission
Internet Draft                                        Lennox/Schulzrinne
draft-lennox-sip-reg-payload-01.txt                  Columbia University
October 31, 2000
Expires: April 2001


     Transporting User Control Information in SIP REGISTER Payloads

STATUS OF THIS MEMO

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.


Abstract

   Several newly developed languages and interfaces, such as the CPL and
   SIP CGI, allow users or administrators to specify how a SIP proxy and
   redirect server should process calls. This document defines how SIP
   REGISTER requests and responses can be used to transport scripts
   between user agents and SIP proxy and redirect servers.



1 Introduction

   Several newly developed languages and interfaces, such as the CPL [1]
   and SIP CGI [2] allow users or administrators to specify how Internet
   telephony servers should process calls. Scripts typically can be
   created on a client, but executed on an Internet telephony server.




Lennox/Schulzrinne                                            [Page 1]


Internet Draft                Reg-Payload               October 31, 2000


   There therefore needs to be a method of transporting these scripts
   from a client to a server, and of retrieving them from the server so
   the client can know the current status or modify the script. This
   method should integrate cleanly with the existing infrastructure of
   Internet telephony, without requiring significant additional protocol
   traffic or complexity in either a client or a server.

   This document defines how the payload of SIP [3] REGISTER messages,
   and their responses, can be used to transport these scripts to SIP
   registration servers alongside the user's registration.  Since
   clients typically will need to register anyway, and servers will need
   to have registrars to process the clients' registrations, this
   technique does not impose much additional overhead on servers and
   clients.

   This technique is not appropriate for all environments -- most
   obviously, it is not useful for H.323 [4] servers -- and we do not
   anticipate that it will be the only such transport mechanism
   developed.  Other protocols considered have included transporting
   scripts over LDAP [5], ACAP [6], or HTTP file upload [7], or
   transport mechanisms developed from scratch.

   The advantages of this technique, over these other possible methods
   for transfering scripts to a registration server, are twofold. First
   of all, a SIP client already needs to know the registrar and
   addresses to use in order to register a Contact location. Re-using
   this registration infrastructure makes it trivial to know the
   location to which a script should be sent. Other methods would
   require some correlation mechanism, or additional configuration
   options -- a client would need to be told what HTTP server (for
   example) to use, in addition to knowing its SIP registrar.

   Additionally, using this mechanism small SIP end systems can send and
   retrieve scripts without needing to implement additional protocols.
   Small embedded end systems are common for SIP; whereas parallel
   protocols would impose significant additional complexity in these
   devices, the mechanism described in this document requires very
   little of these devices over and above the base SIP specification.

2 Conventions Of This Document

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [8] and
   indicate requirement levels for compliant implementations of SIP
   register payload script uploading.





Lennox/Schulzrinne                                            [Page 2]


Internet Draft                Reg-Payload               October 31, 2000


        Some paragraphs are indented, like this; they give
        motivations of design choices, or questions for future
        discussion in the development of the specification. They
        are not normative to the specification of the protocol.

3 Header Field Definitions

   Script uploading borrows a number of header fields from HTTP and
   related MIME protocols. This section defines these extended headers.

3.1 Content-Disposition

   The Content-Disposition header field is defined in RFC 2183 [9]. It
   has also been added to SIP in the work-in-progress revised SIP
   specification "2543bis" [10]. In REGISTER requests or responses, this
   header field is used to describe the intended purpose of a message
   body. The grammar of this header field is as follows:



        Content-Disposition      =  "Content-Disposition" ":"
                                    disposition-type *( ";" disposition-param )
        disposition-type         =  "script" | "sip-cgi" | token
        disposition-param        =  action-param
                                 |  modification-date-param
                                 |  generic-param
        action-param             =  "action" "=" action-value
        action-value             =  "store" | "remove" | token
        modification-date-param  =  "modification-date" "=" quoted-date-time
        quoted-date-time         =  <"> SIP-date <">


   The grammar symbols "token" and "generic-param" are defined in RFC
   2543 [3].

   The Content-Disposition header field serves to describe the purpose
   of the message body. The disposition type describes the purpose of
   the material contained in the body of the message. Currently, two
   disposition types are defined. The type "script" indicates a CPL
   script or a similar scripting environment whose use in a SIP server
   can be uniquely determined by its media type. The type "sip-cgi"
   refers to SIP CGI scripts, which can be any media type executable on
   the server platform.  Additional types can be registered with IANA
   through the procedure defined in RFC 2183 [9].


        The Content-Type of the uploaded payload is not sufficient
        to describe the purpose of the payload to the server.  A



Lennox/Schulzrinne                                            [Page 3]


Internet Draft                Reg-Payload               October 31, 2000


        script with a given purpose could, conceivably, be of any
        of a large number of media types, particularly for SIP CGI.

   The action parameter to the header field is used when uploading
   scripts, to specify what the server should do with the script
   uploaded. If a non-zero-length script is specified, the action
   "store" MUST be given. The action "remove" MUST only be used when
   accompanied by a zero-length body.

   The modification-date parameter is used to indicate the time when the
   script was last modified. This is used for versioning, to prevent
   potential race conditions (see Sections 4 and 7).

   If multipart MIME types [11] are used to indicate several distinct
   scripts (see Section 4.2), this header field MUST be included in the
   MIME part header, not in the general SIP header.

3.2 Accept-Disposition

   The Accept-Disposition header field is used to indicate what content
   disposition types are acceptable to a client or server.



        Accept-Disposition        =  "Accept-Disposition" ":"
                                     #( (disposition-type | "*")
                                          *( ";" generic-param ) )


   The special meta-type "*" matches every content disposition type, and
   indicates that any content disposition is acceptable.

   The action and modification-date parameters are not meaningful for
   Accept-Disposition.


        The Accept-Disposition header field is not currently
        defined by any other published document as far as we know,
        but it is a natural counterpart to Content-Disposition. (In
        general, most Content-* header fields have corresponding
        Accept-* fields.)

3.3 If-Unmodified-Since

   The If-Unmodified-Since request header field is defined in section
   14.28 of the HTTP/1.1 specification, RFC 2616 [12]. It is used to
   make a request conditional. If the requested resource has not been
   modified since the time specified in this field, the server SHOULD



Lennox/Schulzrinne                                            [Page 4]


Internet Draft                Reg-Payload               October 31, 2000


   perform the requested operation as if the If-Unmodified-Since header
   field were not present.

   If the requested resource has been modified since the specified time,
   the server MUST NOT perform the requested operation, and MUST return
   412 Precondition Failed.

   Specifically, for register bodies, this header field is used to
   indicate that the client does not want the provided content to be
   stored if the corresponding content has been modified on the server
   since the given time.

   The syntax of this header field is as follows:



        If-Unmodified-Since  =  "If-Unmodified-Since" ":" SIP-date


   An example of this field is:


          If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT



   If the request normally (i.e., without the If-Unmodified-Since
   header) would result in anything other than a 2xx or 412 status, the
   If-Unmodified-Since header field SHOULD be ignored.

   If the specified date is invalid, the header field is ignored.

4 Transport Details

   This section describes the procedures by which scripts are uploaded
   to a server, and retrieved from it.

4.1 Script Upload and Removal

   To upload a script, the registration client places the script in the
   body of the SIP REGISTER request. Bodies of SIP requests are
   described in [3]. The Content-Type header field is set to the media
   type of the submitted script.  The MIME type application/cpl+xml
   designates CPL scripts.  Clients SHOULD upload SIP CGI scripts as an
   appropriate media type for the language the script is written in (for
   example, application/x-perl), or application/octet-stream if no such
   media type exists or is known. Registrars MAY perform validation on
   the media types if they know certain types of scripts cannot be



Lennox/Schulzrinne                                            [Page 5]


Internet Draft                Reg-Payload               October 31, 2000


   executed on their servers, but SHOULD be permissive about unknown or
   ambiguous media types for SIP CGI scripts.


        Which types of SIP CGI scripts can be successfully run on a
        server depends on the server's environment, including which
        scripting languages are installed on it. It is possible
        that the user has more knowledge of this environment than
        the server.

   Script uploads MUST also be accompanied by a Content-Disposition
   header field (see Section 3.1) describing the purpose of the message
   body. This header field MUST have an action parameter indicating
   whether the script is to be stored or removed, and MAY have a
   modification-date parameter giving a timestamp for the script.

   A script registrar's normal behavior is to enter the script in its
   database, as specified in section 5, associated with the user in the
   To field of the REGISTER message. However, if a zero-length script is
   submitted with the action remove, any existing script of the user's
   with the given disposition type is instead deleted from the database.


        Note that having a zero-length script, and not having any
        script, are quite distinct conditions, and both are legal.

   A script registrar MAY choose to add contents with an unknown
   disposition type and an action=store parameter to its script
   database. (In this case it SHOULD include a "*" field in Accept-
   Disposition headers that it sends -- see Section 4.2.) It MAY
   alternately reject a script with an unknown disposition type with a
   4xx response.


        We anticipate that the mechanism described in this
        specification can also be used for purposes such as users'
        speed-dial lists or device configuration files, and that
        new disposition types would be registered for these.

   To delete a script, a client sends a REGISTER message with its
   Content-Disposition header field with an the appropriate type and a
   action parameter of "remove", and a Content-Length header field of 0.
   If there is no script defined with the specified purpose, this
   message does nothing. When a script is deleted, the server SHOULD
   return to its default behavior, just as if no script had ever been
   uploaded.

   A client MAY include an If-Unmodified-Since header field (see Section



Lennox/Schulzrinne                                            [Page 6]


Internet Draft                Reg-Payload               October 31, 2000


   3.3) to indicate that the uploaded script should only be accepted if
   the script on the server has not been modified since the given date.
   This is typically used if a client has downloaded a script (see
   Section 4.2), modified it, and wishes to upload the modified script;
   the If-Unmodified-Since header field guarantees that the script has
   not in the meantime been modified by any other client.

   The server MAY perform syntactic and semantic validation on scripts
   at the time they are uploaded to the server. If the script is not
   valid, the server SHOULD return a 400-class error to the registration
   request indicating the problem. It MAY include in the body of the
   response an explanation of why the script was considered invalid, if
   the registration included an Accept header field with an appropriate
   media type for such an explanation (such as text/html or text/plain).

   When a script with the same disposition type as an existing script is
   successfully uploaded for a given user, the previous script is
   replaced in the server. Scripts with different disposition types are
   stored and deleted independently.

   How scripts interact with calls on the server is not defined by this
   document. In particular, which script applies to calls in progress at
   the time a script is added, changed or deleted is not defined by this
   document, but MAY be defined by specifications of script languages.
   However, if a current or new script affects the handling of REGISTER
   requests, the upload process SHOULD be handled entirely by the
   existing script; the new script does not take effect until the upload
   process has completed.

   The entity which executes the user's script -- i.e., a proxy or
   redirect server -- needs to have access to the uploaded scripts. This
   document does not specify how this is done; typically, the registrar
   and proxy server are co-located. There normally will be a way for a
   registrar to pass information to an appropriate proxy server; normal
   SIP information such as registered Contact locations needs to be
   passed in order for a registrar to be useful.

   Though the storage of scripts with different disposition types is
   independent, a server MAY choose not to execute some scripts if
   scripts with another disposition are present, for instance only
   executing one of a CPL and SIP CGI script.

   If a script upload fails for any reason (including a validation
   failure, or an unsatisfied If-Unmodified-Since header), the script
   server MUST NOT perform any other actions associated with a
   successful REGISTER request, such as entering Contact headers in the
   registration database.




Lennox/Schulzrinne                                            [Page 7]


Internet Draft                Reg-Payload               October 31, 2000


   A client MAY also include in the upload request an Accept-Disposition
   header field listing disposition types it wants to receive in its
   response. (See Section 4.2.)

4.2 Server Response

   In a successful response to any REGISTER request, whether or not a
   script payload was included, the server SHOULD return the currently
   stored scripts in the body of the response, unless the client
   requested otherwise.

   If the request contained an Accept header, the server SHOULD NOT
   return any scripts whose media types do not match that header.
   Similarly, if the request contained an Accept-Disposition header, the
   server SHOULD NOT return scripts whose disposition types do not match
   that header.

   Empty headers are legal for both the Accept and Accept-Disposition
   headers. (Grammatically, they are "#", not "1#".) If a client does
   not want to receive any scripts in response to a registration, it
   SHOULD include an empty Accept-Disposition header field in its
   REGISTER request. Servers SHOULD correctly honor empty Accept headers
   as well, but these are less likely to be useful for clients.

   If multiple scripts are registered and match the Accept and Accept-
   Disposition headers, the server SHOULD return all of them in a
   multipart content if and only if the client included an appropriate
   multipart/* media type in its Accept header. Otherwise, the server
   MAY select any of the matching registered scripts to return.  A
   client which cannot accept a multipart media type SHOULD NOT include
   multiple Accept-Disposition headers in its request.

   Each returned script MUST have its media type specified by a
   Content-Type header, and its disposition type by a Content-
   Disposition header. The Content-Disposition header field SHOULD
   include the modification-date parameter indicating the time the
   script was modified. This header field SHOULD NOT include an action
   parameter, as the server is not requesting that the client perform
   any actions.

   The server SHOULD NOT return any registered scripts if the response
   to the registration request was an error condition.

   To inform a client of what types of scripts it supports, a server
   SHOULD include Accept and Accept-Disposition headers in any response
   to a registration, response to an OPTIONS request directed at the
   registrar request, and any response which rejected a registration on
   the grounds of an unsupported disposition or media type. A server



Lennox/Schulzrinne                                            [Page 8]


Internet Draft                Reg-Payload               October 31, 2000


   which accepts arbitrary disposition types SHOULD include the wildcard
   disposition pattern "*" in its Accept-Disposition header.


        Note: Including Accept headers in arbitrary REGISTER
        responses is against the strict wording of RFC 2543 [3],
        which says that Accept headers are only allowed in requests
        or 415 (Unsupported Media Type) responses. However, it is
        always legal to include a header field in any request or
        response, as clients which do not understand it in a given
        context simply ignore it.  The work-in-progress revised SIP
        specification [10] allows this usage.

5 Persistence Model

   Registrations in SIP are normally transient -- the data in the
   Contact header fields last only for the length of time specified in
   the registration's Expires header, and clients must refresh their
   registrations periodically.

   In contrast, scripts sent to registration servers using the method
   described in this document are persistent -- they remain in the
   server until replaced or deleted, and they do not need to be
   refreshed. Servers SHOULD therefore store uploaded scripts in non-
   volatile storage so they persist through server restarts or failures.
   Clients SHOULD only upload scripts when they are explicitly requested
   to, and SHOULD NOT transmit their scripts in every registration
   request.


        The model of standard SIP registrations is that each client
        registers itself; if a location changes or hosts die, old
        registrations naturally time out. Since a user can be
        simultaneously registered from many locations, several
        clients re-registering periodically present no conflicts.

   The model of scripts is quite different. A user only has one script
   (or at least only of a given type) at a time, so if clients
   periodically re-uploaded scripts, two clients with different
   specified scripts would cause "script flapping," as the behavior
   specified in the server changed frequently, with unpredictable and
   probably surprising behavior. Moreover, one of the most important
   purposes of scripts is to control the processing of a user's requests
   when he or she is not registered from any location; if scripts timed
   out and had to be refreshed, this goal could not be accomplished.

6 Examples




Lennox/Schulzrinne                                            [Page 9]


Internet Draft                Reg-Payload               October 31, 2000


   The first example shows a user uploading a simple call-filtering SIP
   CGI script written in Perl to his server. Note that he is
   transmitting both a contact address, which persists only for 30
   minutes, the time specified by the Expires header, and a script,
   which persists indefinitely.  This allows him subsequently to
   register new contact addresses and have his script apply equally to
   them. (See [2] for an explanation of SIP CGI as used in the script.)

   The use of Basic authorization here is for the purposes of the
   example only; in actual practice much more robust authentication
   SHOULD be used. See section 8.



   REGISTER sip:sip.example.com SIP/2.0
   From: Joe User <sip:joe@example.com>
   To: Joe User <sip:joe@example.com>
   CSeq: 18 REGISTER
   Expires: 1800
   Call-ID: 39485832@joespc.example.com
   Contact: sip:joe@joespc.example.com
   Accept: application/x-perl, application/sdp, text/html
   Accept-Disposition: sip-cgi
   Authorization: Basic am9lOnBhc3N3b3JkAFBX
   Content-Type: application/x-perl
   Content-Length: 137
   Content-Disposition: sip-cgi; action=store

   #!/usr/bin/perl
   if ($ENV{HTTP_FROM} =~ /telemarketers.com/) {
       print "SIP/2.0 603 Go away\n"
   } else {
       exit(0); # Default action
   }


   In the second example, a few minutes later, the user registers a new
   contact address, but does not change his script. In the response to
   the registration, the server reminds him of his contact addresses and
   his current script.

   His client sends this request:


   REGISTER sip:sip.example.com SIP/2.0
   From: Joe User <sip:joe@example.com>
   To: Joe User <sip:joe@example.com>
   CSeq: 19 REGISTER



Lennox/Schulzrinne                                           [Page 10]


Internet Draft                Reg-Payload               October 31, 2000


   Expires: 1800
   Call-ID: 39485832@joespc.example.com
   Contact: sip:joe@joeshome.example.com
   Accept: application/x-perl, application/sdp, text/html
   Accept-Disposition: sip-cgi
   Authorization: Basic am9lOnBhc3N3b3JkAFBX
   Content-Length: 0



   And the server replies with this response:



   SIP/2.0 200 OK
   From: Joe User <sip:joe@example.com>
   To: Joe User <sip:joe@example.com>
   CSeq: 19 REGISTER
   Contact: sip:joe@joespc.example.com
   Contact: sip:joe@joeshome.example.com
   Accept: application/cpl+xml, */*
   Accept-Disposition: script, sip-cgi
   Content-Type: application/x-perl
   Content-Disposition: sip-cgi;
       modification-date="Wed, 25 Oct 2000 21:21:54 GMT"
   Content-Length: 137

   #!/usr/bin/perl
   if ($ENV{HTTP_FROM} =~ /telemarketers.com/) {
       print "SIP/2.0 603 Go away\n"
   } else {
       exit(0); # Default action
   }


   Finally, the user decides to eliminate his script, and the server
   responds in the same manner as it would respond to an ordinary
   registration, as though no script had ever been uploaded:


   REGISTER sip:sip.example.com SIP/2.0
   From: Joe User <sip:joe@example.com>
   To: Joe User <sip:joe@example.com>
   CSeq: 20 REGISTER
   Call-ID: 39485832@joespc.example.com
   Contact: sip:joe@joeshome.example.com
   Authorization: Basic am9lOnBhc3N3b3JkAFBX
   Accept: application/x-perl, application/sdp, text/html



Lennox/Schulzrinne                                           [Page 11]


Internet Draft                Reg-Payload               October 31, 2000


   Content-Length: 0
   Content-Disposition: sip-cgi; action=remove




   SIP/2.0 200 OK
   From: Joe User <sip:joe@example.com>
   To: Joe User <sip:joe@example.com>
   CSeq: 20 REGISTER
   Contact: sip:joe@joespc.example.com
   Contact: sip:joe@joeshome.example.com
   Accept: application/cpl+xml, */*
   Accept-Disposition: script, sip-cgi
   Content-Length: 0



7 Usage Notes

   Because scripts can be long, clients which upload scripts, or which
   present an Accept header field which could cause scripts to be
   returned, SHOULD send their REGISTER messages over TCP rather than
   UDP.

   A user agent which downloads a script to allow a user to edit it, and
   then re-uploads the script once the editing is complete, SHOULD
   include a If-Unmodified-Since header field in the re-uploading
   process with a value equal to the downloaded script's modification-
   date. This guarantees that the script has not been modified by any
   other user agent since it was downloaded.

8 Security Considerations

   Scripts transported by this mechanism can control how a server
   processes private information intended for a user. Therefore, a
   server MUST reject all un-authenticated attempts to submit, alter, or
   delete a script.  It is very strongly RECOMMENDED that that the
   server require an authentication method which verifies the integrity
   of the submitted script, to prevent an attacker from replaying a
   script submission with a different script body. Examples of such
   authentication methods are Digest authentication [13] with the
   quality of protection "auth-int", and SIP's PGP authentication.
   Alternately, transport or network-layer authentication and integrity
   verification (TLS [14] or IPSec [15]) can be used between the client
   and server.

   It is also RECOMMENDED that a server authenticate and provide



Lennox/Schulzrinne                                           [Page 12]


Internet Draft                Reg-Payload               October 31, 2000


   integrity verification of the scripts it returns. PGP, transport-
   layer and network-layer authentication accomplish this as well.


        It may be possible to use Digest authentication for
        server-to-client authentication, but it is not clear how
        nonce handling would work.

9 IANA Considerations

   The process for registering new Content-Disposition values and
   parameters is given in RFC 2183 [9].

   This document defines two new Content-Disposition values, "script"
   and "sip-cgi", and one new parameter, "action", which can have the
   value "store" or "remove".

10 Changes From Earlier Versions

10.1 Changes From Draft -00

   The changebars in the Postscript and PDF versions of this document
   indicate significant changes from this version.

        o Improved wording in abstract and introduction: this is a
          specification, not a proposal. It also applies only to SIP.

        o Added wording to the introduction motivating the use of this
          specification rather than the other possitiblities.

        o Changed to using the Content-Disposition header, to be in line
          with rfc2543bis and HTTP. Eliminated Content-Purpose and
          Content-Action in favor of the new header.

        o Added a paragraph motivating the separation of Content-
          Disposition types from media types.

        o Added Accept-Disposition header.

        o Added If-Unmodified-Since header.

        o Separated description of header syntax from upload and
          download procedures.

        o Clarified that scripts are per-user, and associated with the
          user in the To header.

        o Clarified that the model is that proxy servers have access to



Lennox/Schulzrinne                                           [Page 13]


Internet Draft                Reg-Payload               October 31, 2000


          the registered scripts.

        o Added usage note that user agents which support download-
          edit-upload functionality should use the If-Unmodified-Since
          header to prevent race conditions.

        o Expanded upon the security considerations. Added mention of
          qop=auth-int.

10.2 Changes From IPTel Draft -00

   This document was originally published as draft-iptel-sip-reg-
   payload-00, but the consensus of the IPTel working group was that
   this should not be a work item of that group.

        o Added Content-Purpose and Content-Action headers.

        o Changed the procedure by which scripts are deleted.

        o Eliminated the pseudo-media-type application/sip-cgi, as it is
          counter to the spirit of MIME. Instead, established that SIP
          CGI scripts can be any media type.

        o Added "Conventions," "Usage Notes," and "IANA Considerations"
          sections.

        o Updated examples to use the syntax of the current version of
          SIP CGI.

        o Updated references to refer to the latest versions of all
          documents.

11 Authors' Addresses

   Jonathan Lennox
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY 10027
   USA
   electronic mail: lennox@cs.columbia.edu

   Henning Schulzrinne
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY 10027
   USA



Lennox/Schulzrinne                                           [Page 14]


Internet Draft                Reg-Payload               October 31, 2000


   electronic mail: schulzrinne@cs.columbia.edu

12 Bibliography

   [1] J. Lennox and H. Schulzrinne, "CPL: a language for user control
   of internet telephony services," Internet Draft, Internet Engineering
   Task Force, Mar.  1999.  Work in progress.

   [2] J. Lennox, J. Rosenberg, and H. Schulzrinne, "Common gateway
   interface for SIP," Internet Draft, Internet Engineering Task Force,
   June 2000.  Work in progress.

   [3] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
   session initiation protocol," Request for Comments 2543, Internet
   Engineering Task Force, Mar. 1999.

   [4] International Telecommunication Union, "Packet based multimedia
   communication systems," Recommendation H.323, Telecommunication
   Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998.

   [5] M. Wahl, T. Howes, and S. Kille, "Lightweight directory access
   protocol (v3)," Request for Comments 2251, Internet Engineering Task
   Force, Dec.  1997.

   [6] C. Newman and J. G. Myers, "ACAP -- application configuration
   access protocol," Request for Comments 2244, Internet Engineering
   Task Force, Nov.  1997.

   [7] E. Nebel and L. Masinter, "Form-based file upload in HTML,"
   Request for Comments 1867, Internet Engineering Task Force, Nov.
   1995.

   [8] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," Request for Comments 2119, Internet Engineering Task Force,
   Mar. 1997.

   [9] R. Troost, S. Dorner, and K. Moore, "Communicating presentation
   information in internet messages: The content-disposition header
   field," Request for Comments 2183, Internet Engineering Task Force,
   Aug. 1997.

   [10] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
   Session initiation protocol," Internet Draft, Internet Engineering
   Task Force, Aug. 2000.  Work in progress.

   [11] N. Freed and N. Borenstein, "Multipurpose internet mail
   extensions (MIME) part two: Media types," Request for Comments 2046,
   Internet Engineering Task Force, Nov. 1996.



Lennox/Schulzrinne                                           [Page 15]


Internet Draft                Reg-Payload               October 31, 2000


   [12] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
   Leach, and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1,"
   Request for Comments 2616, Internet Engineering Task Force, June
   1999.

   [13] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach,
   A. Luotonen, and L. Stewart, "HTTP authentication: Basic and digest
   access authentication," Request for Comments 2617, Internet
   Engineering Task Force, June 1999.

   [14] T. Dierks and C. Allen, "The TLS protocol version 1.0," Request
   for Comments 2246, Internet Engineering Task Force, Jan. 1999.

   [15] S. Kent and R. Atkinson, "Security architecture for the internet
   protocol," Request for Comments 2401, Internet Engineering Task
   Force, Nov. 1998.


   Full Copyright Statement

   Copyright (c) The Internet Society (2000). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.






Lennox/Schulzrinne                                           [Page 16]


Internet Draft                Reg-Payload               October 31, 2000


                           Table of Contents



   1          Introduction ........................................    1
   2          Conventions Of This Document ........................    2
   3          Header Field Definitions ............................    3
   3.1        Content-Disposition .................................    3
   3.2        Accept-Disposition ..................................    4
   3.3        If-Unmodified-Since .................................    4
   4          Transport Details ...................................    5
   4.1        Script Upload and Removal ...........................    5
   4.2        Server Response .....................................    8
   5          Persistence Model ...................................    9
   6          Examples ............................................    9
   7          Usage Notes .........................................   12
   8          Security Considerations .............................   12
   9          IANA Considerations .................................   13
   10         Changes From Earlier Versions .......................   13
   10.1       Changes From Draft -00 ..............................   13
   10.2       Changes From IPTel Draft -00 ........................   14
   11         Authors' Addresses ..................................   14
   12         Bibliography ........................................   15




























Lennox/Schulzrinne                                           [Page 17]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/