INTERNET DRAFT Shingo Fujimoto/Dave Marvit draft-fujimoto-idip-00.txt Fujitsu Labs of America, Inc. 6 Aug 1998 IDentity Infrastructure Protocol (IDIP) 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 view the entire list of current Internet-Drafts, please check the "1id- abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract The IDentity Infrastructure Protocol (IDIP) is designed to support a new class of services known as 'Identity Services'. These constitute online extensions of a person's identity leading to the formation of an 'extended individual'. IDIP supports the coordinated communications between online identities (so called IDOs) and facilitates the invocation of applications. This document presents a specification for IDIP and provides some examples. S. Fujimoto/D. Marvit [Page 1] INTERNET DRAFT IDIP 6 Aug 1998 Table of Contents 1. Introduction . . . . . . . . . . . . . . . 3 1.1. Overview of IDIP . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . 3 1.3. Definitions . . . . . . . . . . . . . . . 4 1.3.1. IDO server . . . . . . . . . . . . . . . 4 1.3.2. IDO (IDentity Object) . . . . . . . . . . . . 4 1.3.3. IDI (IDentity Infrastructure) . . . . . . . . . 4 1.3.4. IDI Control Channel. . . . . . . . . . . . . 4 1.3.5. Session . . . . . . . . . . . . . . . . 4 1.3.6. Function . . . . . . . . . . . . . . . . 5 1.3.7. ASC (Application Specific Channel) . . . . . . . 5 1.3.8. Function Enabler . . . . . . . . . . . . . 5 1.3.9. IDO Terminal . . . . . . . . . . . . . . . 5 1.4. Basic Operation . . . . . . . . . . . . . 5 2. Generic Grammar . . . . . . . . . . . . . . 6 2.1. Basic Rules . . . . . . . . . . . . . . . 6 2.2. IDIP Request . . . . . . . . . . . . . . . 7 2.3. IDIP Response . . . . . . . . . . . . . . 8 2.4. IDIP Data . . . . . . . . . . . . . . . . 8 3. IDIP Parameters . . . . . . . . . . . . . . 8 3.1. IDIP Version . . . . . . . . . . . . . . . 9 3.2. IDO-To and IDO-From . . . . . . . . . . . . 9 3.3. Content-Type . . . . . . . . . . . . . . . 10 3.4. Content-Length . . . . . . . . . . . . . . 10 3.5. Accept-Type . . . . . . . . . . . . . . . 10 3.6. IDIP-Authenticate . . . . . . . . . . . . . 10 3.6.1. Authenticate Style Parameter . . . . . . . . . 11 3.6.1a. Style Basic . . . . . . . . . . . . . . . 11 3.7. Keywords Parameter . . . . . . . . . . . . . 11 3.8. Location . . . . . . . . . . . . . . . . 11 4. IDIP Commands . . . . . . . . . . . . . . 12 4.1. START . . . . . . . . . . . . . . . . . 12 4.2. END , . . . . . . . . . . . . . . . . . 12 4.3. LIST . . . . . . . . . . . . . . . . . 12 4.4. CALL . . . . . . . . . . . . . . . . . 13 4.5. KILL . . . . . . . . . . . . . . . . . 13 4.6. ADD . . . . . . . . . . . . . . . . . . 13 4.7. DELETE . . . . . . . . . . . . . . . . . 13 4.8. PING . . . . . . . . . . . . . . . . . 14 5. Data description format for IDI function . . . . . 14 5.1. Name Property . . . . . . . . . . . . . . 14 5.2. Specification Property . . . . . . . . . . . 14 5.3. Accept Property . . . . . . . . . . . . . . 15 5.4. Keywords Property . . . . . . . . . . . . . 15 5.5. Location Property . . . . . . . . . . . . . 15 6. Media Type "application/sdp" . . . . . . . . . 15 S. Fujimoto/D. Marvit [Page 2] INTERNET DRAFT IDIP 6 Aug 1998 7. Examples . . . . . . . . . . . . . . . . 15 7.1. Simple Negotiation . . . . . . . . . . . . . 15 7.2. Identify Caller . . . . . . . . . . . . . . 17 7.3. Filtering . . . . . . . . . . . . . . . 17 7.4. Adding an IDI function . . . . . . . . . . . 18 7.5. Giving temporary access . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . 20 9. Reference . . . . . . . . . . . . . . . . 21 10. Authors' Address . . . . . . . . . . . . . 22 1. Introduction 1.1. Overview of IDIP The existence of an IDentity Infrastructure (IDI) will enable people to manage and maintain their privacy while enhancing the power and variety of services available. The IDentity Infrastructure Protocol (IDIP) is an application-layer protocol for "online presence" management that is central to IDI. Using this protocol, IDentity Objects (IDOs) can communicate and control the initiation of applications that provide various identity services and functions. For the purpose of this protocol, each "identity function" can be defined as a set of network connections. IDIP can be used to "call" both human and non-human entities. IDIP can be used to send and receive dynamically changing information about "extended individuals" that exist online and are capable of being evoked. As well IDIP can also be used to manage access to information contained in IDOs. IDIP can be used to "filter" incoming requests based on callee's preferences. 1.2. Terminology 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 [KEYWORDS] and indicate requirement levels for compliant IDIP implementations. S. Fujimoto/D. Marvit [Page 3] INTERNET DRAFT IDIP 6 Aug 1998 1.3. Definitions The IDI system consists of several components as illustrated below. +-------------+ IDI Control Channel +-------------+ +------------+ | IDO server |=====================>| IDO server |<===>|IDO Terminal| +-------------+ +-------------+ +------------+ || IDI Control Channel || IDO server control +-------------+ || (i.e. HTTP) |Func. Enabler| || +-------------+ || || Invoke App. || Invoke App. +-------------+ +-------------+ | Application |<====================>| Application | +-------------+ ASC +-------------+ (Caller) (Callee) This specification uses a number of terms to refer the components of the system. 1.3.1. IDO server An IDO server is the network component which can accept IDIP calls. IDO server will be found from an IDO Address which will be explained later. 1.3.2. IDO(IDentity Object) The IDO is a logical component that is hosted by IDO servers. IDOs can communicate using IDIP to establish "Application Specific Channels" (described below). An IDO is hosted by an IDO server. Each IDO has only one interface on the IDO server which is specified by an IDO address. 1.3.3. IDI (IDentity Infrastructure) IDI is an infrastructure to provide "Identity Services". Collectively these will provide a rich online presence while enhancing both privacy and richness of available services. 1.3.4. IDI Control Channel An IDI Control Channel is used to connect IDOs. This channel is always open and publicly accessible to accept incoming requests. 1.3.5. Session A session is a continuous time period during which two IDOs S. Fujimoto/D. Marvit [Page 4] INTERNET DRAFT IDIP 6 Aug 1998 communicate and during which the requester (also known as the "caller") has been identified as meriting authorization by the IDO receiving the request (also known as the "callee"). The request provides some form of authentication. Based upon the authentication information provided by the requester, the IDO receiving the request may allow complete access, partial access, or no access to the requester. 1.3.6. Function As described in this document, an IDI "function" is a set of network connections called the "Application Specific Channel". A function is an abstracted model of communication between caller and callee IDOs. 1.3.7. ASC (Application Specific Channel) After negotiation between IDOs, applications will communicate through Application Specific Channels (ASCs). These are established out-of-band. (Here 'out-of-band' means outside the IDO Control Channel.) Each application, or application type, will create its own Application Specific Channel. The communication between applications along ASCs is not part of the IDIP specification. 1.3.8. Function Enabler The IDO may have a "Function Enabler" component. These components have exactly same features as the IDO server. However, a Function Enabler will only accept connections from authorized IDO. A Function Enabler is the OPTIONAL component. 1.3.9. IDO Terminal An IDO may have an "IDO Terminal", which can control the IDO's behavior. One example of control and IDO's behavior is setting filtering preferences. IDO Terminal is NOT part of the IDIP specification. 1.4. Basic Operation This section explains the basic protocol functionality and operation. Callers and callees are identified by IDO addresses. When an IDO starts a negotiation with another IDO, the caller first locates the appropriate IDO server for the callee and connect to the server. Next, the caller IDO issues a "START" command to the callee IDO. This serves to specify callee IDO and to identify the caller. Then the caller and callee IDOs can exchange commands and responses until the IDIP connection is closed or until an "END" S. Fujimoto/D. Marvit [Page 5] INTERNET DRAFT IDIP 6 Aug 1998 command is issued. The caller IDO may issue a "LIST" command to request a list of functions available to the callee. The caller may also issue a "CALL" command to enable a specific IDO "function". The connection that forms a "function" MAY terminate without an IDO's control. To terminate the IDI function explicitly, the caller MAY issue a "KILL" command to the callee IDO. 2. Generic Grammar 2.1. Basic Rules The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by [US-ASCII]. OCTET = CHAR = UPALPHA = LOALPHA = ALPHA = UPALPHA | LOALPHA DIGIT = CTL = CR = LF = SP = HT = <"> = IDIP defines the octet sequence CR LF as the end-of-line marker for all protocol elements. CRLF = CR LF The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of TEXT may contain octets from character sets other than US-ASCII. S. Fujimoto/D. Marvit [Page 6] INTERNET DRAFT IDIP 6 Aug 1998 TEXT = Hexadecimal numeric characters are used in several protocol elements. HEX = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT The special characters must be in a quoted string to be used within a parameter value. word = token | quoted-string token = 1* tspecials = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | " | "/" | "[" | "]" | "?" | "=" | "{" | "}" A string of text is parsed as a single word if it is quoted using double-quote marks. quoted-string = ( <"> *(qdtext) <"> ) qdtext = and CTLs> Single-character quoting using the backslash ("\") character is not permitted in IDIP. 2.2. IDIP Request The caller IDO issues IDIP requests. An IDIP request consists of command and data parts. The command part contains a command method and a method argument. IDIP-request = IDIP-command IDIP-parameters CRLF IDIP-data IDIP-parameters = * (IDIP-parameter CRLF) IDIP-command = start-command | end-command | list-command | call-command | kill-command | add-command | delete-command | ping-command S. Fujimoto/D. Marvit [Page 7] INTERNET DRAFT IDIP 6 Aug 1998 2.3. IDIP Response The callee IDO returns IDIP response. The IDIP response consists of status and data parts. The status part contains status code and its description. IDIP-response = IDIP-status IDIP-data IDIP-status = status-line IDIP-parameters status-line = status-code SP status-description CRLF status-code = success ; 1xx | client-error ; 2xx | server-error ; 3xx | generic-error ; 4xx success = "100" ; OK client-error = "201" ; Authentication Error | "202" ; Request Denied server-error = "301" ; Invalid Callee | "302" ; Server Internal Error | "303" ; No Function Available | "304" ; Cannot Provide Acceptable Data | "305" ; Server Timeout | "306" ; IDO Moved | "307" ; Function Busy generic-error = "401" ; Unknown Error status-description = 1*TEXT 2.4. IDIP Data IDIP Data is used to send media-typed([MEDIA TYPE]) data which is required by an IDIP-request or an IDIP-response. IDIP-data = * 3. IDIP Parameters The IDIP request and response MAY contain one or more lines of IDIP parameters. IDIP-parameter = IDIP-version S. Fujimoto/D. Marvit [Page 8] INTERNET DRAFT IDIP 6 Aug 1998 | IDO-To | IDO-From | content-type | content-length | accept-type | IDIP-authenticate | keyword-parameter | location-parameter 3.1. IDIP Version IDIP uses a "." numbering scheme to indicate versions of the protocol. The protocol versioning policy allows a sender to indicate the compatibility of IDIP protocol interfaces. The number is incremented when the new feature is added. And the number is incremented when the format of a message within the protocol is changed or when some features are disabled. If the IDIP Version parameter is specified in the IDIP request, the IDO server MUST include IDIP-Version Parameter in the IDIP response. The IDIfP version described in this document is "1.0". IDIP-Version = "IDIP-Version:" SP "IDIP" "/" 1*DIGIT "." 1*DIGIT Note that the major and minor numbers should be treated as separate integers and that each may be incremented higher than a single digit. Thus, IDIP/2.4 is a lower version than IDIP/2.13, which in turn is lower than IDIP/12.3. Leading zeros should be ignored by recipients and never generated by senders. 3.2. IDO-To and IDO-From The IDO address is used to specify both caller and callee IDOs. IDO-To = "To:" SP IDO-Address IDO-From = "From:" SP IDO-Address IDO-Address = identity_name "@" host identity_name = 1 * TEXT host = Note that the host which is specified in the "host" part must respond to an IDIP request. There is no limitation for the length of an identity name. However, IDO server MUST accept at least 1024 S. Fujimoto/D. Marvit [Page 9] INTERNET DRAFT IDIP 6 Aug 1998 characters. 3.3. Content Type The content type parameter can be used to indicate the media type of data which is attached to an IDIP command or response. content-type = "Content-Type:" SP media-type IDIP uses Internet Media Types [MEDIA TYPE] in the Content-Type parameter or Accept-Type parameter to provide open and extensible data typing. media-type = type "/" subtype *( ";" parameter ) type = token subtype = token parameter = attribute "=" value attribute = token value = token | quoted-string The type, subtype, and parameter attribute names are case- insensitive. Parameter values may or may not be case-sensitive, depending on the semantics of the parameter name. 3.4. Content-Length The Content-Length parameter indicates the number of bytes in the attached data. All IDIP requests and responses MUST include a Content-Length parameter. 3.5. Accept Type The Accept-Type parameter can be used to indicate a media which are acceptable as a response to a request. This parameter may appear multiple times to indicate a list of media. accept-type = "Accept-Type:" SP media-type 3.6. IDIP Authenticate When used by the IDIP caller, the IDIP-Authenticate parameter specifies the authentication parameters. When used by the IDIP S. Fujimoto/D. Marvit [Page 10] INTERNET DRAFT IDIP 6 Aug 1998 callee, this parameter indicates which authentication parameters should be specified by the caller. IDIP-authenticate = "IDIP-Authenticate:" SP auth-options auth-options = option *(; option ) option = authenticate-style 3.6.1. Authenticate Style Option The authenticate style option indicates which authentication style will be used for authentication. Currently only "style basic" is defined. authenticate-style = "style" "=" value 3.6.1a. Style Basic This style provides 'password' authentication. The IDIP-body is used to send password data. 3.7. Keywords Parameter The caller IDO MAY include a Keywords parameter with the LIST command. The keywords are comma(',') delimited and SHOULD effect the result of the LIST command. keyword-parameter = "Keywords:" SP keywords keywords = keyword * ("," keywords) keyword = token | quoted-string 3.8. Location In the event that an IDO has changed its server location, the old location IDO server MAY generate Location parameter to show the new location of callee IDO. location-parameter = "Location:" SP location location = IDO-Address S. Fujimoto/D. Marvit [Page 11] INTERNET DRAFT IDIP 6 Aug 1998 4. IDIP Commands 4.1. START This command is used to specify which IDO to call. At the same time, the caller IDO may add authentication information to identify itself. start-command = "START" CRLF Both IDO-To and IDO-From parameter MUST be specified. IDOs SHOULD send an IDIP-authenticate parameter to prompt or to pass the authentication information in START command or response. If the session is successfully established between IDOs, status "100 OK" will be returned. If the callee IDO is invalid, status "301 Invalid Callee" will be returned. If the caller IDO is the account which is required further authentication, status "201 Authentication Error" will be returned. And if the callee IDO has changed its server location, status "306 IDO Moved" will be returned with Location parameter. 4.2. END This command is used to shut down the connection initiated by the START command. The END command declares that the specified function should shut down. It is RECOMMENDED that session are ended by issuing an END command. end-command = "END" CRLF For this command, the IDO server MUST returns "100 OK". 4.3. LIST This command returns the list of functions that are available to be called on by the callee IDO. list-command = "LIST" CRLF The caller IDO MAY use the Keywords parameter to return a list of matched IDI-function entries. If the request is successfully accepted by the IDO server, status "100 OK" will be returned. If the list of functions was empty, "303 No Function Available" will be returned. S. Fujimoto/D. Marvit [Page 12] INTERNET DRAFT IDIP 6 Aug 1998 4.4. CALL This command is used to activate a function. The response to a CALL command may contain a set of parameters relevant to the function being called. The CALL command takes one argument, a IDI function name. This IDI function name comes from a result of the LIST command. This command MAY be issued by the IDO server to the Function Enabler. call-command = "CALL" SP function-name CRLF function-name = word If the function specified is successfully invoked, status "100 OK" will be returned. If the function is not registered, "303 No Function Available" will be returned. 4.5. KILL This command is used to explicitly terminates a function which activated by the previous CALL command. If the function specified is successfully KILLed, "100 OK" will be returned. If the function is not existed, "303 No Function Available" will be returned. And if the function is not successfully KILLed, "302 Internal Error" will be returned. kill-command = "KILL" SP function-name CRLF 4.6. ADD This command is used to add an entry to the list of functions that can be returned in response to a LIST command. Only the Function Enablers can issue a ADD command. add-command = "ADD" CRLF If the function specified is successfully added, "100 OK" will be returned. If a request comes from an unauthorized IDO, status "202 Request Denied" will be returned. And if the function is not successfully added, "302 Internal Error" will be returned. 4.7. DELETE This command is used to delete an entry from the list of functions that can be returned in response to a LIST command. Only the S. Fujimoto/D. Marvit [Page 13] INTERNET DRAFT IDIP 6 Aug 1998 Function Enablers can issue a DELETE command. If the IDI function specified is successfully deleted, status "100 OK" will be returned. If the function is not existed. status "303 No Function Available" will be returned. delete-command = "DELETE" function-name CRLF 4.8. PING This command is used to determine if the specified function is available. If the IDI function specified is available, status "100 OK" will be returned. If the function still running, but is busy, "307 Function Busy" will be returned. If the function was invoked, but timed out, "305 Server Timeout" will be returned. And if the function is not successfully invoked, "302 Internal Error" will be returned. ping-command = "PING" function-name CRLF 5. Data description format for IDI function A custom data format is used to respond to a LIST command or to describe a function in a ADD command. This data format is specified as "application/x-idi-function" on the Content-Type parameter. IDI-function = "" *property "" property = name-prop ; Name Property | accept-prop ; Accept Property | spec-prop ; Specification Property | keywords-prop ; Keywords Property | location-prop ; Location Property 5.1. Name Property A Name property contains a unique string identifier used to specify an IDI function. name-prop = "" function-name "" 5.2. Specification Property A Specification property contains one of the standards commonly supported on the Internet. spec-prop = "" *( "" standard-name "" ) "" | "" standard-name "" S. Fujimoto/D. Marvit [Page 14] INTERNET DRAFT IDIP 6 Aug 1998 standard-name = token 5.3. Accept Property The Accept property contains media-types [MEDIA TYPE] will be accepted as an IDIP-data part. accept-prop = "" *( "" media-type "" ) "" | "" media-type "" 5.4. Keywords Property The Keywords property contains string keywords which will be used at Keywords parameter in a LIST command. keywords-prop = "" *( "" keyword "" ) "" | "" keyword "" 5.5. Location Property The Location property contains URL[URL] to declare function locations explicitly. A Location property MAY be specified by a Function Enabler. location-prop = "" url "" url = 6. Application Specific Channel Application Specific Channels (ASCs) will be opened by an IDO. IDO servers use the SDP[SDP] format to provide the necessary information to establish network connections associated with ASCs. 7. Examples 7.1. Simple Negotiation Alice(alice@ido.foo.com) wants to talk with Bob(bob@ido.foo.com) using "video phone". Alice's IDO(IDO-A) connects to Bob's IDO(IDO-B) and starts negotiation. They are engaging in peer-to-peer communication. [Start session from IDO-A] START IDIP-Version: IDIP/0.9 S. Fujimoto/D. Marvit [Page 15] INTERNET DRAFT IDIP 6 Aug 1998 From: alice@ido.foo.com To: bob@ido.foo.com Content-Length: 0 [from IDO-B] 100 OK IDIP-Version: IDIP/0.9 Content-Length: 0 [from IDO-A] LIST Accept-Type: application/x-idi-function Accept-Type: multipart/mixed Accept-Type: multipart/alternative keyword: video, phone Content-Length: 0 [from IDO-B] 100 OK Content-Type: application/x-idi-function Content-Length: 83 video phone h.323 [from IDO-A] CALL "video phone" Accept-Type: application/sdp Accept-Type: multipart/mixed Accept-Type: multipart/alternative Content-Length: 0 [form IDO-B] 100 OK Content-Type: application/sdp Content-Length: 60 v=0 c=IN IP4 133.164.59.101 m=application 20450 udp 0 [form IDO-A] END Content-Length: 0 S. Fujimoto/D. Marvit [Page 16] INTERNET DRAFT IDIP 6 Aug 1998 [form IDO-B] 100 OK Content-Length: 0 [End session] 7.2. Identify Caller IDO-A identifies itself. [Start session from IDO-A] START IDIP-Version: IDIP/0.9 From: alice@ido.foo.com To: bob@ido.foo.com Content-Length: 0 [from IDO-B] 201 IDIP/0.9 Authentication Error IDIP-Version: IDIP/0.9 IDIP-Authenticate: style=basic Content-Length: 0 [from IDO-A] START Version: IDIP/0.9 From: alice@ido.foo.com To: bob@ido.foo.com IDIP-Authenticate: style=basic Content-Type: application/octet-stream Content-Length: 7 (7byte data is here) [from IDO-B] 100 OK IDIP-Version: IDIP/0.9 [continue negotiation] 7.3. Filtering Bob(IDO-B) does not want to communicate via "video phone" with Charley(IDO-C), even though IDO-B has the capability of accepting a "video phone" connection. [Start session from IDO-C] START IDIP-Version: IDIP/0.9 S. Fujimoto/D. Marvit [Page 17] INTERNET DRAFT IDIP 6 Aug 1998 From: charley@ido.foo.com To: bob@ido.foo.com Content-Length: 0 [from IDO-B] 100 OK Version: IDIP/0.9 Content-Length: 0 [from IDO-C] LIST IDIP-Version: IDIP/0.9 Accept-Type: application/x-idi-function Accept-Type: multipart/mixed Accept-Type: multipart/alternative keyword: video, phone Content-Length: 0 [from IDO-B] 303 No Function Available IDIP-Version: IDIP/0.9 Content-Length: 0 [continue negotiation] 7.4. Adding an IDI function Bob(bob@ido.foo.com) wants to register an entry for a function named "ftp data receive". [After identification, from Function Enabler (FE-B)] ADD Content-TYpe: application/x-idi-function ftp data receive ftp server [from IDO-B] 100 OK Content-Length: 0 [continue ...] 7.5. Giving temporary access Alice(alice@ido.foo.com) wants to send binary data to S. Fujimoto/D. Marvit [Page 18] INTERNET DRAFT IDIP 6 Aug 1998 Bob(bob@ido.foo.com) using ftp. [After Identification, from IDO-A] LIST Accept-Type: application/x-idi-function Accept-Type: multipart/mixed Accept-Type: multipart/alternative keyword: ftp Content-Length: 0 [from IDO-B] 100 OK Content-Type: multipart/mixed; boundary="----- =_NextPart_0001303033304" Content-Length: 457 ----- =_NextPart_0001303033304 Content-Type: application/x-idi-function Content-Length: 92 ftp data receive ftp server ----- =_NextPart_0001303033304 Content-Type: application/x-idi-function Content-Length: 125 ftp data send ftp client application/sdp ----- =_NextPart_0001303033304 [from IDO-A] CALL "ftp data receive" Accept-Type: application/sdp Accept-Type: multipart/parallel Accept-Type: multipart/alternative Content-Type: application/sdp Content-Length: 0 [form IDO-B] 100 OK S. Fujimoto/D. Marvit [Page 19] INTERNET DRAFT IDIP 6 Aug 1998 Content-Type: application/sdp Content-Length: 71 v=0 u=ftp://guest1:openSesame@133.164.59.101/incoming/X080711.data [form IDO-A] END Content-Length: 0 [form IDO-B] 100 OK Content-Length: 0 [End session] After this negotiation, IDO-A has the information required to access IDO-B's ftp server(133.164.59.101), account "guest1", password "openSesame". When the CALL request was issued by IDO-A, IDO-B forwarded the request to its Function Enabler. [from IDO-B after identify itself] CALL "ftp data receive" Content-Type: application/x-idi-function Content-Length: 0 [from Function Enabler] 100 OK Content-Type: application/sdp Content-Length: 71 v=0 u=ftp://guest1:openSesame@133.164.59.101/incoming/X080711.data [ftp server on the terminal is now ready to receive data] Note that the result was also forwarded to IDO-A by IDO-B as response from IDO-A. 8. Security Considerations To prevent the caller from violating callee's privacy, an IDO server SHOULD provide some high level authentication mechanism to identify the caller. S. Fujimoto/D. Marvit [Page 20] INTERNET DRAFT IDIP 6 Aug 1998 Furthermore, some of IDI communications pass sensitive information, including password and other private information. In such cases the IDO server SHOULD use some encryption system such as TLS[TLS] or S/MIME[SMIME]. 9. References [KEYWORDS] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. [US-ASCII] US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986. [MEDIA TYPE] Postel, J., "Media Type Registration Procedure." RFC 1590, USC/ISI, March 1994. [MIME] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September 1993. [URL] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of Minnesota, December 1994. [SDP] M. Handley and V. Jacobson, "SDP: session description protocol," RFC 2327, Internet Engineering Task Force, Apr. 1998. [TLS] Tim Dierks, "The TLS protocol Version 1.0" Internet-Draft Consensus Development, Nov. 1997. [SMIME] S. Dusse, "S/MIME Version 2 Message Specification" RFC 2311, RSA Data Security, Mar. 1998 S. Fujimoto/D. Marvit [Page 21] INTERNET DRAFT IDIP 6 Aug 1998 10. Authors' Address Shingo Fujimoto Fujitsu Labs of America, Inc. 595 Lawrence Expressway Sunnyvale, CA 94086 U.S.A. Fax: +1 (408) 530 - 4515 EMail: shingo@fla.fujitsu.com Dave Marvit Fujitsu Labs of America, Inc. 595 Lawrence Expressway Sunnyvale, CA 94086 U.S.A. Fax: +1 (408) 530 - 4515 EMail: dave@marvit.org S. Fujimoto/D. Marvit [Page 22] #