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

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

   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

   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           = <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) <"> )

   qdtext         = <any CHAR except <"> 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       = * <any OCTET>

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 "<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 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           = <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
   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   = "<idi-function>" *property "</idi-function>"

   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      = "<name>" function-name "</name>"

5.2. Specification Property

   A Specification property contains one of the standards commonly
   supported on the Internet.

   spec-prop      = "<bag>" *( "<spec>" standard-name "</spec>" ) "</bag>"
                  | "<spec>" standard-name "</spec>"




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   = "<bag>" *( "<accept>" media-type "</accept>" ) "</bag>"
                 | "<accept>" media-type "</accept>"

5.4. Keywords Property

   The Keywords property contains string keywords which will be used at
   Keywords parameter in a LIST command.

   keywords-prop = "<bag>" *( "<keyword>" keyword "</keyword>" ) "</bag>"
                 | "<keyword>" 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 = "<location>" url "</location>"

   url           = <any 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

      <idi-function>
      <name>video phone</name>
      <spec>h.323</spec>
      </idi-function>

      [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

      <idi-function>
      <name>ftp data receive</name>
      <spec>ftp server</spec>
      </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



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

      <idi-function>
      <name>ftp data receive</name>
      <spec>ftp server<spec>
      </idi-function>

      ----- =_NextPart_0001303033304
      Content-Type: application/x-idi-function
      Content-Length: 125

      <idi-function>
      <name>ftp data send</name>
      <spec>ftp client</spec>
      <accept>application/sdp</accept>
      </idi-function>

      ----- =_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]

#