idnits 2.17.1 draft-fujimoto-idip-00.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 27 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-25) 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. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 21 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 12 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (6 Aug 1998) is 9394 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'MIME' is defined on line 950, 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) ** Obsolete normative reference: RFC 1738 (ref. 'URL') (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 2327 (ref. 'SDP') (Obsoleted by RFC 4566) -- Possible downref: Non-RFC (?) normative reference: ref. 'TLS' ** Downref: Normative reference to an Historic RFC: RFC 2311 (ref. 'SMIME') Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Shingo Fujimoto/Dave Marvit 3 draft-fujimoto-idip-00.txt Fujitsu Labs of America, Inc. 4 6 Aug 1998 6 IDentity Infrastructure Protocol (IDIP) 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as "work in progress." To view 19 the entire list of current Internet-Drafts, please check the "1id- 20 abstracts.txt" listing contained in the Internet-Drafts Shadow 21 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 22 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 23 ftp.isi.edu (US West Coast). 25 Copyright Notice 27 Copyright (C) The Internet Society (1998). All Rights Reserved. 29 Abstract 31 The IDentity Infrastructure Protocol (IDIP) is designed to support 32 a new class of services known as 'Identity Services'. These 33 constitute online extensions of a person's identity leading to the 34 formation of an 'extended individual'. IDIP supports the 35 coordinated communications between online identities (so called 36 IDOs) and facilitates the invocation of applications. This 37 document presents a specification for IDIP and provides some 38 examples. 40 Table of Contents 42 1. Introduction . . . . . . . . . . . . . . . 3 43 1.1. Overview of IDIP . . . . . . . . . . . . . 3 44 1.2. Terminology . . . . . . . . . . . . . . . 3 45 1.3. Definitions . . . . . . . . . . . . . . . 4 46 1.3.1. IDO server . . . . . . . . . . . . . . . 4 47 1.3.2. IDO (IDentity Object) . . . . . . . . . . . . 4 48 1.3.3. IDI (IDentity Infrastructure) . . . . . . . . . 4 49 1.3.4. IDI Control Channel. . . . . . . . . . . . . 4 50 1.3.5. Session . . . . . . . . . . . . . . . . 4 51 1.3.6. Function . . . . . . . . . . . . . . . . 5 52 1.3.7. ASC (Application Specific Channel) . . . . . . . 5 53 1.3.8. Function Enabler . . . . . . . . . . . . . 5 54 1.3.9. IDO Terminal . . . . . . . . . . . . . . . 5 55 1.4. Basic Operation . . . . . . . . . . . . . 5 56 2. Generic Grammar . . . . . . . . . . . . . . 6 57 2.1. Basic Rules . . . . . . . . . . . . . . . 6 58 2.2. IDIP Request . . . . . . . . . . . . . . . 7 59 2.3. IDIP Response . . . . . . . . . . . . . . 8 60 2.4. IDIP Data . . . . . . . . . . . . . . . . 8 61 3. IDIP Parameters . . . . . . . . . . . . . . 8 62 3.1. IDIP Version . . . . . . . . . . . . . . . 9 63 3.2. IDO-To and IDO-From . . . . . . . . . . . . 9 64 3.3. Content-Type . . . . . . . . . . . . . . . 10 65 3.4. Content-Length . . . . . . . . . . . . . . 10 66 3.5. Accept-Type . . . . . . . . . . . . . . . 10 67 3.6. IDIP-Authenticate . . . . . . . . . . . . . 10 68 3.6.1. Authenticate Style Parameter . . . . . . . . . 11 69 3.6.1a. Style Basic . . . . . . . . . . . . . . . 11 70 3.7. Keywords Parameter . . . . . . . . . . . . . 11 71 3.8. Location . . . . . . . . . . . . . . . . 11 72 4. IDIP Commands . . . . . . . . . . . . . . 12 73 4.1. START . . . . . . . . . . . . . . . . . 12 74 4.2. END , . . . . . . . . . . . . . . . . . 12 75 4.3. LIST . . . . . . . . . . . . . . . . . 12 76 4.4. CALL . . . . . . . . . . . . . . . . . 13 77 4.5. KILL . . . . . . . . . . . . . . . . . 13 78 4.6. ADD . . . . . . . . . . . . . . . . . . 13 79 4.7. DELETE . . . . . . . . . . . . . . . . . 13 80 4.8. PING . . . . . . . . . . . . . . . . . 14 81 5. Data description format for IDI function . . . . . 14 82 5.1. Name Property . . . . . . . . . . . . . . 14 83 5.2. Specification Property . . . . . . . . . . . 14 84 5.3. Accept Property . . . . . . . . . . . . . . 15 85 5.4. Keywords Property . . . . . . . . . . . . . 15 86 5.5. Location Property . . . . . . . . . . . . . 15 87 6. Media Type "application/sdp" . . . . . . . . . 15 88 7. Examples . . . . . . . . . . . . . . . . 15 89 7.1. Simple Negotiation . . . . . . . . . . . . . 15 90 7.2. Identify Caller . . . . . . . . . . . . . . 17 91 7.3. Filtering . . . . . . . . . . . . . . . 17 92 7.4. Adding an IDI function . . . . . . . . . . . 18 93 7.5. Giving temporary access . . . . . . . . . . . 18 94 8. Security Considerations . . . . . . . . . . . 20 95 9. Reference . . . . . . . . . . . . . . . . 21 96 10. Authors' Address . . . . . . . . . . . . . 22 98 1. Introduction 100 1.1. Overview of IDIP 102 The existence of an IDentity Infrastructure (IDI) will enable people 103 to manage and maintain their privacy while enhancing the power and 104 variety of services available. 106 The IDentity Infrastructure Protocol (IDIP) is an application-layer 107 protocol for "online presence" management that is central to IDI. 108 Using this protocol, IDentity Objects (IDOs) can communicate and 109 control the initiation of applications that provide various identity 110 services and functions. For the purpose of this protocol, each 111 "identity function" can be defined as a set of network connections. 112 IDIP can be used to "call" both human and non-human entities. 114 IDIP can be used to send and receive dynamically changing information 115 about "extended individuals" that exist online and are capable of 116 being evoked. As well IDIP can also be used to manage access to 117 information contained in IDOs. IDIP can be used to "filter" incoming 118 requests based on callee's preferences. 120 1.2. Terminology 122 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 123 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 124 and "OPTIONAL" are to be interpreted as described in RFC 2119 125 [KEYWORDS] and indicate requirement levels for compliant IDIP 126 implementations. 128 1.3. Definitions 130 The IDI system consists of several components as illustrated below. 132 +-------------+ IDI Control Channel +-------------+ +------------+ 133 | IDO server |=====================>| IDO server |<===>|IDO Terminal| 134 +-------------+ +-------------+ +------------+ 135 || IDI Control Channel || IDO server control 136 +-------------+ || (i.e. HTTP) 137 |Func. Enabler| || 138 +-------------+ || 139 || Invoke App. || Invoke App. 140 +-------------+ +-------------+ 141 | Application |<====================>| Application | 142 +-------------+ ASC +-------------+ 143 (Caller) (Callee) 145 This specification uses a number of terms to refer the components of 146 the system. 148 1.3.1. IDO server 150 An IDO server is the network component which can accept IDIP 151 calls. IDO server will be found from an IDO Address which will be 152 explained later. 154 1.3.2. IDO(IDentity Object) 156 The IDO is a logical component that is hosted by IDO servers. IDOs 157 can communicate using IDIP to establish "Application Specific 158 Channels" (described below). An IDO is hosted by an IDO server. Each 159 IDO has only one interface on the IDO server which is specified by an 160 IDO address. 162 1.3.3. IDI (IDentity Infrastructure) 164 IDI is an infrastructure to provide "Identity Services". Collectively 165 these will provide a rich online presence while enhancing both privacy 166 and richness of available services. 168 1.3.4. IDI Control Channel 170 An IDI Control Channel is used to connect IDOs. This channel is 171 always open and publicly accessible to accept incoming requests. 173 1.3.5. Session 175 A session is a continuous time period during which two IDOs 176 communicate and during which the requester (also known as the 177 "caller") has been identified as meriting authorization by the IDO 178 receiving the request (also known as the "callee"). The request 179 provides some form of authentication. Based upon the authentication 180 information provided by the requester, the IDO receiving the request 181 may allow complete access, partial access, or no access to the 182 requester. 184 1.3.6. Function 186 As described in this document, an IDI "function" is a set of network 187 connections called the "Application Specific Channel". A function is an 188 abstracted model of communication between caller and callee IDOs. 190 1.3.7. ASC (Application Specific Channel) 192 After negotiation between IDOs, applications will communicate through 193 Application Specific Channels (ASCs). These are established 194 out-of-band. (Here 'out-of-band' means outside the IDO Control 195 Channel.) Each application, or application type, will create its own 196 Application Specific Channel. The communication between applications 197 along ASCs is not part of the IDIP specification. 199 1.3.8. Function Enabler 201 The IDO may have a "Function Enabler" component. These components have 202 exactly same features as the IDO server. However, a Function Enabler 203 will only accept connections from authorized IDO. A Function Enabler 204 is the OPTIONAL component. 206 1.3.9. IDO Terminal 208 An IDO may have an "IDO Terminal", which can control the IDO's 209 behavior. One example of control and IDO's behavior is setting 210 filtering preferences. IDO Terminal is NOT part of the IDIP 211 specification. 213 1.4. Basic Operation 215 This section explains the basic protocol functionality and operation. 216 Callers and callees are identified by IDO addresses. 218 When an IDO starts a negotiation with another IDO, the caller first 219 locates the appropriate IDO server for the callee and connect to the 220 server. Next, the caller IDO issues a "START" command to the callee 221 IDO. This serves to specify callee IDO and to identify the 222 caller. Then the caller and callee IDOs can exchange commands and 223 responses until the IDIP connection is closed or until an "END" 224 command is issued. The caller IDO may issue a "LIST" command to 225 request a list of functions available to the callee. The caller may 226 also issue a "CALL" command to enable a specific IDO "function". The 227 connection that forms a "function" MAY terminate without an IDO's 228 control. To terminate the IDI function explicitly, the caller MAY 229 issue a "KILL" command to the callee IDO. 231 2. Generic Grammar 233 2.1. Basic Rules 235 The following rules are used throughout this specification to 236 describe basic parsing constructs. The US-ASCII coded character set 237 is defined by [US-ASCII]. 239 OCTET = 241 CHAR = 243 UPALPHA = 245 LOALPHA = 247 ALPHA = UPALPHA | LOALPHA 249 DIGIT = 251 CTL = 254 CR = 256 LF = 258 SP = 260 HT = 262 <"> = 264 IDIP defines the octet sequence CR LF as the end-of-line marker for 265 all protocol elements. 267 CRLF = CR LF 269 The TEXT rule is only used for descriptive field contents and values 270 that are not intended to be interpreted by the message parser. Words 271 of TEXT may contain octets from character sets other than US-ASCII. 273 TEXT = 275 Hexadecimal numeric characters are used in several protocol elements. 277 HEX = "A" | "B" | "C" | "D" | "E" | "F" 278 | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT 280 The special characters must be in a quoted string to be used within a 281 parameter value. 283 word = token | quoted-string 285 token = 1* 287 tspecials = "(" | ")" | "<" | ">" | "@" 288 | "," | ";" | ":" | " 289 | "/" | "[" | "]" | "?" | "=" 290 | "{" | "}" 292 A string of text is parsed as a single word if it is quoted using 293 double-quote marks. 295 quoted-string = ( <"> *(qdtext) <"> ) 297 qdtext = and CTLs> 299 Single-character quoting using the backslash ("\") character is not 300 permitted in IDIP. 302 2.2. IDIP Request 304 The caller IDO issues IDIP requests. 306 An IDIP request consists of command and data parts. The command part 307 contains a command method and a method argument. 309 IDIP-request = IDIP-command IDIP-parameters CRLF IDIP-data 311 IDIP-parameters = * (IDIP-parameter CRLF) 313 IDIP-command = start-command 314 | end-command 315 | list-command 316 | call-command 317 | kill-command 318 | add-command 319 | delete-command 320 | ping-command 322 2.3. IDIP Response 324 The callee IDO returns IDIP response. 326 The IDIP response consists of status and data parts. 327 The status part contains status code and its description. 329 IDIP-response = IDIP-status IDIP-data 331 IDIP-status = status-line IDIP-parameters 333 status-line = status-code SP status-description CRLF 335 status-code = success ; 1xx 336 | client-error ; 2xx 337 | server-error ; 3xx 338 | generic-error ; 4xx 340 success = "100" ; OK 342 client-error = "201" ; Authentication Error 343 | "202" ; Request Denied 345 server-error = "301" ; Invalid Callee 346 | "302" ; Server Internal Error 347 | "303" ; No Function Available 348 | "304" ; Cannot Provide Acceptable Data 349 | "305" ; Server Timeout 350 | "306" ; IDO Moved 351 | "307" ; Function Busy 353 generic-error = "401" ; Unknown Error 355 status-description = 1*TEXT 357 2.4. IDIP Data 359 IDIP Data is used to send media-typed([MEDIA TYPE]) data which is 360 required by an IDIP-request or an IDIP-response. 362 IDIP-data = * 364 3. IDIP Parameters 366 The IDIP request and response MAY contain one or more lines of IDIP 367 parameters. 369 IDIP-parameter = IDIP-version 370 | IDO-To 371 | IDO-From 372 | content-type 373 | content-length 374 | accept-type 375 | IDIP-authenticate 376 | keyword-parameter 377 | location-parameter 379 3.1. IDIP Version 381 IDIP uses a "." numbering scheme to indicate versions 382 of the protocol. The protocol versioning policy allows a sender to 383 indicate the compatibility of IDIP protocol interfaces. The 384 number is incremented when the new feature is added. And the 385 number is incremented when the format of a message within the 386 protocol is changed or when some features are disabled. If the IDIP 387 Version parameter is specified in the IDIP request, the IDO server 388 MUST include IDIP-Version Parameter in the IDIP response. The IDIfP 389 version described in this document is "1.0". 391 IDIP-Version = "IDIP-Version:" SP "IDIP" "/" 1*DIGIT "." 1*DIGIT 393 Note that the major and minor numbers should be treated as separate 394 integers and that each may be incremented higher than a single digit. 395 Thus, IDIP/2.4 is a lower version than IDIP/2.13, which in turn is 396 lower than IDIP/12.3. Leading zeros should be ignored by recipients 397 and never generated by senders. 399 3.2. IDO-To and IDO-From 401 The IDO address is used to specify both caller and callee IDOs. 403 IDO-To = "To:" SP IDO-Address 405 IDO-From = "From:" SP IDO-Address 407 IDO-Address = identity_name "@" host 409 identity_name = 1 * TEXT 411 host = 415 Note that the host which is specified in the "host" part must respond 416 to an IDIP request. There is no limitation for the length of an 417 identity name. However, IDO server MUST accept at least 1024 418 characters. 420 3.3. Content Type 422 The content type parameter can be used to indicate the media type of 423 data which is attached to an IDIP command or response. 425 content-type = "Content-Type:" SP media-type 427 IDIP uses Internet Media Types [MEDIA TYPE] in the Content-Type 428 parameter or Accept-Type parameter to provide open and extensible 429 data typing. 431 media-type = type "/" subtype *( ";" parameter ) 433 type = token 435 subtype = token 437 parameter = attribute "=" value 439 attribute = token 441 value = token | quoted-string 443 The type, subtype, and parameter attribute names are case- 444 insensitive. Parameter values may or may not be case-sensitive, 445 depending on the semantics of the parameter name. 447 3.4. Content-Length 449 The Content-Length parameter indicates the number of bytes in the 450 attached data. All IDIP requests and responses MUST include a 451 Content-Length parameter. 453 3.5. Accept Type 455 The Accept-Type parameter can be used to indicate a media which are 456 acceptable as a response to a request. This parameter may appear 457 multiple times to indicate a list of media. 459 accept-type = "Accept-Type:" SP media-type 461 3.6. IDIP Authenticate 463 When used by the IDIP caller, the IDIP-Authenticate parameter 464 specifies the authentication parameters. When used by the IDIP 465 callee, this parameter indicates which authentication parameters 466 should be specified by the caller. 468 IDIP-authenticate = "IDIP-Authenticate:" SP auth-options 470 auth-options = option *(; option ) 472 option = authenticate-style 474 3.6.1. Authenticate Style Option 476 The authenticate style option indicates which authentication style 477 will be used for authentication. Currently only "style basic" is 478 defined. 480 authenticate-style = "style" "=" value 482 3.6.1a. Style Basic 484 This style provides 'password' authentication. The IDIP-body is used 485 to send password data. 487 3.7. Keywords Parameter 489 The caller IDO MAY include a Keywords parameter with the LIST 490 command. The keywords are comma(',') delimited and SHOULD effect the 491 result of the LIST command. 493 keyword-parameter = "Keywords:" SP keywords 495 keywords = keyword * ("," keywords) 497 keyword = token | quoted-string 499 3.8. Location 501 In the event that an IDO has changed its server location, the old 502 location IDO server MAY generate Location parameter to show the new 503 location of callee IDO. 505 location-parameter = "Location:" SP location 507 location = IDO-Address 509 4. IDIP Commands 511 4.1. START 513 This command is used to specify which IDO to call. At the same time, 514 the caller IDO may add authentication information to identify itself. 516 start-command = "START" CRLF 518 Both IDO-To and IDO-From parameter MUST be specified. 520 IDOs SHOULD send an IDIP-authenticate parameter to prompt or to pass 521 the authentication information in START command or response. 523 If the session is successfully established between IDOs, status "100 524 OK" will be returned. If the callee IDO is invalid, status "301 525 Invalid Callee" will be returned. If the caller IDO is the account 526 which is required further authentication, status "201 Authentication 527 Error" will be returned. And if the callee IDO has changed its 528 server location, status "306 IDO Moved" will be returned with 529 Location parameter. 531 4.2. END 533 This command is used to shut down the connection initiated by the 534 START command. The END command declares that the specified function 535 should shut down. It is RECOMMENDED that session are ended by issuing 536 an END command. 538 end-command = "END" CRLF 540 For this command, the IDO server MUST returns "100 OK". 542 4.3. LIST 544 This command returns the list of functions that are available to be 545 called on by the callee IDO. 547 list-command = "LIST" CRLF 549 The caller IDO MAY use the Keywords parameter to return a list of 550 matched IDI-function entries. 552 If the request is successfully accepted by the IDO server, status 553 "100 OK" will be returned. If the list of functions was empty, "303 554 No Function Available" will be returned. 556 4.4. CALL 558 This command is used to activate a function. The response to a CALL 559 command may contain a set of parameters relevant to the function 560 being called. The CALL command takes one argument, a IDI function 561 name. This IDI function name comes from a result of the LIST 562 command. This command MAY be issued by the IDO server to the 563 Function Enabler. 565 call-command = "CALL" SP function-name CRLF 567 function-name = word 569 If the function specified is successfully invoked, status "100 OK" 570 will be returned. If the function is not registered, "303 No Function 571 Available" will be returned. 573 4.5. KILL 575 This command is used to explicitly terminates a function which 576 activated by the previous CALL command. If the function specified is 577 successfully KILLed, "100 OK" will be returned. If the function is 578 not existed, "303 No Function Available" will be returned. And if the 579 function is not successfully KILLed, "302 Internal Error" will be 580 returned. 582 kill-command = "KILL" SP function-name CRLF 584 4.6. ADD 586 This command is used to add an entry to the list of functions that 587 can be returned in response to a LIST command. Only the Function 588 Enablers can issue a ADD command. 590 add-command = "ADD" CRLF 592 If the function specified is successfully added, "100 OK" will be 593 returned. If a request comes from an unauthorized IDO, status "202 594 Request Denied" will be returned. And if the function is not 595 successfully added, "302 Internal Error" will be returned. 597 4.7. DELETE 599 This command is used to delete an entry from the list of functions 600 that can be returned in response to a LIST command. Only the 601 Function Enablers can issue a DELETE command. If the IDI function 602 specified is successfully deleted, status "100 OK" will be returned. 603 If the function is not existed. status "303 No Function Available" 604 will be returned. 606 delete-command = "DELETE" function-name CRLF 608 4.8. PING 610 This command is used to determine if the specified function is 611 available. If the IDI function specified is available, status "100 612 OK" will be returned. If the function still running, but is busy, 613 "307 Function Busy" will be returned. If the function was invoked, 614 but timed out, "305 Server Timeout" will be returned. And if the 615 function is not successfully invoked, "302 Internal Error" will be 616 returned. 618 ping-command = "PING" function-name CRLF 620 5. Data description format for IDI function 622 A custom data format is used to respond to a LIST command or to 623 describe a function in a ADD command. This data format is specified 624 as "application/x-idi-function" on the Content-Type parameter. 626 IDI-function = "" *property "" 628 property = name-prop ; Name Property 629 | accept-prop ; Accept Property 630 | spec-prop ; Specification Property 631 | keywords-prop ; Keywords Property 632 | location-prop ; Location Property 634 5.1. Name Property 636 A Name property contains a unique string identifier used to specify 637 an IDI function. 639 name-prop = "" function-name "" 641 5.2. Specification Property 643 A Specification property contains one of the standards commonly 644 supported on the Internet. 646 spec-prop = "" *( "" standard-name "" ) "" 647 | "" standard-name "" 649 standard-name = token 651 5.3. Accept Property 653 The Accept property contains media-types [MEDIA TYPE] will be 654 accepted as an IDIP-data part. 656 accept-prop = "" *( "" media-type "" ) "" 657 | "" media-type "" 659 5.4. Keywords Property 661 The Keywords property contains string keywords which will be used at 662 Keywords parameter in a LIST command. 664 keywords-prop = "" *( "" keyword "" ) "" 665 | "" keyword "" 667 5.5. Location Property 669 The Location property contains URL[URL] to declare function locations 670 explicitly. A Location property MAY be specified by a Function 671 Enabler. 673 location-prop = "" url "" 675 url = 677 6. Application Specific Channel 679 Application Specific Channels (ASCs) will be opened by an IDO. 681 IDO servers use the SDP[SDP] format to provide the necessary 682 information to establish network connections associated with ASCs. 684 7. Examples 686 7.1. Simple Negotiation 688 Alice(alice@ido.foo.com) wants to talk with Bob(bob@ido.foo.com) 689 using "video phone". Alice's IDO(IDO-A) connects to Bob's IDO(IDO-B) 690 and starts negotiation. They are engaging in peer-to-peer 691 communication. 693 [Start session from IDO-A] 694 START 695 IDIP-Version: IDIP/0.9 696 From: alice@ido.foo.com 697 To: bob@ido.foo.com 698 Content-Length: 0 700 [from IDO-B] 701 100 OK 702 IDIP-Version: IDIP/0.9 703 Content-Length: 0 705 [from IDO-A] 706 LIST 707 Accept-Type: application/x-idi-function 708 Accept-Type: multipart/mixed 709 Accept-Type: multipart/alternative 710 keyword: video, phone 711 Content-Length: 0 713 [from IDO-B] 714 100 OK 715 Content-Type: application/x-idi-function 716 Content-Length: 83 718 719 video phone 720 h.323 721 723 [from IDO-A] 724 CALL "video phone" 725 Accept-Type: application/sdp 726 Accept-Type: multipart/mixed 727 Accept-Type: multipart/alternative 728 Content-Length: 0 730 [form IDO-B] 731 100 OK 732 Content-Type: application/sdp 733 Content-Length: 60 735 v=0 736 c=IN IP4 133.164.59.101 737 m=application 20450 udp 0 739 [form IDO-A] 740 END 741 Content-Length: 0 743 [form IDO-B] 744 100 OK 745 Content-Length: 0 747 [End session] 749 7.2. Identify Caller 751 IDO-A identifies itself. 753 [Start session from IDO-A] 754 START 755 IDIP-Version: IDIP/0.9 756 From: alice@ido.foo.com 757 To: bob@ido.foo.com 758 Content-Length: 0 760 [from IDO-B] 761 201 IDIP/0.9 Authentication Error 762 IDIP-Version: IDIP/0.9 763 IDIP-Authenticate: style=basic 764 Content-Length: 0 766 [from IDO-A] 767 START 768 Version: IDIP/0.9 769 From: alice@ido.foo.com 770 To: bob@ido.foo.com 771 IDIP-Authenticate: style=basic 772 Content-Type: application/octet-stream 773 Content-Length: 7 775 (7byte data is here) 777 [from IDO-B] 778 100 OK 779 IDIP-Version: IDIP/0.9 780 [continue negotiation] 782 7.3. Filtering 784 Bob(IDO-B) does not want to communicate via "video phone" with 785 Charley(IDO-C), even though IDO-B has the capability of accepting a 786 "video phone" connection. 788 [Start session from IDO-C] 789 START 790 IDIP-Version: IDIP/0.9 791 From: charley@ido.foo.com 792 To: bob@ido.foo.com 793 Content-Length: 0 795 [from IDO-B] 796 100 OK 797 Version: IDIP/0.9 798 Content-Length: 0 800 [from IDO-C] 801 LIST 802 IDIP-Version: IDIP/0.9 803 Accept-Type: application/x-idi-function 804 Accept-Type: multipart/mixed 805 Accept-Type: multipart/alternative 806 keyword: video, phone 807 Content-Length: 0 809 [from IDO-B] 810 303 No Function Available 811 IDIP-Version: IDIP/0.9 812 Content-Length: 0 814 [continue negotiation] 816 7.4. Adding an IDI function 818 Bob(bob@ido.foo.com) wants to register an entry for a function named 819 "ftp data receive". 821 [After identification, from Function Enabler (FE-B)] 822 ADD 823 Content-TYpe: application/x-idi-function 825 826 ftp data receive 827 ftp server 828 830 [from IDO-B] 831 100 OK 832 Content-Length: 0 834 [continue ...] 836 7.5. Giving temporary access 838 Alice(alice@ido.foo.com) wants to send binary data to 839 Bob(bob@ido.foo.com) using ftp. 841 [After Identification, from IDO-A] 842 LIST 843 Accept-Type: application/x-idi-function 844 Accept-Type: multipart/mixed 845 Accept-Type: multipart/alternative 846 keyword: ftp 847 Content-Length: 0 849 [from IDO-B] 850 100 OK 851 Content-Type: multipart/mixed; boundary="----- =_NextPart_0001303033304" 852 Content-Length: 457 854 ----- =_NextPart_0001303033304 855 Content-Type: application/x-idi-function 856 Content-Length: 92 858 859 ftp data receive 860 ftp server 861 863 ----- =_NextPart_0001303033304 864 Content-Type: application/x-idi-function 865 Content-Length: 125 867 868 ftp data send 869 ftp client 870 application/sdp 871 873 ----- =_NextPart_0001303033304 875 [from IDO-A] 876 CALL "ftp data receive" 877 Accept-Type: application/sdp 878 Accept-Type: multipart/parallel 879 Accept-Type: multipart/alternative 880 Content-Type: application/sdp 881 Content-Length: 0 883 [form IDO-B] 884 100 OK 885 Content-Type: application/sdp 886 Content-Length: 71 888 v=0 889 u=ftp://guest1:openSesame@133.164.59.101/incoming/X080711.data 891 [form IDO-A] 892 END 893 Content-Length: 0 895 [form IDO-B] 896 100 OK 897 Content-Length: 0 899 [End session] 901 After this negotiation, IDO-A has the information required to access 902 IDO-B's ftp server(133.164.59.101), account "guest1", password 903 "openSesame". 905 When the CALL request was issued by IDO-A, IDO-B forwarded the 906 request to its Function Enabler. 908 [from IDO-B after identify itself] 909 CALL "ftp data receive" 910 Content-Type: application/x-idi-function 911 Content-Length: 0 913 [from Function Enabler] 914 100 OK 915 Content-Type: application/sdp 916 Content-Length: 71 918 v=0 919 u=ftp://guest1:openSesame@133.164.59.101/incoming/X080711.data 921 [ftp server on the terminal is now ready to receive data] 923 Note that the result was also forwarded to IDO-A by IDO-B as response 924 from IDO-A. 926 8. Security Considerations 928 To prevent the caller from violating callee's privacy, an IDO server 929 SHOULD provide some high level authentication mechanism to identify 930 the caller. 932 Furthermore, some of IDI communications pass sensitive information, 933 including password and other private information. In such cases the 934 IDO server SHOULD use some encryption system such as TLS[TLS] or 935 S/MIME[SMIME]. 937 9. References 939 [KEYWORDS] S. Bradner, "Key words for use in RFCs to indicate 940 requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 941 1997. 943 [US-ASCII] US-ASCII. Coded Character Set - 7-Bit American Standard 944 Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 945 1986. 947 [MEDIA TYPE] Postel, J., "Media Type Registration Procedure." RFC 948 1590, USC/ISI, March 1994. 950 [MIME] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet 951 Mail Extensions) Part One: Mechanisms for Specifying and Describing 952 the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, 953 September 1993. 955 [URL] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform 956 Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation, 957 University of Minnesota, December 1994. 959 [SDP] M. Handley and V. Jacobson, "SDP: session description 960 protocol," RFC 2327, Internet Engineering Task Force, Apr. 1998. 962 [TLS] Tim Dierks, "The TLS protocol Version 1.0" Internet-Draft 963 Consensus Development, Nov. 1997. 965 [SMIME] S. Dusse, "S/MIME Version 2 Message Specification" RFC 2311, 966 RSA Data Security, Mar. 1998 968 10. Authors' Address 970 Shingo Fujimoto 971 Fujitsu Labs of America, Inc. 972 595 Lawrence Expressway 973 Sunnyvale, CA 94086 U.S.A. 975 Fax: +1 (408) 530 - 4515 976 EMail: shingo@fla.fujitsu.com 978 Dave Marvit 979 Fujitsu Labs of America, Inc. 980 595 Lawrence Expressway 981 Sunnyvale, CA 94086 U.S.A. 983 Fax: +1 (408) 530 - 4515 984 EMail: dave@marvit.org 986 #