[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
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]