rfc3050.txt

最新的RFC

5.1.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 [4] and
   indicate requirement levels for compliant SIP CGI implementations.

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

5.1.3 Specifications

   Not all of the functions and features of SIP CGI are defined in the
   main part of this specification.  The following phrases are used to
   describe the features which are not specified:

         System-defined: The feature may differ between systems, but
               must be the same for different implementations using the
               same system.  A system will usually identify a class of
               operating systems.  Some systems are defined in section 6
               of this document.  New systems may be defined by new
               specifications without revision of this document.

         Implementation-defined: The behavior of the feature may vary
               from implementation to implementation, but a particular
               implementation should be consistent in its behavior.



Lennox, et al.               Informational                     [Page 12]

RFC 3050                      CGI for SIP                   January 2001


5.1.4 Terminology

   This specification uses many terms defined in the SIP/2.0
   specification [2]; however, the following terms are used here in a
   sense which may not accord with their definitions in that document,
   or with their common meaning.

         metavariable: A named parameter that carries information from
               the server to the script.  It is not necessarily a
               variable in the operating system's environment, although
               that is the most common implementation.

         script: The software which is invoked by the server via this
               interface.  It need not be a standalone program, but
               could be a dynamically-loaded or shared library, or even
               a subroutine in the server.  It may be a set of
               statements interpreted at run-time, as the term `script'
               is frequently understood, but that is not a requirement
               and within the context of this specification the term has
               the broader definition stated.

         server: The application program which invokes the script in
               order to service messages.

         message: A SIP request or response, typically either the one
               that triggered the invocation of the CGI script, or one
               that the CGI script caused to be sent.

5.2 Notational Conventions and Generic Grammar

   In this specification we use the Augmented Backus-Naur Form notation
   as described in appendix C of the SIP/2.0 specification, RFC 2543
   [2].

   The following grammatical constructs are taken from other documents;
   this table lists the appropriate sources.

        OCTET          SIP/2.0 [2] Appendix C.1
        CHAR           SIP/2.0 [2] Appendix C.1
        digit          SIP/2.0 [2] Appendix C.1
        alphanum       SIP/2.0 [2] Appendix C.1
        token          SIP/2.0 [2] Appendix C.1
        hostname       SIP/2.0 [2] Section 2
        SIP-URL        SIP/2.0 [2] Section 2
        SIP-Version    SIP/2.0 [2] Section 4.3.1
        Status-Code    SIP/2.0 [2] Section 5.1.1
        Reason-Phrase  SIP/2.0 [2] Section 5.1.1
        media-type     HTTP/1.1 [5] Section 3.7



Lennox, et al.               Informational                     [Page 13]

RFC 3050                      CGI for SIP                   January 2001


                       (via SIP/2.0 [2] Section 6.16)
        field-name     SIP/2.0 [2] Section 6.6

   Other grammatical constructs taken from outside sources are noted in
   the text.

5.3 Invoking the Script

   The script is invoked in a system-defined manner.  Unless specified
   otherwise, the file containing the script will be invoked as an
   executable program.

   Only one CGI script at a time may be outstanding for a SIP
   transaction.  If subsequently arriving responses would cause a CGI
   script to be invoked, handling of them is deferred, except for ACK,
   until CGI scripts for previous messages in the transaction terminate.
   Messages are processed in the order they are received.

5.4 The SIP CGI Script Command Line

   The server SHOULD NOT provide any command line arguments to the
   script.

        Command line arguments are used for indexed queries in HTTP
        CGI; HTTP indexed queries do not have an equivalent in SIP.

5.5 Data Input to the SIP CGI Script

   Information about a message comes from two different sources: the
   message header, and any associated content-body.  Servers MUST make
   portions of this information available to scripts.

5.5.1 Message Metadata (Metavariables)

   Each SIP CGI server implementation MUST define a mechanism to pass
   data about the message from the server to the script.  The
   metavariables containing these data are accessed by the script in a
   system-defined manner.  The representation of the characters in the
   metavariables is system-defined.

   The representation of metavariables MUST distinguish between
   undefined values (which are not present) and null values (which are
   present, but have zero length).  Null values are only allowed for
   those metavariables whose grammar permits this.







Lennox, et al.               Informational                     [Page 14]

RFC 3050                      CGI for SIP                   January 2001


        For historical reasons, HTTP CGI does not distinguish
        between null values and undefined values.  This
        specification eliminates this misfeature; null values and
        undefined values are semantically different.

   Case is not significant in the metavariable names, in that there
   cannot be two different variables whose names differ in case only.
   Here they are shown using a canonical representation of capitals plus
   underscore ("_").  The actual representation of the names is system
   defined; for a particular system the representation MAY be defined
   differently than this.

   Metavariable values MUST be considered case-sensitive except as noted
   otherwise.

   The canonical metavariables defined by this specification are:

       AUTH_TYPE
       CONTENT_LENGTH
       CONTENT_TYPE
       GATEWAY_INTERFACE
       REMOTE_ADDR
       REMOTE_HOST
       REMOTE_IDENT
       REMOTE_USER
       REGISTRATIONS
       REQUEST_METHOD
       REQUEST_TOKEN
       REQUEST_URI
       RESPONSE_STATUS
       RESPONSE_REASON
       RESPONSE_TOKEN
       SCRIPT_COOKIE
       SERVER_NAME
       SERVER_PORT
       SERVER_PROTOCOL
       SERVER_SOFTWARE

   Metavariables with names beginning with the protocol name (e.g.,
   "SIP_ACCEPT") are also canonical in their description of message
   header fields.  The number and meaning of these fields may change
   independently of this specification.  (See also section 5.5.1.5.)

   A server MAY also specify additional non-canonical metavariables.







Lennox, et al.               Informational                     [Page 15]

RFC 3050                      CGI for SIP                   January 2001


5.5.1.1 AUTH_TYPE

   If the target of the message required access authentication for
   external access, then the server MUST set the value of this variable
   from the auth-scheme token in the message's Authorization header
   field.  Otherwise it is not defined.

        AUTH_TYPE    =  "" | auth-scheme
        auth-scheme  =  "Basic" | "Digest" | "PGP" | token

   SIP access authentication schemes are described in sections 14 and 15
   of the SIP/2.0 specification [2].  The auth-scheme is not case-
   sensitive.

   Servers MUST provide this metavariable to scripts if the message
   header included an Authorization field that was authenticated.

   For the complex authentication schemes, the server SHOULD perform the
   authentication checking itself.  If the authentication failed, this
   metavariable SHOULD NOT be set.

   If several authentication credentials, with multiple schemes, are
   present in the message, this variable SHOULD be set to correspond to
   the authenticated credentials with the strongest scheme the server
   supports.  If credentials are present for several domains, the server
   SHOULD NOT perform any action on credentials from domains external to
   it.

   If both Authorization and Proxy-Authorization headers are present,
   the server SHOULD perform the authorizations based on the appropriate
   header for the context in which it is running.  For example, a server
   which is a proxy server and a registrar would use Authorization
   headers for REGISTER messages aimed at its local domains, and Proxy-
   Authorization headers for all other messages.

5.5.1.2 CONTENT_LENGTH

   This metavariable is set to the size of the message-body entity
   attached to the message, if any, in decimal number of octets.  If no
   data are attached, then this metavariable is not defined.  The syntax
   is the same as for the SIP Content-Length header field (section 6.15,
   SIP/2.0 specification [2]).

        CONTENT_LENGTH  =  "" | 1*digit

   Servers MUST provide this metavariable to scripts if the message was
   a accompanied by a content-body entity, even if the message did not
   include a Content-Length header field.



Lennox, et al.               Informational                     [Page 16]

RFC 3050                      CGI for SIP                   January 2001


5.5.1.3 CONTENT_TYPE

   If the message includes a message-body, CONTENT_TYPE is set to the
   Internet Media Type [6] of the attached entity if the type was
   provided via a Content-type field in the message header, or if the
   server can determine it in the absence of a supplied Content-type
   field.  The syntax is the same as for the SIP Content-Type header
   field.

        CONTENT_TYPE  =  "" | media-type

   The type, subtype, and parameter attribute names are not case-
   sensitive.  Parameter values MAY be case sensitive.  Media types and
   their use in SIP are described in section 6.16 of the SIP/2.0
   specification [2], and by reference in section 3.7 of the HTTP/1.1
   specification [5].

   Since in SIP the Content-Type header MUST be specified if a body is
   present, servers MUST provide this metavariable to scripts if a body
   was present in the original message, unless the "body" is actually an
   encrypted payload.

5.5.1.4 GATEWAY_INTERFACE

   This metavariable is set to the dialect of SIP CGI being used by the
   server to communicate with the script.  Syntax:

        GATEWAY_INTERFACE  =  "SIP-CGI" "/" major "." minor
        major              =  1*digit
        minor              =  1*digit

   Note that the major and minor numbers are treated as separate
   integers and hence each may be more than a single digit.  Thus SIP-
   CGI/2.4 is a lower version than SIP-CGI/2.13 which in turn is lower
   than SIP-CGI/12.3.  Leading zeros in either the major or the minor
   number MUST be ignored by scripts and SHOULD NOT be generated by
   servers.

   This document defines the 1.1 version of the SIP CGI interface
   ("SIP-CGI/1.1").

   Servers MUST provide this metavariable to scripts.

        For maximal compatibility with existing HTTP CGI libraries,
        we want to keep this as similar as possible to the syntax
        of CGI 1.1.  However, we do want it to be clear that this is
        indeed SIP CGI.  Making HTTP CGI's version identifier a
        substring of the SIP CGI identifier seemed like a



Lennox, et al.               Informational                     [Page 17]

RFC 3050                      CGI for SIP                   January 2001


        reasonable compromise. (The existing CGI libraries we
        checked do not seem to check the version.)

5.5.1.5 Protocol-Specific Metavariables