idnits 2.17.1 draft-smith-java-appl-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. Expected boilerplate is as follows today (2024-04-26) 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 6 months document validity. ** 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 12 longer pages, the longest (page 5) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages -- Found 13 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** 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 an Authors' Addresses Section. ** There are 18 instances of too long lines in the document, the longest one being 72 characters in excess of 72. ** There are 19 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 64 has weird spacing: '...nd Java to pr...' == Line 70 has weird spacing: '...Manager from...' == Line 244 has weird spacing: '...terface csiC...' -- 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 (20 November 1996) is 10019 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 section? '1' on line 127 looks like a reference -- Missing reference section? '2' on line 129 looks like a reference -- Missing reference section? '3' on line 136 looks like a reference -- Missing reference section? '-n' on line 360 looks like a reference -- Missing reference section? '-x' on line 336 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T.G.Smith 3 INTERNET-DRAFT Gecko Software 4 Expire in six months 20 November 1996 6 Orbit Shadow TM - Data Transport Protocol 7 for 8 Java Thin Client Applications 9 to access 10 Network Management Platforms 12 14 _1. _S_t_a_t_u_s _o_f _t_h_i_s _M_e_m_o 16 This document is an Internet-Draft. Internet-Drafts are working docu- 17 ments of the Internet Engineering Task Force (IETF), its areas, and 18 its working groups. Note the other groups may also distribute working 19 documents as Internet-Drafts. 21 Internet Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite the other than as "work in progress". 26 To learn the current status of any Internet-Draft, please check the 27 "lid-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.oc.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 _2. _A_b_s_t_r_a_c_t 34 _2._1. _I_n_t_e_r_e_s_t 36 This document is of interest to vendors of network management platforms 37 and network management applications, for the management of intranets, 38 private internetworks and the public Internet. 40 _2._2. _S_t_a_t_u_s _R_e_p_o_r_t 42 This is the first submission of this RFC. 44 _2._3. _P_r_o_t_o_c_o_l 46 This protocol is an application layer protocol for the interchange of 47 data between a network management server and a network management 48 client application. The protocol is intended to be used in operating 49 system independant implementations of "thin" client applications. 50 This protocol is currently implemented by one manufacturer - Gecko 52 RFC nnnn Orbit Shadow - Protocol Specification November 1996 54 Software, but is being placed in the public domain as it is of 55 interest to other manufacturers dealing with network management 56 issues. 58 _3. _I_n_t_r_o_d_u_c_t_i_o_n _t_o _O_R_B_I_T 60 A GeckoWare product from Gecko Software 62 ORBIT is an architecture that integrates information technology 63 management platforms, the World Wide Web, HTML browser applications 64 and Java to provide operating system independant access to mission 65 critical management information. Designed to be used with enterprise 66 systems and network management platforms such as 68 SPECTRUM from Cabletron Systems 69 HP OpenView from Hewlett Packard 70 SunNET Manager from Sun Microsystems 72 ORBIT Planet provides a public domain Java API to access information 73 on a remote management platform, using the ORBIT Star server. The 74 ORBIT Star and Satellite are Java powered, and communicate using 75 ORBIT Shadow an application layer protocol that is implemented using 76 TCP/IP sockets. Any Java compatabile application, specifically HTML 77 browsers, can implement Java applets that access management applica- 78 tion information through ORBIT Planet, Shadow and Star. 80 _3._1. _O_R_B_I_T _S_t_a_r 82 A server application (daemon) that co-exists with the management 83 application, or remote from the management application where sup- 84 ported by the API or CLI. ORBIT Star accepts API or CLI calls from 85 one or more ORBIT Satellites vi a ORBIT Shadow. These calls are 86 passed to the management application by ORBIT Star and the results 87 passed back to the relevant ORBIT Planet. 89 _3._2. _O_R_B_I_T _P_l_a_n_e_t 91 A public domain Java package, consisting of class, method and inter- 92 face definitions that implement the Application Program Interfaces or 93 Command Line Interfaces of a management application. Communication 94 with a management application is through ORBIT Shadow to an ORBIT 95 Star. 97 _3._3. _O_R_B_I_T _S_h_a_d_o_w 99 An application layer protocol, implemented uding TCP/IP sockets, that 101 RFC nnnn Orbit Shadow - Protocol Specification November 1996 103 controls data requests and responses between ORBIT Stars and ORBIT 104 Planets. 106 _4. _U_s_e _C_a_s_e _f_o_r _O_r_b_i_t _S_h_a_d_o_w 108 An example of the application of Orbit Shadow is given as a use case. 109 In this use case, the Orbit implementation is Orbit for SPECTRUM8r9, 110 Cabletron Systems, Inc, enterprise management system. Fred, a net- 111 work Manager, wishes to be able to view the state of all Cisco 112 routers in his company's network using the Netscape browser that he 113 has installed on his Apple Macintosh. Fred asks Cathy, an applica- 114 tion programmer, to build him an application to perform this func- 115 tion. 117 Cathy designs a series of Java applets that Fred will access from an 118 page on their corporate WWW server. One of the applets that she 119 writes needs to be able to query the state of a specific router (a 120 managed object).Cathy uses Orbit Planet as the interface to interro- 121 gate a SPECTRUM system, installed on their network, as to the state 122 of the required router. 124 Orbit Planet (a public domain Java package) provides Cathy with 125 object classes, methods and interfaces to interrogate and update her 126 SPECTRUM server, using an Orbit Star application on the SpectroSERVER 127 host[1]. Cathy includes the Orbit Planet Java packages in her applet 128 that needs to be able to query the state of a specific router. When 129 the relevant method is invoked[2] Orbit Shadow packages the request 130 into an Orbit Shadow protocol frame and communicates the request to 131 the relevant Orbit Star. From the above, you can see that Orbit Sha- 132 dow is embedded in Orbit Planet. There is also a corresponding Orbit 133 Shadow embedded in Orbit Star. When this Orbit Shadow receives the 134 request from Cathy's applet, it executes the request and returns the 135 data to the applet. To execute the request, Orbit Star calls the 136 relevant SPECTRUM interface[3], parses and formats the resulting out- 137 put before handing the data to Orbit Shadow. Orbit Shadow packages 138 the data into an Orbit Shadow protocol frame and communicates the 139 response to the relevant Orbit Planet. 141 END-NOTES 142 --------- 143 1 Orbit Star - SPECTRUM does not necessarily have to co- 144 reside with a SpectroSERVER. V1.x of Orbit Star - SPECTRUM 145 uses the SPECTRUM Command Line Interface and can reside on a 146 separate host to the SpectroSERVER, provided that the 147 SPECTRUM CLI is installed on the same host as Orbit Star - 148 SPECTRUM. Compatabile versions of SpectroSERVER and 150 RFC nnnn Orbit Shadow - Protocol Specification November 1996 152 SPECTRUM CLI can be on different Operating System platforms, 153 which implies that Orbit Star - SPECTRUM can be deployed on 154 a different host operating system to that of the 155 SpectroSRVER. 156 2 The method that corresponds to the SPECTRUM Command Line 157 Interface (CLI) show attributes [mh=] 158 attr= 159 3 This would be the same interface as invoked by the Orbit 160 Planet method in footnote 2. 162 _5. _P_r_o_t_o_c_o_l _D_e_f_i_n_i_t_i_o_n 164 _5._1. _F_r_a_m_e _S_t_r_u_c_t_u_r_e 166 An Orbit Shadow protocol frame contains the fields set out in "Table 167 1 - Orbit Shadow Protocol Frame". 169 Field number Field descriptor 170 8 ______________________________________________________________ 171 0 version 172 1 sequence 173 2 command 174 3 final 175 4 platform 176 5 interface 177 6 database 178 7 object 179 8 attribute 180 9 attribute type 181 10 value 183 Table 1 - Orbit Shadow Protocol Frame 185 Each of the fields in the protocol frame are described below. 187 _5._1._1. _V_e_r_s_i_o_n 189 The field version identifies the revision of Orbit Shadow that is in 190 use. The field is an signed integer value with a length of eight (8) 191 bits. 193 _5._1._2. _S_e_q_u_e_n_c_e 195 The field sequence is used ensure that information sent between the 196 Orbit Star and the Orbit Planet remains in sequence. The field is a 197 signed integer value with a length of thiry-two (32) bits. 199 9 201 RFC nnnn Orbit Shadow - Protocol Specification November 1996 203 _5._1._3. _C_o_m_m_a_n_d 205 The command field identifies the protocol action to be carried out by 206 the receipient of the protocol frame. The defined commands are 208 Command Abbreviation Integer Value 209 8 ______________________________________________________________________________________________________ 210 authorise AUTH 0 211 request REQ 1 212 response RES 2 213 positive acknowledge ACK 3 214 negative acknowledge NACK 4 215 wait WAIT 5 216 terminate TERM 6 218 Table 2 - Defined values for field: command 220 These commands are implemented in the protocol frame as a signed 221 integer value with a length of eight (8) bits. Detailed examples of 222 the use of these commands is given in section "Protocol State Model". 224 _5._1._4. _F_i_n_a_l 226 The final field is a boolean flag, implemented as a single bit. This 227 flag is set to true (1) if the protocol frame is the last frame for 228 the specified command and is set to false (0) if the frame is not the 229 last frame in an exchange for a specified command. This flag is used 230 when sending bulk data in a request or a response. 232 _5._1._5. _P_l_a_t_f_o_r_m 234 The platform field defines the network or systems management platform 235 that Orbit Star interfaces with and is implemented as an signed 236 integer of length eight (8) bits. Currently defined values for plat- 237 form are 239 Value Application Platform Abbreviation 240 8 ____________________________________________________________________________________________________________________________________________ 241 -128 Reserved - - 242 .. 243 -1 Reserved - - 244 0 Cabletron SPECTRUM Command Line Interface csiCLI 245 1 Cabletron SPECTRUM SSAPI ver 4.0 csiSSAPI 247 RFC nnnn Orbit Shadow - Protocol Specification November 1996 249 Value Application Platform Abbreviation 250 8 ____________________________________________________________________________________________________________________________________________ 251 2 SunNET Manager - sunNET 252 3 Sun Solstice - sunENT 253 Enterprise Manager 254 4 HP Network Node - hpNNM3 255 Manager ver 3.x 256 5 HP Network Node - hpNNM4 257 Manager ver 4.x 259 Table 3 - Defined values for field: platform 261 _5._1._6. _I_n_t_e_r_f_a_c_e 263 The field interface defines the specific interface on the specified 264 platform that this protocol frame refers to and is implemented as a 265 signed integer eight (8) bits in length. Interface values are unique 266 when used in conjunction with a specific platform value. Currently 267 defined values for the field "interface" are set out in Table 4. The 268 "interface" values for platform "csiCLI" use the typographical con- 269 ventions from the SPECTRUM "Command Line Interface User Guide". 271 Platform Interface Interface 272 Value Description 273 8 ______________________________________________________________________________________________________________________ 274 csiCLI 000 reserved 275 csiCLI 001 connect [hostname] 276 [lh=landscape_handle] 277 csiCLI 002 disconnect 278 csiCLI 003 ack alarm aid=alarm_id 279 [lh=landscape_handle] 280 csiCLI 004 create alarm 281 cond=alarm_condition 282 cause=alarm_cause 283 mh=model_handle 284 csiCLI 005 create association 285 rel=relation 286 lmh=left_model_handle 287 rmh=right_model_handle. 288 csiCLI 006 create event 289 type=event_type 290 text=event_text 291 [mh=model_handle | 292 lh=landscape_handle ] 293 csiCLI 007 create model 294 mth=model_type_handle 295 [attr=attribute_id, 296 val=value ...] 298 RFC nnnn Orbit Shadow - Protocol Specification November 1996 300 Platform Interface Interface 301 Value Description 302 8 ______________________________________________________________________________________________________________________ 303 [lh=landscape_handle] 304 csiCLI 008 current [mh=model_handle | 305 lh=landscape_handle ] 306 csiCLI 009 destroy alarm [-n] 307 aid=alarm_id 308 [lh=landscape_handle] 309 csiCLI 010 destroy association [-n] 310 rel=relation 311 lmh=left_model_handle 312 rmh=right_model_handle. 313 csiCLI 011 destroy model [-n] 314 mh=model_handle 315 csiCLI 012 jump [text_string] 316 csiCLI 013 seek attr=attribute_id, 317 val=value 318 [lh=landscape_handle] 319 csiCLI 014 setjump [-n] text_string 320 csiCLI 015 show alarms [-x] 321 [mh=model_handle | 322 lh=landscape_handle ] 323 csiCLI 016 show associations 324 [mh=model_handle] 325 csiCLI 017 show attributes 326 [attr=attribute_id 327 [,iid=instance_id][,next]] 328 [attr=attribute_id 329 [,iid=instance_id][,next]...] 330 [mh=model_handle] 331 csiCLI 018 show attributes 332 mth=model_type_handle 333 [lh=landscape_handle] 334 csiCLI 019 show children [rel=relation] 335 [mh=model_handle] 336 csiCLI 020 show events [-x] 337 [mh=model_handle | 338 lh=landscape_handle ] 339 csiCLI 021 show inheritance 340 mth=model_type_handle 341 [lh=landscape_handle] 342 csiCLI 022 show models [lh=landscape_handle] 343 csiCLI 023 show parents [rel=relation] 344 [mh=model_handle] 345 csiCLI 024 show relations [lh=landscape_handle] 346 csiCLI 025 show rules rel=relation 347 csiCLI 026 show types [lh=landscape_handle] 348 csiCLI 027 show landscapes 350 RFC nnnn Orbit Shadow - Protocol Specification November 1996 352 Platform Interface Interface 353 Value Description 354 8 ______________________________________________________________________________________________________________________ 355 csiCLI 028 update [mh=model_handle] 356 attr=attribute_id 357 [,iid=instance_id],val=value 358 [attr=attribute_id 359 [,iid=instance_id],val=value...] 360 csiCLI 029 update [-n] 361 mth=model_type_handle 362 attr=attribute_id,val=value 363 [attr=attribute_id,val=value...] 364 [lh=landscape_handle] 366 Table 4 - Defined values for field: interface 368 _5._1._7. _D_a_t_a_b_a_s_e 370 The field database defines the target database on the platform for 371 which the interface is to be invoked, and is implemented as a signed 372 integer thirty two (32) bits in length. This field is used when the 373 target platform supports distributed databases or has multiple data 374 sources. The usage of this field is dependant on the value of plat- 375 form. The semantic definitions for database that are currently 376 defined are 378 Platform Semantic value of database 379 8 __________________________________________________________________________________________________________________________ 380 csiCLI SPECTRUM VNM Landscape Handle 381 csiSSAPI SPECTRUM VNM Landscape Handle 383 Table 5 'Defined Values for field: database' 385 _5._1._8. _O_b_j_e_c_t 387 The field object defines an object in the "database" on the "plat- 388 form", and is implemented as an signed integer thirty two (32) bits 389 in length. The semantic value of object is specific for each plat- 390 form. The semantic definitions for object that are currently defined 391 are 393 Platform Semantic value of object 395 RFC nnnn Orbit Shadow - Protocol Specification November 1996 397 8 __________________________________________________________________________________________________________ 398 csiCLI SPECTRUM VNM model handle 399 csiSSAPI SPECTRUM VNM model handle 401 Table 6 'Defined values for field: object' 403 _5._1._9. _A_t_t_r_i_b_u_t_e 405 The field attribute defines an attribute of an object, and is imple- 406 mented as a signed integer thirty two (32) bits in length. The seman- 407 tic value of attribute is specific for each platform. The semantic 408 definitions for object that are currently defined are 410 Platform Semantic value of attribute 411 8 __________________________________________________________________________________________________________________________ 412 csiCLI SPECTRUM VNM attribute handle 413 csiSSAPI SPECTRUM VNM attribute handle 415 Table 7 'Defined values for field: attribute' 417 _5._1._1_0. _A_t_t_r_i_b_u_t_e _T_y_p_e 419 The field "attribute type" describes the data type implemented by the 420 "attribute". This field is implemented as a signed integer eight (8) 421 bits in length. The Orbit Shadow protocol uses primitive data types 422 as defined by Sun Microsystem's Java TM programming language. The 423 definition of these primitive data types can be found at 425 http://www.javasoft.com 427 Field Value Data type 428 8 __________________________________________________ 429 0 Boolean 430 1 Char 431 2 Integer 432 3 Long 433 4 Float 434 5 Double 435 6 String 437 Table 8 'Defined values for field: attribute type' 438 9 440 RFC nnnn Orbit Shadow - Protocol Specification November 1996 442 _5._1._1_1. _V_a_l_u_e 444 The field value contains the data which is the value of the attribute 445 specified in the Orbit Shadow protocol frame, and is implemented as a 446 variable length sequence of bytes. 448 _5._2. _P_r_o_t_o_c_o_l _S_t_a_t_e _M_o_d_e_l 450 _5._2._1. _O_v_e_r_v_i_e_w 452 The exchange of Orbit Shadow frames between an Orbit Star and an 453 Orbit Planet is described by a series of data flow diagrams. Data 454 exchange between the Orbit Planet and Orbit Star is asynchronous and 455 bi-directional, and is always initiated by an Orbit Planet. For every 456 exchange that is initiated by an Orbit Planet, an Orbit Star will 457 reply with either a positive or negative acknowledgement. A session 458 between an Orbit Planet and an Orbit Star is initiated with a user 459 authentication exchange, followed by a sequence of requests and 460 responses. The session is not necessarily explicitly terminated, but 461 can be terminated by the Orbit Planet, or the Orbit Star. 463 _5._2._2. _S_e_s_s_i_o_n _I_n_i_t_i_a_t_i_o_n 465 A session between an Orbit Planet and an Orbit Star requires that 466 user authentication take place at least once, before any other 467 requests are serviced. If no authentication has occured, then the 468 Orbit Star will deny service to the Orbit Planet. Table 9 "Initial 469 state - no authorisation", shows the protocol exchange where an Orbit 470 Star denies service when no authentication has taken place. 472 Frame Orbit Planet Orbit Star Frame detail 473 8 ______________________________________________________________________________________________________ 474 1 REQ object=<..>, 475 attribute=<..>, 476 value=.. 478 2 NACK object=<..>, 479 attribute=<..>, 480 value=.. 482 Table 9 "Initial state - no authorisation" 484 An authorisation exchange is shown in Table 10 "Initial state - 485 authorisation exchange". In this exchange, both the user name and the 487 RFC nnnn Orbit Shadow - Protocol Specification November 1996 489 user password are accepted by the Orbit Star as valid. 491 Frame Orbit Planet Orbit Star Frame detail 492 8 ____________________________________________________________________________________________________________________________ 493 1 AUTH object=null, 494 attribute=, 495 value=user name 496 2 ACK object=, 497 attribute=, 498 value=user name 499 3 AUTH object=, 500 attribute=, 501 value=password 502 4 ACK object=, 503 attribute=, 504 value=password 506 Table 10 "Initial state - authorisation exchange" 508 If either the user name or user password is invalid, the Orbit Star 509 will send a negative acknowledgement of the authentication request. 510 An example of this is shown in 512 Frame Orbit Planet Orbit Star Frame detail 513 8 ____________________________________________________________________________________________________________________________ 514 1 AUTH object=null, 515 attribute=, 516 value=user name 517 2 ACK object=, 518 attribute=, 519 value=user name 520 3 AUTH object=, 521 attribute=, 522 value=password 523 4 NACK object=, 524 attribute=, 525 value=password 527 Table 11 "Initial state - authentication failure" 529 _5._2._3. _R_e_s_q_u_e_s_t _A_n_d _R_e_s_p_o_n_s_e 531 After the Orbit Planet has successfully identified the end-user to 532 the Orbit Star, requests for access to the Orbit Star platform 534 RFC nnnn Orbit Shadow - Protocol Specification November 1996 536 interfaces can be made. On receiving a request, the Orbit Star will 537 acknowledge that the request is to be serviced, or refuse the request 538 through a negative acknowledgement. Table 12 "Request - service 539 refusal" shows the protocol exchange when the Orbit Star refuses to 540 service an Orbit Planet request. 542 Frame Orbit Planet Orbit Star Frame detail 543 8 ______________________________________________________________________________________________________ 544 1 REQ object=<..>, 545 attribute=<..>, 546 value=.. 547 2 NACK object=<..>, 548 attribute=<..>, 549 value=.. 551 Table 12 "Request - service refusal" 553 Assuming that the Orbit Star is able to service the request from the 554 Orbit Planet, the exchange might be as set out in Table 13 "Request - 555 simple response". 557 Frame Orbit Planet Orbit Star Frame detail 558 8 ________________________________________________________________________________________________________________ 559 1 REQ object=<..>, 560 attribute=<..>, 561 value=.. 562 2 ACK object=<..>, 563 attribute=<..>, 564 value=.. 565 3 RES object=<..>, 566 attribute=<..>, 567 value=.. 568 4 ACK object=<..>, 569 attribute=<..>, 570 value=.. 572 Table 13 "Request - simple response" 574 _5._2._4. _S_e_s_s_i_o_n _T_e_r_m_i_n_a_t_i_o_n 576 To be completed. 578 RFC nnnn Orbit Shadow - Protocol Specification November 1996 580 _6. _S_e_c_u_r_i_t_y _C_o_n_s_i_d_e_r_a_t_i_o_n_s 582 There is a possible requirement for encryption of passwords in the 583 user authentication exchange in session initiation. 585 _7. _R_e_f_e_r_e_n_c_e_s 587 _8. _A_u_t_h_o_r'_s _A_d_d_r_e_s_s 589 Tony Gordon Smith 590 Gecko Software 591 17 Paragon Place 592 Blackheath 593 London 594 SE3 0SP 595 United Kingdom 597 Phone: +44-(0)700 0GECKO 598 +44-(0)700 043256 599 Fax: +44-(0)700 740175 600 EMail: tony@geckoware.com