idnits 2.17.1 draft-fujimoto-idip-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 32 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 28 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 8 instances of too long lines in the document, the longest one being 17 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (30 Mar 1999) is 9157 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CRLF' is mentioned on line 300, but not defined == Missing Reference: 'From IDO-A' is mentioned on line 1220, but not defined == Unused Reference: 'MIME' is defined on line 1249, but no explicit reference was found in the text == Unused Reference: 'URL' is defined on line 1260, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'US-ASCII' ** Obsolete normative reference: RFC 1590 (ref. 'MEDIA TYPE') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1521 (ref. 'MIME') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) -- Possible downref: Non-RFC (?) normative reference: ref. 'TLS' ** Downref: Normative reference to an Historic RFC: RFC 2311 (ref. 'SMIME') ** Obsolete normative reference: RFC 1738 (ref. 'URL') (Obsoleted by RFC 4248, RFC 4266) Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT S. Fujimoto 3 draft-fujimoto-idip-01.txt A. Iwakawa 4 D. Marvit 5 Fujitsu Labs of America, Inc. 6 Expire: 30 Sep 1999 30 Mar 1999 8 IDentity Infrastructure Protocol (IDIP) 10 Status of this Memo 12 This document is an Internet-Draft and is NOT offered in accordance 13 with Section 10 of RFC2026, and will only exist as an Internet-Draft. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (1999). All Rights Reserved. 34 Abstract 36 The IDentity Infrastructure Protocol (IDIP) is designed to support 37 a new class of services known as 'Identity Services'. These 38 constitute online extensions of a person's identity leading to the 39 formation of an 'extended individual'. IDIP supports the 40 coordinated communications between online identities (so called 41 IDOs) and facilitates the invocation of applications. This 42 document presents a specification for IDIP and provides some 43 examples. 45 Table of Contents 47 1. Introduction ....................................................3 48 1.1. Overview of IDIP .............................................3 49 1.2. Requirements .................................................3 50 1.3. Definitions ..................................................4 51 1.3.1. IDO server ................................................4 52 1.3.2. IDO (IDentity Object) .....................................4 53 1.3.3. IDI (IDentity Infrastructure) .............................4 54 1.3.4. IDI Control Channel .......................................4 55 1.3.5. Session ...................................................5 56 1.3.6. Function Provider .........................................5 57 1.3.7. ASC (Application Specific Channel) ........................5 58 1.3.8. Function Enabler ..........................................5 59 1.3.9. IDO Terminal ..............................................5 60 1.4. Basic Operation ..............................................6 61 2. Generic Grammar .................................................6 62 2.1. Basic Rules ..................................................6 63 2.2. IDIP Request .................................................8 64 2.3. IDIP Response ................................................8 65 2.4. IDIP Data ....................................................9 66 3. IDIP Parameters .................................................9 67 3.1. IDIP Version .................................................9 68 3.2. IDO-To and IDO-From .........................................10 69 3.3. Content-Type ................................................10 70 3.4. Content-Length ..............................................11 71 3.5. Accept-Type .................................................11 72 3.6. IDIP-Authenticate ...........................................11 73 3.6.1. Authenticate Style Parameter .............................11 74 3.6.1a. Style Basic .............................................12 75 3.7. Keywords Parameter ..........................................12 76 3.8. Location ....................................................12 77 4. Status Code Definition .........................................12 78 4.1. Success .....................................................12 79 4.1.1. 100 OK ...................................................12 80 4.2. Informational ...............................................12 81 4.2.1. 201 Continue .............................................13 82 4.2.2. 202 IDO Forwarded ........................................13 83 4.2.3. 203 IDO Moved ............................................13 84 4.2.4. 204 Unknown Caller .......................................13 85 4.2.5. 205 Identified As Anonymous ..............................13 86 4.3. Rejected Errors .............................................13 87 4.3.1. 301 Invalid IDO Called ...................................14 88 4.3.2. 302 Authentication Failed ................................14 89 4.3.3. 303 Permission Denied ....................................14 90 4.3.4. 304 Change Funciton Parameter ............................14 91 4.4. Unexpected Errors ...........................................14 92 4.4.1. 401 IDO Internal Error ...................................14 93 4.4.2. 402 Function Not Available ...............................14 94 4.4.3. 403 Corrupted Data .......................................14 95 5. IDIP Commands ..................................................15 96 5.1. START ......................................................15 97 5.2. END ........................................................15 98 5.3. LIST .......................................................15 99 5.4. CALL .......................................................16 100 5.5. KILL .......................................................16 101 5.6. ADD ........................................................16 102 5.7. DELETE .....................................................16 103 5.8. DISABLE ....................................................17 104 5.9. ENABLE .....................................................17 105 5.10. LOGIN ......................................................17 106 5.11. LOGOUT .....................................................17 107 5.12. REDIRECT ...................................................18 108 6. Data description format for IDI function .......................18 109 6.5. Function ID Property .........................................18 110 6.2. Description Property .........................................18 111 6.3. Specification Property .......................................18 112 6.4. Keyword Property .............................................18 113 6.5. Parameter Property ...........................................19 114 7. Examples .......................................................20 115 7.1. Simple Negotiation ..........................................20 116 7.2. Identify Caller .............................................22 117 7.3. Blocking Inquery ............................................23 118 7.4. Adding an IDI function ......................................24 119 7.5. Giving temporary access .....................................24 120 7.5. Asking Redirection ..........................................27 121 8. Security Considerations ........................................28 122 9. Reference ......................................................28 123 10. Authors' Address ..............................................29 125 1. Introduction 127 1.1. Overview of IDIP 129 The existence of an IDentity Infrastructure (IDI) will enable people 130 to manage and maintain their privacy while enhancing the power and 131 variety of services available. 133 The IDentity Infrastructure Protocol (IDIP) is an application-layer 134 protocol for "online presence" management that is central to IDI. 135 Using this protocol, IDentity Objects (IDOs) can communicate and 136 control the initiation of applications that provide various identity 137 services and functions. For the purpose of this protocol, each 138 "identity function" can be defined as a set of network connections. 140 IDIP can be used to send and receive dynamically changing information 141 about "extended individuals" through their IDOs. IDIP can also be 142 used to block or allow the access to the information contained in 143 IDOs based on the rule which defined by callee entity. 145 1.2. Requirements 147 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 148 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 149 and "OPTIONAL" are to be interpreted as described in RFC 2119 150 [KEYWORDS] and indicate requirement levels for compliant IDIP 151 implementations. 153 1.3. Definitions 155 The IDI system consists of several components as illustrated below. 157 +-------------+ IDI Control Channel +-------------+ +--------+ 158 | IDO server |=====================>| IDO server |==| IDO | 159 +-------------+ +-------------+ |Terminal| 160 || IDI Control Channel || +--------+ 161 +-------------+ +-------------+ /| 162 |Func. Enabler| <-User Requests |Func. Enabler| | 163 +-------------+ +-------------+ User 164 || Invoke App. Invoke App.|| Requests 165 +-------------+ +-------------+ 166 | Function | | Function | 167 | Provider |<====================>| Provider | 168 +-------------+ Application +-------------+ 169 (Caller) Specific (Callee) 170 Channel 172 This specification uses a number of terms to refer the components of 173 the system. 175 1.3.1. IDO server 177 An IDO server is the network component which can accept IDIP 178 calls. IDO server will be found from an IDO Address explained below. 180 1.3.2. IDO(IDentity Object) 182 An IDO is a logical component that is hosted by an IDO server. IDOs 183 can communicate using IDIP to establish "Application Specific 184 Channels" (described below). An IDO is hosted by an IDO server. Each 185 IDO has only one interface on the IDO server which is specified by an 186 IDO address. 188 1.3.3. IDI (IDentity Infrastructure) 190 IDI(IDentity Infrastructure) is an infrastructure to provide "Identity 191 Services". Collectively these will provide a rich online presence 192 while enhancing both privacy and richness of available services. 194 1.3.4. IDI Control Channel 196 An IDI Control Channel is used to connect IDOs. This channel is 197 always open and publicly accessible to accept incoming requests. 199 1.3.5. Session 201 A session is a continuous time period during which two IDOs 202 communicate and during which the requester (also known as the 203 "caller") has been identified as meriting authorization by the IDO 204 receiving the request (also known as the "callee"). The request 205 provides some form of authentication. Based upon the authentication 206 information provided by the requester, the IDO receiving the request 207 may allow complete access, partial access, or no access to the 208 requester. 210 1.3.6. Function Provider 212 As described in this document, an IDI Function is defined as a set of 213 network connections called the "Application Specific 214 Channel(ASC)". The Function Provider is a component which implements 215 IDI function with controling applications. These applications actually 216 provide ASCs. A Function Provider provides abstracted interface for 217 parameter negotiation, invoking application, shutdown the application. 219 1.3.7. ASC (Application Specific Channel) 221 After negotiation between IDOs, applications will communicate through 222 Application Specific Channels (ASCs). These are established 223 out-of-band. (Here 'out-of-band' means outside the IDO Control 224 Channel.) Each application, or application type, will create its own 225 Application Specific Channel. The communication between applications 226 along ASCs is not part of the IDIP specification. 228 1.3.8. Function Enabler 230 The IDO may have a "Function Enabler" component. These components have 231 exactly same features as the IDO server. However, a Function Enabler 232 will only accept connections from authorized IDO. A Function Enabler 233 is an OPTIONAL component. 235 1.3.9. IDO Terminal 236 An IDO may have an "IDO Terminal", which can control the IDO's 237 behavior. One example of controling IDO's behavior is setting 238 filtering preferences. IDO Terminal is NOT part of the IDIP 239 specification. 241 1.4. Basic Operation 243 This section explains the basic protocol functionality and operation. 244 Callers and callees are identified by IDO addresses. 246 When an IDO starts a negotiation with another IDO, the caller first 247 locates the appropriate IDO server for the callee and connects to the 248 server. Next, the caller IDO issues a "START" command to the callee 249 IDO. This serves to specify the callee IDO and to identify the 250 caller. Then the caller and callee IDOs can exchange commands and 251 responses until the IDIP connection is closed or until an "END" 252 command is issued. The caller IDO may issue a "LIST" command to 253 request a list of functions available to the callee. The caller may 254 also issue a "CALL" command to activate a specific IDO "function". 255 The connection that forms a "function" MAY terminate without an IDO's 256 control. To terminate the IDI function explicitly, the caller MAY 257 issue a "KILL" command to the callee IDO. 259 2. Generic Grammar 261 2.1. Basic Rules 263 The following rules are used throughout this specification to 264 describe basic parsing constructs. The US-ASCII coded character set 265 is defined by [US-ASCII]. 267 OCTET = 269 CHAR = 271 UPALPHA = 273 LOALPHA = 275 ALPHA = UPALPHA | LOALPHA 277 DIGIT = 279 CTL = 282 CR = 283 LF = 285 SP = 287 HT = 289 <"> = 291 IDIP defines the octet sequence CR LF as the end-of-line marker for 292 all protocol elements. 294 CRLF = CR LF 296 IDIP headers can be folded onto multiple lines if the continuation 297 line begins with a space or horizontal tab. All linear white space, 298 including folding, has the same semantics as SP. 300 LWS = [CRLF] 1*( SP | HT ) 302 The TEXT rule is only used for descriptive field contents and values 303 that are not intended to be interpreted by the message parser. Words 304 of TEXT may contain octets from character sets other than US-ASCII. 306 TEXT = 308 Hexadecimal numeric characters are used in several protocol elements. 310 HEX = "A" | "B" | "C" | "D" | "E" | "F" 311 | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT 313 The special characters must be in a quoted string to be used within a 314 parameter value. 316 word = token | quoted-string 318 token = 1* 320 tspecials = "(" | ")" | "<" | ">" | "@" 321 | "," | ";" | ":" | " 322 | "/" | "[" | "]" | "?" | "=" 323 | "{" | "}" 325 A string of text is parsed as a single word if it is quoted using 326 double-quote marks. 328 quoted-string = ( <"> *(qdtext) <"> ) 329 qdtext = > 331 Single-character quoting using the backslash ("\") character is not 332 permitted in IDIP. 334 2.2. IDIP Request 336 The caller IDO issues IDIP requests. 338 An IDIP request consists of command and data parts. The command part 339 contains a command method and a method argument. 341 IDIP-request = IDIP-command IDIP-parameters CRLF IDIP-data 343 IDIP-parameters = * (IDIP-parameter CRLF) 345 IDIP-command = start-command 346 | end-command 347 | list-command 348 | call-command 349 | kill-command 350 | add-command 351 | delete-command 352 | disable-command 353 | enable-command 354 | login-command 355 | logout-command 356 | redirect-command 358 2.3. IDIP Response 360 The callee IDO returns IDIP response. 362 The IDIP response consists of status and data parts. The status part 363 contains status code and its description. 365 IDIP-response = IDIP-status IDIP-data 367 IDIP-status = status-line IDIP-parameters 369 Each Status-Code is defined in later section, including a description 370 of which method(s) it can follow and any metainformation required in 371 the response. 373 status-line = status-code SP status-description CRLF 374 status-code = successful ; 1XX 375 | informational ; 2XX 376 | rejected-error ; 3XX 377 | unexpected-eror ; 4XX 379 successful = "100" ; Success 381 informational = "201" ; Continue 382 | "202" ; Forwarded 383 | "203" ; Moved 384 | "204" ; Unknown Caller 385 | "205" ; Identified As Anonymous 387 rejected-error = "301" ; Invalid IDO Called 388 | "302" ; Authentication Failed 389 | "303" ; Permission Denied 390 | "304" ; Change Function Parameter 392 unexpected-error = "401" ; IDO Internal Error 393 | "402" ; Function Not Avaiable 394 | "403" ; Corrupted Data 396 status-description = 1*TEXT 398 2.4. IDIP Data 400 IDIP Data is used to send media-typed([MEDIA TYPE]) data which is 401 required by an IDIP-request or an IDIP-response. 403 IDIP-data = * 405 3. IDIP Parameters 407 The IDIP request and response MAY contain one or more lines of IDIP 408 parameters. 410 IDIP-parameter = IDIP-version 411 | IDO-To 412 | IDO-From 413 | content-type 414 | content-length 415 | accept-type 416 | IDIP-authenticate 417 | keyword-parameter 418 | location-parameter 420 3.1. IDIP Version 421 IDIP uses a "." numbering scheme to indicate versions 422 of the protocol. The protocol versioning policy allows a sender to 423 indicate the compatibility of IDIP protocol interfaces. The 424 number is incremented when the new feature is added. And the 425 number is incremented when a format of a message within the protocol 426 is changed or when some features are disabled. If the IDIP Version 427 parameter is specified in the IDIP request, the IDO server MUST 428 include IDIP-Version Parameter in the IDIP response. The IDIP 429 version described in this document is "1.0". 431 IDIP-Version = "IDIP-Version:" SP "IDIP" "/" 1*DIGIT "." 1*DIGIT 433 Note that the major and minor numbers should be treated as separate 434 integers and that each may be incremented higher than a single digit. 435 Thus, IDIP/2.4 is a lower version than IDIP/2.13, which in turn is 436 lower than IDIP/12.3. Leading zeros should be ignored by recipients 437 and never generated by senders. 439 3.2. IDO-To and IDO-From 441 The IDO address is used to specify both caller and callee IDOs. 443 IDO-To = "To:" SP IDI-Address 445 IDO-From = "From:" SP IDI-Address 447 IDI-Address = identity_name "@" host 449 identity_name = 1 * 451 host = 455 Note that the host which is specified in the "host" part must respond 456 to an IDIP request. There is no limitation for the length of an IDI- 457 Address However, an IDO server MUST accept at least 1024 characters. 459 3.3. Content Type 461 The content type parameter can be used to indicate the media type of 462 data which is attached to an IDIP command or response. 464 content-type = "Content-Type:" SP media-type 466 IDIP uses Internet Media Types [MEDIA TYPE] in the Content-Type 467 parameter or Accept-Type parameter to provide open and extensible 468 data typing. 470 media-type = type "/" subtype *( ";" parameter ) 472 type = token 474 subtype = token 476 parameter = attribute "=" value 478 attribute = token 480 value = token | quoted-string 482 The type, subtype, and parameter attribute names are case- 483 insensitive. Parameter values may or may not be case-sensitive, 484 depending on the semantics of the parameter name. 486 3.4. Content-Length 488 The Content-Length parameter indicates the number of bytes in the 489 attached data. All IDIP requests and responses MUST include a 490 Content-Length parameter. 492 3.5. Accept Type 494 The Accept-Type parameter can be used to indicate a media which are 495 acceptable as a response to a request. This parameter may appear 496 multiple times to indicate a list of media. 498 accept-type = "Accept-Type:" SP media-type 500 3.6. IDIP Authenticate 502 When used by the IDIP caller, the IDIP-Authenticate parameter 503 specifies the authentication parameters. When used by the IDIP 504 callee, this parameter indicates which authentication parameters 505 should be specified by the caller. 507 IDIP-authenticate = "IDIP-Authenticate:" SP auth-info 509 auth-info = authenticate-style ";" authenticate-data 511 authenticate-data = base64data * ("," base64data) 513 3.6.1. Authenticate Style 515 The authenticate style indicates which authentication style will be 516 used for authentication. In this document, only "style basic" is 517 defined. 519 authenticate-style = "style" "=" value 521 3.6.1a. Style Basic 523 This style provides 'password' authentication. The IDIP-body is used 524 to send password data. 526 3.7. Keywords Parameter 528 The caller IDO MAY include a Keywords parameter with the LIST 529 command. The keywords are comma(',') delimited and SHOULD effect the 530 result of the LIST command. 532 keyword-parameter = "Keywords:" SP keywords 534 keywords = word * ("," keywords) 536 3.8. Location 538 In the event that an IDO has changed its server location, the old 539 location IDO server MAY generate Location parameter to show the new 540 location of callee IDO. 542 location-parameter = "Location:" SP location 544 location = IDO-Address 546 4. Status Code Definition 548 4.1. Success 550 This class of status code indicates that the caller IDO's request was 551 successfully received, understood, and accepted. 553 4.1.1. 100 OK 555 The request has succeeded. 557 4.2. Informational 559 This class of status code indicates that the caller IDO's request was 560 successfully received, understood, but is pending acceptance status. 562 4.2.1. 201 Continue 564 The caller IDO may continue with its request. This interim response 565 is used to inform the caller IDO that the initial part of the request 566 has been received and has not yet been rejected by the server. The 567 caller IDO SHOULD contine by sending the remainder of the request or, 568 if the request has already been completed, ignore this response. The 569 callee IDO MUST send a final response after the request has been 570 completed. 572 4.2.2. 202 IDO Forwarded 574 The server which hosts the IDO was temporary changed. The temporary 575 server's location is provided in the Location parameter. The caller 576 IDO SHOULD finish the current connection, and re-connect with a new 577 server. 579 4.2.3. 203 IDO Moved 581 The server which hosts IDO was changed. The new server's location is 582 provided in the Location parameter. The caller IDO SHOULD finish the 583 current connection, and re-connect with a new server. 585 4.2.4. 204 Unknown Caller 587 The callee IDO can not identify the caller as the specified IDI- 588 Address in the IDO-From parameter. The caller MAY retry to issue the 589 START command with a different IDO-From parameter. 591 4.2.5. 205 Identified As Anonymous 593 If the callee IDO accepts anonymous call, all of the unknown callers 594 will be regarded as anonymous entities. The caller MAY retry to issue 595 a START command with a different IDO-From parameter. 597 4.3. Rejected Errors 599 This class of status code indicates that the caller IDO's request was 600 successfully received and understood, but rejected. 602 4.3.1. 301 Invalid IDO Called 604 The IDI-address was invalid for the server. The caller MAY retry to 605 issue a START command with a different IDO-To parameter. 607 4.3.2. 302 Authentication Failed 609 Provided authentication information was invalid. The callee SHOULD 610 send correct information in the next request. 612 4.3.3. 303 Permission Denied 614 The request was rejected, because of the callee has not the right to 615 do. The callee MAY issue END and START commands to get the privillege 616 rights. 618 4.3.4. 304 Change Function Parameter 620 Some of the parameters specified in the CALL request were rejected, 621 and a change is required. The caller SHOULD retry the same request 622 with differnent parameters. 624 4.4. Unexpected Errors 626 This class of status code indicates that the request was not accepted 627 because of an unexpected event. 629 4.4.1. 401 IDO Internal Error 631 The request was not processed as expected. The callee MAY retry the 632 same request. 634 4.4.2. 402 Function Not Available 636 The IDI function specified could not accept the request. The callee 637 SHOULD issue the LIST command to get updated list of IDO functions. 639 4.4.3. 403 Corrupted Data 641 The IDIP data part in the request was corrupted. The callee MUST 642 resend the request to complete a request. 644 5. IDIP Commands 646 5.1. START 648 This command is used to specify which IDO to call. At the same time, 649 the caller IDO MAY add authentication information. 651 start-command = "START" CRLF 653 Both IDO-To and IDO-From parameters MUST be specified. 655 The caller IDO SHOULD send the request with an IDIP-authenticate 656 parameter to identify as the specific caller. On the other hand, the 657 callee IDO MUST return "302 Authentication Failed" error, in case of 658 the caller was required to provide authentication information. 660 If the session is successfully established between IDOs, status "100 661 OK" will be returned. If the callee IDO is invalid, status "301 662 Invalid IDO Called" will be returned. If the caller IDO is the 663 account which is required further authentication, status "302 664 Authentication Failed" " will be returned. And if the callee IDO has 665 changed its server location, status "202 IDO Forwarded" or "203 IDO 666 Moved" will be returned with Location parameter. 668 5.2. END 670 This command is used to shut down the connection initiated by the 671 START command. It is RECOMMENDED that session are ended by issuing 672 an END command. 674 end-command = "END" CRLF 676 For this command, the IDO server MUST returns "100 OK". 678 5.3. LIST 680 This command returns the list of functions that are available to be 681 called on by the callee IDO. These functions are described in the 682 "application/x-idi-function" data structure. 684 list-command = "LIST" CRLF 686 The caller IDO MAY use the Keywords parameter to return a list of 687 matched IDI-function entries. 689 If the request is successfully accepted by the IDO server, status 690 "100 OK" will be returned. If the list of functions was empty, "402 691 Function Not Available" will be returned. 693 5.4. CALL 695 This command is used to activate a function. The response to a CALL 696 command may contain a set of parameters relevant to the function 697 being called. The caller IDO MUST send the request with 698 "application/x-idi-function" data. 700 call-command = "CALL" CRLF 702 function-id = word 704 If the function specified is successfully invoked, status "100 OK" 705 will be returned. If the function is not registered, "402 Function 706 Not Available" will be returned. If any parameters in the data part 707 should be changed, "304 Change Function Parameter" will be retured 708 with data part which contains proposed parameter sets from callee 709 IDO. If the data part can not be parsed, or corrupted, "403 710 Corrupted Data" will be returned. 712 5.5. KILL 714 This command is used to explicitly terminates a function which 715 activated by the previous CALL command. If the function specified is 716 successfully KILLed, "100 OK" will be returned. If the function is 717 not found, "402 Function Not Available" will be returned. And if the 718 function is found, but not successfully KILLed, "401 IDO Internal 719 Error" will be returned. 721 kill-command = "KILL" SP function-id CRLF 723 This command takes function-id parameter. This value is the value of 724 the Function ID property in "application/x-idi-function" data which 725 returned by callee IDO for CALL command. 727 5.6. ADD 729 This command is used to add an entry to the list of functions that 730 can be returned in response to a LIST command. Only the Function 731 Enablers can issue a ADD command. 733 add-command = "ADD" CRLF 735 If the function specified is successfully added, "100 OK" will be 736 returned. If a request comes from an unauthorized IDO, status "303 737 Permission Denied" will be returned. And if the function is not 738 successfully added, "401 IDO Internal Error" will be returned. 740 5.7. DELETE 742 This command is used to delete an entry from the list of functions 743 that can be returned in response to a LIST command. Only the 744 Function Enablers can issue a DELETE command. If the IDI function 745 specified is successfully deleted, status "100 OK" will be returned. 746 If the function is not found, status "402 Function Not Available" 747 will be returned. If the request comes form an unauthorized IDO, 748 status "303 Permission Denied" will be returned. 750 delete-command = "DELETE" CRLF 752 5.8. DISABLE 754 This command is used to delete an entry TEMPORARY from the list of 755 functions that can be returned in response to a LIST command. Only 756 the Function Enablers can issue a DISABLE command. If the IDI 757 function specified is successfully disabled, status "100 OK" will be 758 returned. If the function is not found, status "402 Function Not 759 Available" will be returned. If the request comes form an 760 unauthorized IDO, status "303 Permission Denied" will be returned. 762 disable-command = "DISABLE" function-id CRLF 764 5.9. ENABLE 766 This command is used to enable an disabled entry for the list of 767 functions. Only the Function Enabler can issue a ENABLE command. If 768 the IDI function specified is successfully enable, status "100 OK" 769 will be returned. If the disabled function is not existed, status 770 "402 Function Not Available" will be returned. 772 enable-command = "ENABLE" function-id CRLF 774 5.10. LOGIN 776 This command is used to establish connection from a Function Enabler 777 to the IDO server. Only the Function Enablers can issue a LOGIN 778 command. If authentication was successful, status "100 OK" will be 779 returned, or "302 Authentication Failed" will be returned. 781 login-command = "LOGIN" identity_name CRLF 783 5.11. LOGOUT 785 This command is used to shut down the connection from a Function 786 Enabler to the IDO server. Only the Function Enabler can issue a 787 LOGOUT command. 789 logout-command = "LOGOUT" CRLF 791 For this command, the IDO server MUST returns "100 OK". 793 5.12. REDIRECT 795 This command is used to set the destination for redirection. If the 796 request was accepted, status "100 OK" will be retured. If the request 797 was rejected, status "303 Permission Denied" will be returned. 799 redirect-command = "REDIRECT" IDI-Address CRLF 801 6. Data description format for IDI function 803 IDO use a custom data format to describe IDI function, or to 804 negotiate IDI function parameters. This data format is defined as 805 "application/x-idi-function" on the Content-Type parameter. 807 IDI-function = "" *property "" 809 property = function-id-prop ; Function ID Property 810 | desc-prop ; Description Property 811 | keyword-prop ; Keyword Property 812 | spec-prop ; Specification Property 813 | parameters-prop ; Parameter Property 815 6.1. Function ID Property 817 A Function ID property contains an unique identifer of an IDI 818 Function within the callee IDO. 820 function-id-prop = "" function-id "" 822 function-id = token 824 6.2. Description Property 826 A Description property contains a short description about the IDI- 827 Function. 829 desc-prop = "" description "" 831 description = TEXT 833 6.3. Specification Property 835 A Specification property contains one of the standards commonly 836 supported on the Internet. 838 spec-prop = "" *( "" standard-name "" ) "" 839 | "" standard-name "" 841 standard-name = TEXT 843 6.4. Keyword Property 845 The Function Enabler specifies this property when it adds an IDI- 846 Function entry. The values of this property will be sensitive for 847 LIST command. 849 keyword-prop = "" *( "" keyword "" ) "" 850 | "" keyword "" 852 keyword = TEXT 854 6.5. Parameter Property 856 The parameter property contains structured data which will be passed 857 to the Function Provider. 859 parameter-prop = "" *( parameter-desc ) "" 860 | parameter-desc 862 paramter-desc = "" *( func-parameter ) "" 863 | "" *( func-parameter ) "" 865 func-parameter = "<" param-name *( SP param-attr ) ">" param-value "" 867 param-name = token 869 param-value = TEXT 871 7. Examples 873 7.1. Simple Negotiation 875 Alice(alice@ido.foo.com) wants to talk with Bob(bob@ido.foo.com) 876 using "video phone". Alice's IDO(IDO-A) connects to Bob's IDO(IDO-B) 877 and starts negotiation. They are engaging in peer-to-peer 878 communication. 880 [Start session from IDO-A] 881 START 882 IDIP-Version: IDIP/1.0 883 From: alice@ido.foo.com 884 To: bob@ido.foo.com 885 Content-Length: 0 887 [from IDO-B] 888 100 OK 889 IDIP-Version: IDIP/1.0 890 Content-Length: 0 892 [from IDO-A] 893 LIST 894 keyword: video, phone 895 Content-Length: 0 897 [from IDO-B] 898 100 OK 899 Content-Type: application/x-idi-function 900 Content-Length: 184 902 903 video phone 904 h.323 905 906 907 ido.foo.com 908 909 910 912 [from IDO-A] 913 CALL 914 Content-Type: application/x-idi-function 915 Content-Length: 182 916 917 video phone 918 h.323 919 920 921 alicepc.foo.com 922 923 924 926 [form IDO-B] 927 100 OK 928 Content-Type: application/x-idi-function 929 Content-Length: 296 931 932 vphone1.bob.ido.foo.com 933 video phone 934 h.323 935 936 937 20450/udp 938
bobpc.foo.com
939 20450/udp 940 alicepc.foo.com 941 942 944 [form IDO-A] 945 END 946 Content-Length: 0 948 [form IDO-B] 949 100 OK 950 Content-Length: 0 952 [End session] 954 7.2. Identify Caller 956 IDO-A identifies itself. 958 [Start session from IDO-A] 959 START 960 IDIP-Version: IDIP/1.0 961 From: alice@ido.foo.com 962 To: bob@ido.foo.com 963 Content-Length: 0 965 [from IDO-B] 966 302 Authentication Failed 967 IDIP-Version: IDIP/1.0 968 IDIP-Authenticate: style=basic 969 Content-Length: 0 971 [from IDO-A] 972 START 973 From: alice@ido.foo.com 974 To: bob@ido.foo.com 975 IDIP-Authenticate: style=basic 976 Content-Type: application/octet-stream 977 Content-Length: 7 979 (7byte password data is here) 981 [from IDO-B] 982 100 OK 984 [continue negotiation] 986 7.3. Blocking Inquery 988 Bob(IDO-B) does not want to communicate via "video phone" with 989 Charley(IDO-C), even though IDO-B has the capability of accepting a 990 "video phone" connection. 992 [Start session from IDO-C] 993 START 994 IDIP-Version: IDIP/1.0 995 From: charley@ido.foo.com 996 To: bob@ido.foo.com 997 Content-Length: 0 999 [from IDO-B] 1000 100 OK 1001 Version: IDIP/1.0 1002 Content-Length: 0 1004 [from IDO-C] 1005 LIST 1006 IDIP-Version: IDIP/1.0 1007 keyword: video, phone 1008 Content-Length: 0 1010 [from IDO-B] 1011 402 Function Not Available 1012 IDIP-Version: IDIP/1.0 1013 Content-Length: 0 1015 [continue negotiation] 1017 7.4. Adding an IDI function 1019 Bob(bob@ido.foo.com) wants to register an entry for a function named 1020 "ftpd.bobpc1.foo.com". 1021 [After identification, from Function Enabler (FE-B)] 1022 ADD 1023 Content-Type: application/x-idi-function 1024 Content-Length: 289 1026 1027 ftpd.bobpc1.foo.com 1028 ftp server 1029 rfc959 1030 1031 1032 20/tcp 1033
bobpc1.foo.com
1034 1035 1036 1037 1038 1039 1040 1042 [from IDO-B] 1043 100 OK 1044 Content-Length: 0 1046 [continue ...] 1048 7.5. Giving temporary access 1050 Alice(alice@ido.foo.com) wants to send binary data to 1051 Bob(bob@ido.foo.com) using ftp protocol. Alice started the 1052 negotiation. 1054 [After Identification, from IDO-A] 1055 LIST 1056 keyword: ftp 1057 Content-Length: 0 1059 [from IDO-B] 1060 100 OK 1061 Content-Type: multipart/mixed; boundary="----- =_NextPart_0001303033304" 1062 Content-Length: 752 1064 ----- =_NextPart_0001303033304 1065 Content-Type: application/x-idi-function 1066 Content-Length: 257 1068 1069 ftp server 1070 rfc959 1071 1072 1073 20/tcp 1074 bobpc1.foo.com 1075 1076 1077 alice 1078 1079 1080 1081 1083 ----- =_NextPart_0001303033304 1084 Content-Type: application/x-idi-function 1085 Content-Length: 254 1087 1088 ftp client 1089 rfc959 1090 1091 1092 1093 20/tcp 1094 bob 1095 theSecret 1096 /data.bin 1097 1098 1099 1101 ----- =_NextPart_0001303033304 1103 [from IDO-A] 1104 CALL 1105 Content-Type: application/x-idi-function 1106 Content-Length: 257 1107 1108 ftp server 1109 rfc959 1110 1111 1112 20/tcp 1113 bobpc1.foo.com 1114 1115 1116 alice 1117 1118 1119 1120 1122 [form IDO-B] 1123 100 OK 1124 Content-Type: application/x-idi-function 1125 Content-Length: 240 1127 1128 ftp server 1129 rfc959 1130 1131 1132 20/tcp 1133 bobpc1.foo.com 1134 alice 1135 openSesame 1136 1137 1138 1140 [form IDO-A] 1141 END 1142 Content-Length: 0 1144 [form IDO-B] 1145 100 OK 1146 Content-Length: 0 1148 [End session] 1150 After this negotiation, IDO-A has the information required to access 1151 IDO-B's ftp server(bobpc1.foo.com), account "alice", password 1152 "openSesame". 1154 By the way, when the CALL request was issued by IDO-A, IDO-B 1155 forwarded the request to its Function Enabler. 1157 [from IDO-B after identify itself] 1158 CALL 1159 Content-Type: application/x-idi-function 1160 Content-Length: 257 1162 1163 ftp server 1164 rfc959 1165 1166 1167 20/tcp 1168 bobpc1.foo.com 1169 1170 1171 alice 1172 1173 1174 1175 1177 [from Function Enabler] 1178 100 OK 1179 Content-Type: application/sdp 1180 Content-Length: 240 1182 1183 ftp server 1184 rfc959 1185 1186 1187 20/tcp 1188 bobpc1.foo.com 1189 alice 1190 openSesame 1191 1192 1193 1195 [ftp server on the terminal is now ready to receive data] 1197 Note that the result was also forwarded to IDO-A by IDO-B as response 1198 from IDO-A. 1200 7.6. Ask Redirection 1202 Bob(bob@ido.foo.com) wants to forward all requests to another 1203 identity(bob@personalido.foo.com). 1205 [After identification, from Function Enabler (FE-A)] 1206 REDIRECT bob@personalido.foo.com 1207 Content-Length: 0 1209 [From IDO-A] 1210 100 OK 1211 Content-Length: 0 1213 After this operation, Alice(alice@ido.foo.com) try to call Alice. 1215 START 1216 From: alice@ido.foo.com 1217 To: bob@ido.foo.com 1218 (some parameters) 1220 [From IDO-A] 1221 202 IDO Forworded 1222 Location: bob@personalido.foo.com 1223 Content-Length: 0 1225 8. Security Considerations 1227 To prevent the caller from violating callee's privacy, an IDO server 1228 SHOULD provide some high level authentication mechanism to identify 1229 the caller. 1231 Furthermore, some of IDI communications pass sensitive information, 1232 including password and other private information. In such cases the 1233 IDO server SHOULD use some encryption system such as TLS[TLS] or 1234 S/MIME[SMIME]. 1236 9. References 1238 [KEYWORDS] S. Bradner, "Key words for use in RFCs to indicate 1239 requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1240 1997. 1242 [US-ASCII] US-ASCII. Coded Character Set - 7-Bit American Standard 1243 Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1244 1986. 1246 [MEDIA TYPE] Postel, J., "Media Type Registration Procedure." RFC 1247 1590, USC/ISI, March 1994. 1249 [MIME] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet 1250 Mail Extensions) Part One: Mechanisms for Specifying and Describing 1251 the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, 1252 September 1993. 1254 [TLS] Tim Dierks, "The TLS protocol Version 1.0" Internet-Draft 1255 Consensus Development, Nov. 1997. 1257 [SMIME] S. Dusse, "S/MIME Version 2 Message Specification" RFC 2311, 1258 RSA Data Security, Mar. 1998 1260 [URL] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform 1261 Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation, 1262 University of Minnesota, December 1994. 1264 10. Authors' Address 1266 Shingo Fujimoto 1267 Fujitsu Labs of America, Inc. 1268 595 Lawrence Expressway 1269 Sunnyvale, CA 94086 U.S.A. 1271 Fax: +1 (408) 530 - 4515 1272 Email: shingo@fla.fujitsu.com 1274 Akinori Iwakawa 1275 Fujitsu Labs Limited. 1276 Okubocho Nishiwaki 64 1277 Akashi, HYOGO 674 JAPAN 1279 Fax: +81 (78) 934 - 3312 1280 Email: iwakawa@flab.fujitsu.co.jp 1282 Dave Marvit 1283 Fujitsu Labs of America, Inc. 1284 595 Lawrence Expressway 1285 Sunnyvale, CA 94086 U.S.A. 1287 Fax: +1 (408) 530 - 4515 1288 EMail: dave@marvit.org