INTERNET DRAFT S. Fujimoto draft-fujimoto-idip-01.txt A. Iwakawa D. Marvit Fujitsu Labs of America, Inc. Expire: 30 Sep 1999 30 Mar 1999 IDentity Infrastructure Protocol (IDIP) Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and will only exist as 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (1999). 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, et. al. [Page 1]
INTERNET DRAFT IDIP 30 Mar 1998 Table of Contents 1. Introduction ....................................................3 1.1. Overview of IDIP .............................................3 1.2. Requirements .................................................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 ...................................................5 1.3.6. Function Provider .........................................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 ..............................................6 2. Generic Grammar .................................................6 2.1. Basic Rules ..................................................6 2.2. IDIP Request .................................................8 2.3. IDIP Response ................................................8 2.4. IDIP Data ....................................................9 3. IDIP Parameters .................................................9 3.1. IDIP Version .................................................9 3.2. IDO-To and IDO-From .........................................10 3.3. Content-Type ................................................10 3.4. Content-Length ..............................................11 3.5. Accept-Type .................................................11 3.6. IDIP-Authenticate ...........................................11 3.6.1. Authenticate Style Parameter .............................11 3.6.1a. Style Basic .............................................12 3.7. Keywords Parameter ..........................................12 3.8. Location ....................................................12 4. Status Code Definition .........................................12 4.1. Success .....................................................12 4.1.1. 100 OK ...................................................12 4.2. Informational ...............................................12 4.2.1. 201 Continue .............................................13 4.2.2. 202 IDO Forwarded ........................................13 4.2.3. 203 IDO Moved ............................................13 4.2.4. 204 Unknown Caller .......................................13 4.2.5. 205 Identified As Anonymous ..............................13 4.3. Rejected Errors .............................................13 4.3.1. 301 Invalid IDO Called ...................................14 4.3.2. 302 Authentication Failed ................................14 4.3.3. 303 Permission Denied ....................................14 4.3.4. 304 Change Funciton Parameter ............................14 4.4. Unexpected Errors ...........................................14 4.4.1. 401 IDO Internal Error ...................................14 S. Fujimoto, et. al. [Page 2]
INTERNET DRAFT IDIP 30 Mar 1998 4.4.2. 402 Function Not Available ...............................14 4.4.3. 403 Corrupted Data .......................................14 5. IDIP Commands ..................................................15 5.1. START ......................................................15 5.2. END ........................................................15 5.3. LIST .......................................................15 5.4. CALL .......................................................16 5.5. KILL .......................................................16 5.6. ADD ........................................................16 5.7. DELETE .....................................................16 5.8. DISABLE ....................................................17 5.9. ENABLE .....................................................17 5.10. LOGIN ......................................................17 5.11. LOGOUT .....................................................17 5.12. REDIRECT ...................................................18 6. Data description format for IDI function .......................18 6.5. Function ID Property .........................................18 6.2. Description Property .........................................18 6.3. Specification Property .......................................18 6.4. Keyword Property .............................................18 6.5. Parameter Property ...........................................19 7. Examples .......................................................20 7.1. Simple Negotiation ..........................................20 7.2. Identify Caller .............................................22 7.3. Blocking Inquery ............................................23 7.4. Adding an IDI function ......................................24 7.5. Giving temporary access .....................................24 7.5. Asking Redirection ..........................................27 8. Security Considerations ........................................28 9. Reference ......................................................28 10. Authors' Address ..............................................29 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. S. Fujimoto, et. al. [Page 3]
INTERNET DRAFT IDIP 30 Mar 1998 IDIP can be used to send and receive dynamically changing information about "extended individuals" through their IDOs. IDIP can also be used to block or allow the access to the information contained in IDOs based on the rule which defined by callee entity. 1.2. Requirements 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. 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 || +--------+ +-------------+ +-------------+ /| |Func. Enabler| <-User Requests |Func. Enabler| | +-------------+ +-------------+ User || Invoke App. Invoke App.|| Requests +-------------+ +-------------+ | Function | | Function | | Provider |<====================>| Provider | +-------------+ Application +-------------+ (Caller) Specific (Callee) Channel 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 explained below. 1.3.2. IDO(IDentity Object) An IDO is a logical component that is hosted by an IDO server. 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. S. Fujimoto, et. al. [Page 4]
INTERNET DRAFT IDIP 30 Mar 1998 1.3.3. IDI (IDentity Infrastructure) IDI(IDentity Infrastructure) 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 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 Provider As described in this document, an IDI Function is defined as a set of network connections called the "Application Specific Channel(ASC)". The Function Provider is a component which implements IDI function with controling applications. These applications actually provide ASCs. A Function Provider provides abstracted interface for parameter negotiation, invoking application, shutdown the application. 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 an OPTIONAL component. 1.3.9. IDO Terminal S. Fujimoto, et. al. [Page 5]
INTERNET DRAFT IDIP 30 Mar 1998 An IDO may have an "IDO Terminal", which can control the IDO's behavior. One example of controling 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 connects to the server. Next, the caller IDO issues a "START" command to the callee IDO. This serves to specify the 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" 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 activate 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 = <any 8-bit sequence of data> CHAR = <any US-ASCII character (octets 0 - 127)> UPALPHA = <any US-ASCII uppercase letter "A".."Z"> LOALPHA = <any US-ASCII lowercase letter "a".."z"> ALPHA = UPALPHA | LOALPHA DIGIT = <any US-ASCII digit "0".."9"> CTL = <any US-ASCII control character (octets 0 - 31) and DEL (127)> CR = <US-ASCII CR, carriage return (13)> S. Fujimoto, et. al. [Page 6]
INTERNET DRAFT IDIP 30 Mar 1998 LF = <US-ASCII LF, linefeed (10)> SP = <US-ASCII SP, space (32)> HT = <US-ASCII HT, horizontal-tab (9)> <"> = <US-ASCII double-quote mark (34)> IDIP defines the octet sequence CR LF as the end-of-line marker for all protocol elements. CRLF = CR LF IDIP headers can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP. LWS = [CRLF] 1*( SP | HT ) 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. TEXT = <any OCTET except CTLs> 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*<any CHAR except CTLs or tspecials> tspecials = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | " | "/" | "[" | "]" | "?" | "=" | "{" | "}" A string of text is parsed as a single word if it is quoted using double-quote marks. quoted-string = ( <"> *(qdtext) <"> ) S. Fujimoto, et. al. [Page 7]
INTERNET DRAFT IDIP 30 Mar 1998 qdtext = <any TEXT except <">> 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 | disable-command | enable-command | login-command | logout-command | redirect-command 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 Each Status-Code is defined in later section, including a description of which method(s) it can follow and any metainformation required in the response. status-line = status-code SP status-description CRLF S. Fujimoto, et. al. [Page 8]
INTERNET DRAFT IDIP 30 Mar 1998 status-code = successful ; 1XX | informational ; 2XX | rejected-error ; 3XX | unexpected-eror ; 4XX successful = "100" ; Success informational = "201" ; Continue | "202" ; Forwarded | "203" ; Moved | "204" ; Unknown Caller | "205" ; Identified As Anonymous rejected-error = "301" ; Invalid IDO Called | "302" ; Authentication Failed | "303" ; Permission Denied | "304" ; Change Function Parameter unexpected-error = "401" ; IDO Internal Error | "402" ; Function Not Avaiable | "403" ; Corrupted Data 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 = * <any OCTET> 3. IDIP Parameters The IDIP request and response MAY contain one or more lines of IDIP parameters. IDIP-parameter = IDIP-version | IDO-To | IDO-From | content-type | content-length | accept-type | IDIP-authenticate | keyword-parameter | location-parameter 3.1. IDIP Version S. Fujimoto, et. al. [Page 9]
INTERNET DRAFT IDIP 30 Mar 1998 IDIP uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol. The protocol versioning policy allows a sender to indicate the compatibility of IDIP protocol interfaces. The <minor> number is incremented when the new feature is added. And the <major> number is incremented when a 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 IDIP 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 IDI-Address IDO-From = "From:" SP IDI-Address IDI-Address = identity_name "@" host identity_name = 1 * <CHAR except "@"> host = <A legal Internet host domain name or IP address (in dotted-decimal form), as defined by Section 2.1 of RFC 1123> 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 IDI- Address However, an IDO server MUST accept at least 1024 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. S. Fujimoto, et. al. [Page 10]
INTERNET DRAFT IDIP 30 Mar 1998 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 callee, this parameter indicates which authentication parameters should be specified by the caller. IDIP-authenticate = "IDIP-Authenticate:" SP auth-info auth-info = authenticate-style ";" authenticate-data authenticate-data = base64data * ("," base64data) 3.6.1. Authenticate Style The authenticate style indicates which authentication style will be S. Fujimoto, et. al. [Page 11]
INTERNET DRAFT IDIP 30 Mar 1998 used for authentication. In this document, 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 = word * ("," keywords) 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 4. Status Code Definition 4.1. Success This class of status code indicates that the caller IDO's request was successfully received, understood, and accepted. 4.1.1. 100 OK The request has succeeded. 4.2. Informational This class of status code indicates that the caller IDO's request was successfully received, understood, but is pending acceptance status. S. Fujimoto, et. al. [Page 12]
INTERNET DRAFT IDIP 30 Mar 1998 4.2.1. 201 Continue The caller IDO may continue with its request. This interim response is used to inform the caller IDO that the initial part of the request has been received and has not yet been rejected by the server. The caller IDO SHOULD contine by sending the remainder of the request or, if the request has already been completed, ignore this response. The callee IDO MUST send a final response after the request has been completed. 4.2.2. 202 IDO Forwarded The server which hosts the IDO was temporary changed. The temporary server's location is provided in the Location parameter. The caller IDO SHOULD finish the current connection, and re-connect with a new server. 4.2.3. 203 IDO Moved The server which hosts IDO was changed. The new server's location is provided in the Location parameter. The caller IDO SHOULD finish the current connection, and re-connect with a new server. 4.2.4. 204 Unknown Caller The callee IDO can not identify the caller as the specified IDI- Address in the IDO-From parameter. The caller MAY retry to issue the START command with a different IDO-From parameter. 4.2.5. 205 Identified As Anonymous If the callee IDO accepts anonymous call, all of the unknown callers will be regarded as anonymous entities. The caller MAY retry to issue a START command with a different IDO-From parameter. 4.3. Rejected Errors This class of status code indicates that the caller IDO's request was successfully received and understood, but rejected. 4.3.1. 301 Invalid IDO Called The IDI-address was invalid for the server. The caller MAY retry to issue a START command with a different IDO-To parameter. 4.3.2. 302 Authentication Failed Provided authentication information was invalid. The callee SHOULD S. Fujimoto, et. al. [Page 13]
INTERNET DRAFT IDIP 30 Mar 1998 send correct information in the next request. 4.3.3. 303 Permission Denied The request was rejected, because of the callee has not the right to do. The callee MAY issue END and START commands to get the privillege rights. 4.3.4. 304 Change Function Parameter Some of the parameters specified in the CALL request were rejected, and a change is required. The caller SHOULD retry the same request with differnent parameters. 4.4. Unexpected Errors This class of status code indicates that the request was not accepted because of an unexpected event. 4.4.1. 401 IDO Internal Error The request was not processed as expected. The callee MAY retry the same request. 4.4.2. 402 Function Not Available The IDI function specified could not accept the request. The callee SHOULD issue the LIST command to get updated list of IDO functions. 4.4.3. 403 Corrupted Data The IDIP data part in the request was corrupted. The callee MUST resend the request to complete a request. S. Fujimoto, et. al. [Page 14]
INTERNET DRAFT IDIP 30 Mar 1998 5. IDIP Commands 5.1. START This command is used to specify which IDO to call. At the same time, the caller IDO MAY add authentication information. start-command = "START" CRLF Both IDO-To and IDO-From parameters MUST be specified. The caller IDO SHOULD send the request with an IDIP-authenticate parameter to identify as the specific caller. On the other hand, the callee IDO MUST return "302 Authentication Failed" error, in case of the caller was required to provide authentication information. If the session is successfully established between IDOs, status "100 OK" will be returned. If the callee IDO is invalid, status "301 Invalid IDO Called" will be returned. If the caller IDO is the account which is required further authentication, status "302 Authentication Failed" " will be returned. And if the callee IDO has changed its server location, status "202 IDO Forwarded" or "203 IDO Moved" will be returned with Location parameter. 5.2. END This command is used to shut down the connection initiated by the START command. 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". 5.3. LIST This command returns the list of functions that are available to be called on by the callee IDO. These functions are described in the "application/x-idi-function" data structure. 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, "402 Function Not Available" will be returned. S. Fujimoto, et. al. [Page 15]
INTERNET DRAFT IDIP 30 Mar 1998 5.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 caller IDO MUST send the request with "application/x-idi-function" data. call-command = "CALL" CRLF function-id = word If the function specified is successfully invoked, status "100 OK" will be returned. If the function is not registered, "402 Function Not Available" will be returned. If any parameters in the data part should be changed, "304 Change Function Parameter" will be retured with data part which contains proposed parameter sets from callee IDO. If the data part can not be parsed, or corrupted, "403 Corrupted Data" will be returned. 5.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 found, "402 Function Not Available" will be returned. And if the function is found, but not successfully KILLed, "401 IDO Internal Error" will be returned. kill-command = "KILL" SP function-id CRLF This command takes function-id parameter. This value is the value of the Function ID property in "application/x-idi-function" data which returned by callee IDO for CALL command. 5.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 "303 Permission Denied" will be returned. And if the function is not successfully added, "401 IDO Internal Error" will be returned. S. Fujimoto, et. al. [Page 16]
INTERNET DRAFT IDIP 30 Mar 1998 5.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 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 found, status "402 Function Not Available" will be returned. If the request comes form an unauthorized IDO, status "303 Permission Denied" will be returned. delete-command = "DELETE" CRLF 5.8. DISABLE This command is used to delete an entry TEMPORARY from the list of functions that can be returned in response to a LIST command. Only the Function Enablers can issue a DISABLE command. If the IDI function specified is successfully disabled, status "100 OK" will be returned. If the function is not found, status "402 Function Not Available" will be returned. If the request comes form an unauthorized IDO, status "303 Permission Denied" will be returned. disable-command = "DISABLE" function-id CRLF 5.9. ENABLE This command is used to enable an disabled entry for the list of functions. Only the Function Enabler can issue a ENABLE command. If the IDI function specified is successfully enable, status "100 OK" will be returned. If the disabled function is not existed, status "402 Function Not Available" will be returned. enable-command = "ENABLE" function-id CRLF 5.10. LOGIN This command is used to establish connection from a Function Enabler to the IDO server. Only the Function Enablers can issue a LOGIN command. If authentication was successful, status "100 OK" will be returned, or "302 Authentication Failed" will be returned. login-command = "LOGIN" identity_name CRLF 5.11. LOGOUT This command is used to shut down the connection from a Function Enabler to the IDO server. Only the Function Enabler can issue a LOGOUT command. S. Fujimoto, et. al. [Page 17]
INTERNET DRAFT IDIP 30 Mar 1998 logout-command = "LOGOUT" CRLF For this command, the IDO server MUST returns "100 OK". 5.12. REDIRECT This command is used to set the destination for redirection. If the request was accepted, status "100 OK" will be retured. If the request was rejected, status "303 Permission Denied" will be returned. redirect-command = "REDIRECT" IDI-Address CRLF 6. Data description format for IDI function IDO use a custom data format to describe IDI function, or to negotiate IDI function parameters. This data format is defined as "application/x-idi-function" on the Content-Type parameter. IDI-function = "<idi-function>" *property "</idi-function>" property = function-id-prop ; Function ID Property | desc-prop ; Description Property | keyword-prop ; Keyword Property | spec-prop ; Specification Property | parameters-prop ; Parameter Property 6.1. Function ID Property A Function ID property contains an unique identifer of an IDI Function within the callee IDO. function-id-prop = "<id>" function-id "</id>" function-id = token 6.2. Description Property A Description property contains a short description about the IDI- Function. desc-prop = "<desc>" description "</desc>" description = TEXT 6.3. Specification Property A Specification property contains one of the standards commonly supported on the Internet. S. Fujimoto, et. al. [Page 18]
INTERNET DRAFT IDIP 30 Mar 1998 spec-prop = "<bag>" *( "<spec>" standard-name "</spec>" ) "</bag>" | "<spec>" standard-name "</spec>" standard-name = TEXT 6.4. Keyword Property The Function Enabler specifies this property when it adds an IDI- Function entry. The values of this property will be sensitive for LIST command. keyword-prop = "<bag>" *( "<keyword>" keyword "</keyword>" ) "</bag>" | "<keyword>" keyword "</keyword>" keyword = TEXT 6.5. Parameter Property The parameter property contains structured data which will be passed to the Function Provider. parameter-prop = "<bag>" *( parameter-desc ) "</bag>" | parameter-desc paramter-desc = "<fixed>" *( func-parameter ) "</fixed>" | "<variable>" *( func-parameter ) "</variable>" func-parameter = "<" param-name *( SP param-attr ) ">" param-value "</" param-name ">" param-name = token param-value = TEXT S. Fujimoto, et. al. [Page 19]
INTERNET DRAFT IDIP 30 Mar 1998 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/1.0 From: alice@ido.foo.com To: bob@ido.foo.com Content-Length: 0 [from IDO-B] 100 OK IDIP-Version: IDIP/1.0 Content-Length: 0 [from IDO-A] LIST keyword: video, phone Content-Length: 0 [from IDO-B] 100 OK Content-Type: application/x-idi-function Content-Length: 184 <idi-function> <desc>video phone</desc> <spec>h.323</spec> <parameter> <variable> <calleraddress>ido.foo.com</calleraddress> </variable> </parameter> </idi-function> [from IDO-A] CALL Content-Type: application/x-idi-function Content-Length: 182 S. Fujimoto, et. al. [Page 20]
INTERNET DRAFT IDIP 30 Mar 1998 <idi-function> <desc>video phone</desc> <spec>h.323</spec> <parameter> <fixed> <calleraddress>alicepc.foo.com</calleraddress> </fixed> </parameter> </idi-fucntion> [form IDO-B] 100 OK Content-Type: application/x-idi-function Content-Length: 296 <idi-function> <id>vphone1.bob.ido.foo.com</id> <desc>video phone</desc> <spec>h.323</spec> <parameter> <fixed> <port>20450/udp</port> <address>bobpc.foo.com</address> <callerport>20450/udp</callerport> <calleraddress>alicepc.foo.com</calleraddress> </fixed> </parameter> [form IDO-A] END Content-Length: 0 [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/1.0 From: alice@ido.foo.com To: bob@ido.foo.com Content-Length: 0 S. Fujimoto, et. al. [Page 21]
INTERNET DRAFT IDIP 30 Mar 1998 [from IDO-B] 302 Authentication Failed IDIP-Version: IDIP/1.0 IDIP-Authenticate: style=basic Content-Length: 0 [from IDO-A] START From: alice@ido.foo.com To: bob@ido.foo.com IDIP-Authenticate: style=basic Content-Type: application/octet-stream Content-Length: 7 (7byte password data is here) [from IDO-B] 100 OK [continue negotiation] 7.3. Blocking Inquery 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/1.0 From: charley@ido.foo.com To: bob@ido.foo.com Content-Length: 0 [from IDO-B] 100 OK Version: IDIP/1.0 Content-Length: 0 [from IDO-C] LIST IDIP-Version: IDIP/1.0 keyword: video, phone Content-Length: 0 [from IDO-B] 402 Function Not Available IDIP-Version: IDIP/1.0 S. Fujimoto, et. al. [Page 22]
INTERNET DRAFT IDIP 30 Mar 1998 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 "ftpd.bobpc1.foo.com". [After identification, from Function Enabler (FE-B)] ADD Content-Type: application/x-idi-function Content-Length: 289 <idi-function> <id>ftpd.bobpc1.foo.com</id> <desc>ftp server</desc> <spec>rfc959</spec> <parameter> <fixed> <port>20/tcp</port> <address>bobpc1.foo.com</address> </fixed> <variable> <user></user> <password></password> </variable> </parameter> </idi-function> [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 Bob(bob@ido.foo.com) using ftp protocol. Alice started the negotiation. [After Identification, from IDO-A] LIST keyword: ftp Content-Length: 0 S. Fujimoto, et. al. [Page 23]
INTERNET DRAFT IDIP 30 Mar 1998 [from IDO-B] 100 OK Content-Type: multipart/mixed; boundary="----- =_NextPart_0001303033304" Content-Length: 752 ----- =_NextPart_0001303033304 Content-Type: application/x-idi-function Content-Length: 257 <idi-function> <desc>ftp server</desc> <spec>rfc959</spec> <parameter> <fixed> <port>20/tcp</port> <host>bobpc1.foo.com</host> </fixed> <variable> <user>alice</user> <password></password> </variable> </parameter> </idi-function> ----- =_NextPart_0001303033304 Content-Type: application/x-idi-function Content-Length: 254 <idi-function> <name>ftp client</name> <spec>rfc959</spec> <parameter> <variable> <host></host> <port>20/tcp</port> <user>bob</user> <password>theSecret</password> <path>/data.bin</path> </variable> </parameter> </idi-function> ----- =_NextPart_0001303033304 [from IDO-A] CALL Content-Type: application/x-idi-function Content-Length: 257 S. Fujimoto, et. al. [Page 24]
INTERNET DRAFT IDIP 30 Mar 1998 <idi-function> <desc>ftp server</desc> <spec>rfc959</spec> <parameter> <fixed> <port>20/tcp</port> <host>bobpc1.foo.com</host> </fixed> <variable> <user>alice</user> <password></password> </variable> </parameter> </idi-function> [form IDO-B] 100 OK Content-Type: application/x-idi-function Content-Length: 240 <idi-function> <desc>ftp server</desc> <spec>rfc959</spec> <parameter> <fixed> <port>20/tcp</port> <host>bobpc1.foo.com</host> <user>alice</user> <password>openSesame</password> </fixed> </parameter> </idi-function> [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(bobpc1.foo.com), account "alice", password "openSesame". S. Fujimoto, et. al. [Page 25]
INTERNET DRAFT IDIP 30 Mar 1998 By the way, 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 Content-Type: application/x-idi-function Content-Length: 257 <idi-function> <desc>ftp server</desc> <spec>rfc959</spec> <parameter> <fixed> <port>20/tcp</port> <host>bobpc1.foo.com</host> </fixed> <variable> <user>alice</user> <password></password> </variable> </parameter> </idi-function> [from Function Enabler] 100 OK Content-Type: application/sdp Content-Length: 240 <idi-function> <desc>ftp server</desc> <spec>rfc959</spec> <parameter> <fixed> <port>20/tcp</port> <host>bobpc1.foo.com</host> <user>alice</user> <password>openSesame</password> </fixed> </parameter> </idi-function> [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. S. Fujimoto, et. al. [Page 26]
INTERNET DRAFT IDIP 30 Mar 1998 7.6. Ask Redirection Bob(bob@ido.foo.com) wants to forward all requests to another identity(bob@personalido.foo.com). [After identification, from Function Enabler (FE-A)] REDIRECT bob@personalido.foo.com Content-Length: 0 [From IDO-A] 100 OK Content-Length: 0 After this operation, Alice(alice@ido.foo.com) try to call Alice. START From: alice@ido.foo.com To: bob@ido.foo.com (some parameters) [From IDO-A] 202 IDO Forworded Location: bob@personalido.foo.com Content-Length: 0 S. Fujimoto, et. al. [Page 27]
INTERNET DRAFT IDIP 30 Mar 1998 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. 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. [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 [URL] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of Minnesota, December 1994. S. Fujimoto, et. al. [Page 28]
INTERNET DRAFT IDIP 30 Mar 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 Akinori Iwakawa Fujitsu Labs Limited. Okubocho Nishiwaki 64 Akashi, HYOGO 674 JAPAN Fax: +81 (78) 934 - 3312 Email: iwakawa@flab.fujitsu.co.jp 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, et. al. [Page 29]