[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                                MMUSIC WG
Internet Draft                                               Schulzrinne
ietf-mmusic-scip-00.txt                                              GMD
February 22, 1996
Expires: 8/1/96


                 Simple Conference Invitation Protocol

STATUS OF THIS MEMO

   This document is an Internet-Draft. 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''.

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this document is unlimited.


                                 ABSTRACT


         The conference invitation protocol (SCIP) is an
         application-level protocol for inviting users to
         multimedia conferences. Network users are identified by
         their universal communication identifier, usually their
         electronic mail address. SCIP offers personal mobility by
         supporting forwarding and redirection. It can reuse the
         general email infrastructure, including DNS MX records,
         mailing lists and aliases.  The protocol combines aspects
         of HTTP and SMTP and can re-use their security mechanism.
         The protocol is extensible in methods and parameters and
         is designed to allow interoperation with ITU-T T.124
         (Generic Conference Control). Extension to VCR-control
         are possible as well. The protocol supports both loose
         and tight conference styles.




Schulzrinne                                                   [Page 1]


Internet Draft                    SCIP                 February 22, 1996


1 Introduction

1.1 Purpose

   The conference invitation protocol allows users to invite other users
   as well as automatic applications to point-to-point or multicast
   conferences. It provides extensions

1.2 Requirements

   This document uses the same words as RFC 1123 for defining the
   significance of each particular requirement. These words are:

   must: This word or the adjective "required" means that the item is an
        absolute requirement of the specification.

   should: This word or the adjective "recommended" means that there may
        exist valid reasons in particular circumstances to ignore this
        item, but the full implications should be understood and the
        case carefully weighed before choosing a different course.

   may: This word or the adjective "optional" means that this item is
        truly optional. One implementation may choose to include the
        item because a particular application requires it or because it
        enhances the product, for example, another implementation may
        omit the same item.

   An implementation is not compliant if it fails to satisfy one or more
   of the must requirements for the protocols it implements. An
   implementation that satisfies all the must and all the should
   requirements is said to be "unconditionally compliant"; one that
   satisfies all the must requirements but not all the should
   requirements for its protocols is said to be "conditionally
   compliant".

1.3 Terminology

   This specification uses a number of terms to refer to the roles
   played by participants in SCIP communications. The definitions of
   client, server and proxy are similar to those used by HTTP.

   Calling party: The party initiating a conference invitation.  Note
        that the calling party does not have to be the same as the one
        creating a conference.

   Called party: The person or service that the calling party is trying
        to invite to a conference.




Schulzrinne                                                   [Page 2]


Internet Draft                    SCIP                 February 22, 1996


   Conference: A logical grouping of several sessions. A conference is
        identified by a globally unique conference identifier.

   Conference member: The union of all session members.

   Client: An application program that establishes connections for the
        purpose of sending requests. Clients may or may not interact
        directly with a human user.

   Session member: A member of a session, either an application used by
        a human or a support tool of some kind (e.g., a video recorder).

   Server: An application program that accepts connections in order to
        service requests by sending back responses. A server interacts
        with the called user agent to determine whether to accept a
        call.

   Session: A single media, identified by a common media identifier. In
        a multicast setting, each session has a single multicast
        address.

   Proxy: An intermediary program which acts as both a server and a
        client for the purpose of making requests on behalf of other
        clients.  Requests are serviced internally or by passing them,
        with possible translation, on to other servers. A proxy must
        interpret, and, if necessary, rewrite a request message before
        forwarding it.

   [calling] user agent: The client application which initiates a
        request.

   Any given program may be capable of acting both as a client and a
   server. A typical multimedia conference controller would act as a
   client to initiate calls or invite others to conferences and as a
   server to accept invitations. However, since a server should be
   reachable even if the conference controller is not running, server
   and conference controller may well be separate. The protocol between
   server and conference controller is a local matter, but SCIP itself
   may be used for implementation efficiency. In that case, the
   conference controller may well initiate a connection to the server
   after being started by the server. The issues are somewhat similar to
   the separation of MUA and MTA on a local host, with the added
   difficulty that synchronous communication is needed. (TBD: move this
   section?)

1.4 Overall Operation

   The protocol can be used to either initiate a two-party multimedia



Schulzrinne                                                   [Page 3]


Internet Draft                    SCIP                 February 22, 1996


   call, similar to a phone call, to an invidual or to invite an
   individual to a multicast conference. Except for using unicast or
   multicast network addresses in the media description, there is no
   difference in protocol operation or end system behavior. Conferences
   may take place immediately or in the future. The protocol can convey
   information about conferences that repeat a determinate or
   indeterminate number of times. The protocol can also "invite" a
   recorder to a conference and thus serve as a control mechanism for
   accessing media-on-demand services.

   The SCIP protocol is based on HTTP and employs many of its concepts,
   data types, and protocol operations. The protocol is designed so that
   it could share a single server with HTTP, although that is usually
   not desirable.

   The called party is identified by its electronic mail (RFC 822)
   address. It is also possible that the UCI differs from the (primary)
   electronic mail address, but this is not recommended. The domain
   named in the UCI should also accepts SMTP connections, but may simply
   forward them to a regular electronic mail exchange.

   The caller contacts the server, located according to Section 1.4.1,
   with a call request. The request contains information about the
   originator, subject and urgency of the call and, typically for
   conferences, the anticipated duration. For conferences, out-of-band
   contact information such as email addresses, phone numbers or URIs
   may also be offered. The call request indicates the desired media,
   together with their encoding and network parameters such as the
   unicast or multicast address, protocol type and port number.

   The callee may either accept the call, forward the call or reject the
   call. When accepting a call, the called party returns a subset of the
   media listed in the  Accept field of the request, namely those media
   it is prepared to receive. The called party must not generate any
   media types not listed in the  Accept field. If several parties are
   being invited in parallel, a second round of negotiation may be
   needed. For large-scale conferences, a separate, multicast-based
   negotiation protocol may be preferable, but has not been specified.
   When rejecting a call, the server may offer a reason or a time to
   call back at (using the  Retry-After field).

   If the called server runs on a mail exchange host, the called user
   will likely not be reachable on that host. Rather, that server will
   use a local mechanism to locate the user within the local
   environment. This local mechanism is beyond the scope of this
   specification; examples include multicast queries, user registration
   services or use of active badges. The server may also map a user name
   to a temporary IP address to address the common situation of users



Schulzrinne                                                   [Page 4]


Internet Draft                    SCIP                 February 22, 1996


   connected to the Internet by a modem. A server can operate in
   redirect or proxy mode. In redirect mode, the server returns a status
   code and header fields indicating a possible current location of the
   called party. In proxy mode, the server maintains the incoming SCIP
   connection while it establishes new client SCIP connection to the
   intended called party. It then simply forwards the response of the
   called to the caller. A caller should cache the current location of
   the called party so that it can short-circuit the lookup process for
   future calls. There is no indication of lifetime (say, via an Expires
   header), since user behavior is unpredictable.

   As in HTTP, the called server closes the connection. There is a
   keep-alive mechanism that allows the client to request that the
   server maintain the connection. This can be used for tight conference
   control and T.120 interoperation. However, it is also possible to
   request conference parameter changes even when the initial connection
   was torn down after call acceptance by establishing a new connection.

   A forwarding or name resolution may yield more than one name, for
   example, when expanding a mailbox using SMTP EXPN. The user agent
   should offer a choice of "reach first" or "reach all". In the "reach
   first" case, the caller tries each UCI in turn, only the first one
   accepts the call. In the "reach all" case, the client tries to invite
   as many as possible. It may do this either in parallel or
   sequentially. (It may be useful to describe UCIs, similar to the
   HTTP/1.1  URI field, for example, to indicate, for example, several
   departments within an organization or the language-abilities of
   different possible parties.) Note that while a response may indicate
   several UCIs, a single SCIP request can only act on a single UCI.

   In a multiprocess operating system, a single server per host will
   typically be running continuously as a priviledged process. For
   incoming calls, the server can either determine the call disposition
   automatically, based on some user-specified rules, or signal to the
   user an incoming call, e.g. through an acoustic signal or a pop-up
   window. If the called party accepts the call, the server then starts
   the necessary conferencing applications and passes the parameters
   conveyed by the call request to them.

1.4.1 Resolving Addresses

   A client implementing the SCIP protocol should follow the following
   steps in locating a server belonging to the callee address. For
   brevity, the action "check if valid server" implies attempting to
   connect to the address at the service TCP port. If the connection
   attempt succeeds, the sequence is aborted.

        o Strip the domain part from the addr-spec.



Schulzrinne                                                   [Page 5]


Internet Draft                    SCIP                 February 22, 1996


        o If a location has been cached for this UCI, check if called
         party is present there.

        o If the domain has a DNS A record, check if valid server.

        o If the domain has a DNS SRV resource record [1], check if
         valid server.

        o If the domain has a DNS MX record, check (in order of MX
         preference) if one of the records points to a valid server.

   Note that this procedure makes it possible to have a SCIP-only server
   (i.e., one not acting as an MTA) by simply adding it as an MX record,
   usually with lower priority than a true MTA. Mail delivery will
   simply skip the SCIP-only server, just as SCIP will skip any non-SCIP
   mail exchange hosts.

   If the procedure above does not yield a SCIP server or if the user
   name is not recognized by a SCIP server, a client should attempt to
   contact the mail transfer agent for the same domain using SMTP and
   expand the name using the SMTP EXPN and VRFY commands. If EXPN yields
   more than one name, the client should treat this as a group call and
   contact all list members in the manner described above. The client
   should contact list members in parallel. A client may limit the
   number of parallel connection attempts; a user agent acting a client
   may request confirmation if the number of addresses exceeds a given
   threshold.  SMTP expansion can be used to offer the service of life-
   long UCIs, without actually handling calls.

   If all attempts to contact a SCIP server fail, a user agent may
   attempt to send a MIME message to the address, with content type
   message/cip

2 Notational Conventions and Generic Grammar

2.1 Augmented BNF

   See RFC HTTP 1.1, Section 2.1.

2.2 Basic Rules

   See RFC HTTP 1.1, Section 2.2. The attribute-value bag is not used.


   phone-number    =    E123 / phrase "<" E123 ">" / E123 comment
   E123            =    "+" country-code (SPACE / "-")
                        1*(DIGIT / "A" / "B" / "C" / "D" /
                        "#" / "*" / "." / "-")



Schulzrinne                                                   [Page 6]


Internet Draft                    SCIP                 February 22, 1996


   country-code    =    1*3 DIGIT
   time            =    rfc1123-date / hex-time
   hex-time        =    *HEX ; time in seconds since 1 Jan 1900


3 Protocol Parameters

3.1 Product Tokens

   See HTTP/1.1, Section 3.8.

3.2 Universal Communication Identifiers

   SCIP defines universal communication identifiers (UCIs) as a
   generalization of mailboxes according to RFC 822. UCIs can be used
   for electronic mail or interactive communications. UCIs have the
   format of RFC 822 addr-specs, possibly with some extensions.

   TBD: Possibly affix port number (with :port) to allow user-space
   implementations and sharing of HTTP servers?

   A special form of UCI is an E.164 international telephone number,
   written as a numeric string preceded by a plus-sign, followed by the
   country code. A phone number may contain the digits 0 through 9, the
   letters A through D, the star (ASCII 0x2A) and the pound sign (ASCII
   0x23). A E.164 UCI may employ the ASCII period "." (ASCII 0x2E) or
   dash "-" (ASCII 0x2D) for grouping. These are ignored when
   processing. An application may either directly dial this telephone
   number through a local computer-telephony interface, establish a
   phone-call through a locally-configured LAN-telephony gateway or
   offer the user the number for manual dialing through an appropriate
   interface. It is the responsibility of the computer-telephony
   interface or gateway to translate the number to a number that is
   valid at the origination point of the telephone call, e.g., by
   removing the country code and prefixing the remainder with any long-
   distance access code, or dialing the appropriate international access
   code. (Note:  Implementation of the full AT modem dial commands such
   as pauses or choosing between tone and pulse dialing is not useful,
   since dialing conventions will differ from location to location.)
   E.140 telephone numbers can be easily distinguished from mailboxes by
   the presence of the leading plus sign and the absence of the at-sign.
   (TBD: Can a mailbox start with a +?)

3.3 UCIs as Uniform Resource Identifiers

   Since UCIs are meant as universal identifiers for both synchronous
   and asynchronous communications, SCIP reuses the mailto URI scheme
   (see Section XX, RFC 1738). It is suggested that the mailto URI be



Schulzrinne                                                   [Page 7]


Internet Draft                    SCIP                 February 22, 1996


   extended to encompass telephone numbers as well. The user interface
   of browsers implementing SCIP should offer the user the choice of
   either sending electronic mail or trying to establish real-time
   communication.

   Since the number of parameters and the total length of a typical
   conference description is large, it is recommended to use a http or
   ftp or similar scheme to retrieve an object of type message/scip,
   defined in Appendix A. It is also possible to use the "data" URI
   scheme [2] to convey information of type message/cip

4 SCIP Message

   SCIP headers may be folded as described in RFC 822.

5 Request

   A request from a client to a server includes, within the first line
   of that message, the method to be applied to the UCI, the identifier
   of the called party, and the protocol version in use. (Note: there is
   no need for a HTTP/0.9 backward compatible request.)


   Request-Line    =    method SP UCI SP "SCIP/1.0" CRLF


5.1 Method

6 Response

   A server returns a response message to a request.


   Response       =    Status-Line
                       *(General Header /
                       Response header)
                       CRLF
   Status-Line    =    SCIP-Version SP Status-code SP Reason-phrase CRLF


   An example:


   SCIP/1.0 302 Moved Temporarily
   Location: secretary@westwing.whitehouse.gov
   Location: security@eastwing.whitehouse.gov





Schulzrinne                                                   [Page 8]


Internet Draft                    SCIP                 February 22, 1996


7 Method Definitions

   For T.124 compatibility, additional methods will be defined in the
   future.

7.1 CALL

   Call the user identified by the  called-UCI.

7.2 CHANGE

   Change parameters of the conference.

7.3 CLOSE

   Close the conference.

8 Status Code Definitions

8.1 Informational (1xx)

   Currently, no 1xx type status codes are defined for SCIP. The HTTP
   codes 100 (Continue) and 101 (Switching Protocols) are not
   applicable.  Progress indication such as "ringing" may be useful.

8.2 Successful (2xx)

   The HTTP status codes 201 (Created), 202 (Accepted), 203 (Non-
   Authoritative Information), 204 (No Content), 205 (Reset Content),
   206 (Partial Content) are not applicable and must not be sent in
   response to a SCIP method.

8.2.1 200 OK

   The request has succeeded. The information returned with the response
   depends on the method used in the request:

   CALL The call has been accepted by the called party.

8.3 Redirection 3xx

8.3.1 301 Moved Permanently

   The user identfied by the UCI has moved permanently and any future
   calls should be to the new UCI returned in the  Location field.  If a
   user may be at several locations, several  Location fields may be
   returned, with the client then trying to contact the new locations in
   turn or in parallel. (HTTP only allows one Location field.)



Schulzrinne                                                   [Page 9]


Internet Draft                    SCIP                 February 22, 1996


8.3.2 302 Moved Temporarily

   The user identified by the UCI has moved

8.4 Caller Error 4xx

   The 4xx class of status codes is intended for cases in which the
   client (caller) seems to have erred. Status codes 400 (Bad Request),
   401 (Unauthorized), 402 (Payment Required), 403 (Forbidden), 404 (Not
   Found), 405 (Method Not Allowed), 406 (None Acceptable), 408 (Request
   Timeout), 410 (Gone) have the same interpretation as for HTTP, with
   URI replaced by UCI.

8.5 Callee Error 5xx

   The 5xx class of status codes indicates that the server is incapable
   of completing the request. The codes 500 (Internal Server Error), 501
   (Not Implemented), 502 (Bad Gateway), 503 (Service Unavailable), 504
   (Gateway timeout) are to be interpreted in the same way as in HTTP
   1.1, except that URI is to be replaced by UCI. Busy conditions, i.e.,
   where the called party indicates she does not wish to receive calls,
   or a busy signal from a telephony gateway, are indicated by status
   code 503. If known, a  Retry-After field can give an indication when
   a new call may succeed.

9 Header Field Definitions

9.1 Accept


   Accept         =    "Accept" ":" #(
                       media-range
                       [";" "ttl" "=" ttl-value]
                       [";" "addr" "=" net-address]
                       [";" "cbw" "=" bandwidth]
                       [";" "bw" "=" bandwidth]
                       [";" "key" "=" encryption-key]
                       [";" "id" "=" media-id]
                       [";" "i" "=" information]
                       [";" "tp" "=" ("rtp" / other-transport-protocol)]
                       [";" "pt" "=" payload-type]
                       [";" "dir" "=" "sendonly" / "recvonly" /
                       "hduplex" / "fduplex"]
                       )
   media-range    =    type "/" (subtype / "*")
   type           =    ("audio" / "video" / "application")
   subtype        =    (audio-enc ["." sr "." ch]) / video-enc / application)
   net-address    =    [(host / multicast-address)] [":" port]



Schulzrinne                                                  [Page 10]


Internet Draft                    SCIP                 February 22, 1996


   sr             =    <audio sampling rate>
   ch             =    <audio channel count>


   For audio and video, the media subtype designates the encoding using
   the RTP profile designations, e.g., H261, PCMU, L16, etc.. Parameters
   propagate, that is, they apply to all following media, even across
   several  Accept lines. (This follows from the HTTP convention that
   several fields with the same name are equivalent to a single field
   with comma-separated items.) TBD: There are currently no preferences
   encoded, as this makes responses difficult to handle.  (Who decides
   if the preference of the called and calling parties differ?) However,
   adding a "q" parameter like HTTP might be useful if the behavior can
   be defined.

   The response contains the subset of media that the called party can
   support, without parameters. (This is the reason that sampling rate,
   channel count and other identifying encoding parameters are part of
   the subtype rather than parameters.)

   bw: Per-sender bandwidth, in kb/s.

   cbw: Conference bandwidth, in kb/s. This is the total bandwidth for
        all senders of this media instance.

   id: Media instance identifier. The identifier is a random base-64
        string with at least 8 characters that can be used to identify
        media change requests. Different values of this field separate
        several media streams. A media stream can consist of a number of
        media types which are either only used sequentially or, if used
        in parallel and with different network associations, carry
        exactly the same information. (TBD: Should the latter be
        allowed? It is useful for having both low-bandwidth and high-
        bandwidth versions of the same material.)

   ttl: The multicast time-to-live value.

   key: Encryption key for this media type, in base-64 encoding.

   pt: RTP dynamic payload type for the encoding.

   tp: Transport protocol.

   dir: Direction of transmission, as viewed from the called part.
        Half-duplex (hduplex) and full-duplex (fduplex) permit sending
        and receiving. Half-duplex indicates that there is a mechanism
        to ensure that only one party speaks at any given time and is
        mainly useful for two-party conversations.



Schulzrinne                                                  [Page 11]


Internet Draft                    SCIP                 February 22, 1996


   Example request for a conference containing audio and video:


   CALL foo@bar.com SCIP/1.0
   Accept: audio/pcmu.16000.1;ttl=128;addr=224.2.0.1;pt=95;id=Axuay,
           audio/gsm.8000.1
   Accept: video/h261;ttl=128;addr=224.2.0.2;id=Zkd1k,
           video/jpeg;bw=128;recvonly



   The sample response shown below indicates that the called party only
   supports PCMU audio and JPEG video:


   200 OK
   Accept: audio/pcmu.16000.1
   Accept: video/jpeg



   TBD: Alternative: Identify possible encodings in response numerically
   or by identifier to simplify matching.

9.2 Accept-Language

   TBD.

9.3 Authorization

   TBD.

9.4 Call-Id

   Each call must be identified by a globally unique call identifier. If
   a user invites somebody to the same conference, it must use the same
   Call-Id it was invited with. (TBD: For T.120 interoperation, this
   field is the conference identifier, which is not guaranteed to be
   globally unique.)


   Call-Id    =    "Call-Id" ":" "<" local-id "@" addr-spec ">"


9.5 Forwarded

   The  Forwarded response header is to be used by servers to indicate
   the intermediate steps between the calling user agent and the server



Schulzrinne                                                  [Page 12]


Internet Draft                    SCIP                 February 22, 1996


   on call requests. A  Forwarded response is not inserted if
   redirection occurs. A proxy server adds a  Forwarded field in the
   response to the client when it contacts another server for call
   completion. It is analogous to the "Received" field of RFC 822 and
   the  Forwarded field of HTTP. It is intended to be used for tracing
   transport problems and avoiding request loops.


   Forwarded  ___   "Forwarded" ":" "for" FQDN
   FQDN       ___   <Fully qualified domain name>


   Multiple  Forwarded header fields are allowed and should represent
   each proxy server that has forwarded the call request. It is strongly
   recommended that proxies used as a portal through a network firewall
   do not, by default, send out information about internal hosts within
   the firewall region. This information should only be propagated if
   explicitly enabled. If not enabled, the for token and  FQDN should
   not be included in the field value, and any  Forwarded headers
   already present in the message (those added behind the firewall)
   should be removed.

9.6 From

   From = "From" ":" mailbox

   An example is


   From: Herbert Hoover <president@whitehouse.gov>



9.7 Keep-Alive

   Used in request to have server keep open the connection after the
   initial call.

9.8 Key

   This field can be used to convey an encryption key for the media
   sessions that are marked as encrypted. Naturally, the key is safe
   from eavesdroppers only if the SCIP connection is itself encrypted.

9.9 Location

   Location = "Location" ":" absoluteUCI




Schulzrinne                                                  [Page 13]


Internet Draft                    SCIP                 February 22, 1996


   An example is:


   Location: secretary@westwing.whitehouse.gov



9.10 Phone

   The  Phone field provides contact information for the person
   initiating the conference. This person may differ from the one
   issuing the conference invitation or creating the conference
   announcement. For a multicast conference, either the  Phone or Email
   field must be specified. More than one  Phone or Email field is
   allowed. The field is intended to be used as the RTCP SDES fields by
   the same name, e.g., to summon help if problems arise or to contact a
   human operator should a conference cause network problems.

   Phone = "Phone" ":" phone-number

   An example is:


   Phone: conference operator <+1.415.555.1212>
   Phone: +49.30.25499.182 (Conference Chair)



9.11 Priority


   Priority    =    "Priority" ":" ("urgent" / "high"
                    / "normal" / "low" / user-defined-priority)


   The  Priority field gives a general indication of the urgency of the
   message. This allows the user agent of a called party to forward or
   refuse calls without assistance from the user. Abuse is dealt with by
   social oppobrium.

9.12 Reach


   Reach    =    "Reach" ":" ("first" / "all")


9.13 Repeat




Schulzrinne                                                  [Page 14]


Internet Draft                    SCIP                 February 22, 1996


   The  Repeat field indicates for conferences, that the session repeats
   at some interval.

9.14 Retry-After

   The  Retry-After field indicates the earliest time another call
   attempt is likely to be successful. It has the same syntax as the
   HTTP field by the same name.

9.15 Subject

   The  Subject provides a summary of the conference topic or indicate
   the nature of the call.

9.16 Time


   Time          =    "Time" ":" start-time ["," stop-time]
   start-time    =    rfc1123-date ; time conference starts
   stop-time     =    rfc1123-date ; time conference ends


9.17 URI

   The URI header field points to additional information about the
   conference and/or the caller. There should be no more than one URI
   field.

   URI = "URI" ":" URI

   An example is:


   URI: http://www.w3.org/pub/Talks/



9.18 User-Agent

   (See HTTP 1.1, 10.43) The  User-Agent field contains information
   about the user agent originating the request. This is for statistical
   purposes, the tracing of protocol violations, and automated
   recognition of user agents for the sake of tailoring responses to
   particular user agent limitations. Although it is not required, user
   agents should include this field with the requests.  The field can
   contain multiple product tokens (see Section 3.1) and comments
   identifying the agent and any subproducts which form a significant
   part of the user agent. By convention, the product tokens are listed



Schulzrinne                                                  [Page 15]


Internet Draft                    SCIP                 February 22, 1996


   in order of their signficance for identifying the application.

   User-Agent = "User-Agent" ":" 1*(product / comment)

   Example:


   User-Agent: isc/1.2 libscip/0.9



10 Response

11 Security Considerations

   TBD.

12 Acknowledgements

   The document structure and parts of the texts were lifted from the
   HTTP/1.1 specification. The compact representation is similar to that
   used by SDP.

13 Author Address

   Henning Schulzrinne
   GMD Fokus
   Hardenbergplatz 2
   D-10623 Berlin
   Germany
   electronic mail: schulzrinne@fokus.gmd.de

A Internet Media Type message/scip

   In addition to defining the SCIP/1.0 protocol, this document serves
   as the specification for the Internet media type "message/scip". The
   following is to be registered with IANA according to RFC 1590:



   Media type name:         message
   Media subtype name:      scip
   Required parameters:     none
   Optional parameters:     version, msgtype
     version: The SCIP version number of the enclosed message (e.g.,
              "1.0").  If not present, the version can be determined from
              the first line of the body.
     msgtype: The message type - "request", "response" or "directory".



Schulzrinne                                                  [Page 16]


Internet Draft                    SCIP                 February 22, 1996


              If "directory", only the header fields of the request are
              in the body.  If not present, the type can be determined
              from the first line of the body.
   Encoding considerations: only "7bit", "8bit", or "binary" are
                            permitted.
   Security considerations: none.



B Compact Representation

   In some environments, bandwidth is at a premium and a more compact
   representation is desired. Examples of such environments include
   encoding conference information in data URIs [2] or carrying them in
   limited-bandwidth multicast directories. The compact representation
   described here should only be used in those circumstances, as it is
   harder for humans to debug and is less compatible with HTTP and SMTP
   conventions. It is anticipated that a single parser can process both
   formats without difficulty.

   The following abbreviations may be used for field names:


   Accept     M
   Email      e
   Key        k
   Phone      p
   Repeat     r
   Time       t
   Subject    i
   URI        u


   Fields not listed above are generally not used in non-interactive
   (e.g., directory or WWW) applications. In a compact representation, a
   single LF should be used as a line terminator.

C Tolerant Applications

   The line terminator for  SCIP-header fields is the sequence CRLF, as
   for HTTP. However, it is recommended that applications, when parsing
   such headers, recognize a single LF as a line terminator and ignore
   the leading CR.

D T.124 and H.245 Interoperation

   T.124 and H.245 interoperation is through gateways.




Schulzrinne                                                  [Page 17]


Internet Draft                    SCIP                 February 22, 1996


   SCIP field    T.124 parameter
   ______________________________________
   Subject       Conference Description
                 Conference ID
                 Conference Name
                 Conference Name Modifier


E Open Issues

        o Character set: ISO 8859-1 or UTF-7? The former is easily
         available on most systems, covers a large fraction of the non-
         Asian current Internet population and is HTTP compatible. UTF-7
         is probably more future-safe.

        o Terminology: Session for group of streams? (but: also
         applications); conference? (but also "invitation")

        o Name of protocol: Could be SIP (session invitation protocol),
         but invitations are to conferences, which consist of (audio,
         video, (configuration). CICP,

        o Methods for VCR-style control.

        o Operation with telephony gateways.

        o Charging mechanisms for media-on-demand - reuse HTTP
         extensions?

F Bibliography

   [1] A. Gulbrandsen and P. Vixie, "A DNS RR for specifying the
   location of services," Internet Draft, Internet Engineering Task
   Force, Jan. 1996.  Work in progress.

   [2] L. Masinter, "Data: URL scheme," Internet Draft, Internet
   Engineering Task Force, Feb. 1996.  Work in progress.














Schulzrinne                                                  [Page 18]


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