idnits 2.17.1 draft-frystyk-httpng-arch-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-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. ** 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 1 longer page, the longest (page 1) being 1119 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 54 instances of too long lines in the document, the longest one being 25 characters in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 847: '...IntegerLiteral = OPTIONAL NonNegativeN...' RFC 2119 keyword, line 936: '...ltDescriptions = OPTIONAL REFERENCE Me...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1006 has weird spacing: '...rotocol w3n...' -- 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 (1 August 1998) is 9398 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: 'RFC2277' is mentioned on line 483, but not defined == Unused Reference: 'Java RMI' is defined on line 1071, but no explicit reference was found in the text == Unused Reference: 'RFC 2277' is defined on line 1074, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CORBA' -- Possible downref: Non-RFC (?) normative reference: ref. 'DCOM' -- Possible downref: Non-RFC (?) normative reference: ref. 'HTTP-ng-goals' -- Possible downref: Non-RFC (?) normative reference: ref. 'HTTP-ng-interfaces' -- Possible downref: Non-RFC (?) normative reference: ref. 'HTTP-ng-webmux' -- Possible downref: Non-RFC (?) normative reference: ref. 'HTTP-ng-wire' -- Possible downref: Non-RFC (?) normative reference: ref. 'ILU' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISL' -- Possible downref: Non-RFC (?) normative reference: ref. 'Java RMI' ** Obsolete normative reference: RFC 2068 (Obsoleted by RFC 2616) -- Possible downref: Non-RFC (?) normative reference: ref. 'PEP' Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Bill Janssen, Xerox PARC 2 Henrik Frystyk Nielsen, W3C 3 Internet Draft Mike Spreitzer, Xerox PARC 4 expires in six months 1 August 1998 6 HTTP-ng Architectural Model 8 10 Status of this Document 11 *********************** 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, and 15 its working groups. Note that other groups may also distribute working 16 documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress." 23 To view the entire list of current Internet-Drafts, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 26 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 27 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 29 This document has been produced as part of the W3C HTTP-ng Activity 30 (for current status, see 31 "http://www.w3.org/Protocols/HTTP-NG/Activity"). This is work in 32 progress and does not imply endorsement by, or the consensus of, either 33 W3C or members of the HTTP-ng Protocol Design Working Group. We expect 34 the document to evolve considerably as the project continues. 36 Distribution of this document is unlimited. Please send comments to 37 the HTTP-NG mailing list at . Discussions 38 are archived at "http://www.w3.org/Protocols/HTTP-NG/". 40 Please read the "HTTP-NG Short- and Longterm Goals" [HTTP-ng-goals] 41 for a discussion of goals and requirements of a potential new 42 generation of the HTTP protocol and how we intend to evaluate these 43 goals. 45 Abstract 46 ******** 48 This document defines the architectural model for a new HTTP 49 framework called HTTP-ng, along with a set of terms for referring to 50 parts of it. 52 Table Of Contents 53 ***************** 55 1. Introduction 56 2. Overview of 57 3. Architecture of an HTTP-ng-based Web 58 4. The HTTP-ng Type System 59 4.1. Type IDs 60 4.2. Identifiers 61 4.3. The Boolean Type 62 4.4. Enumerated Types 63 4.5. Numeric Types 64 4.5.1. Fixed-point Types 65 4.5.2. Floating-point Types 66 4.6. String Types 67 4.7. Sequence Types 68 4.8. Array Types 69 4.9. Record Types 70 4.10. Union Types 71 4.11. The Pickle Type 72 4.12. Reference Types 73 4.13. Object Types 74 4.13.1. Supertypes and Inheritance 75 4.13.2. Methods 76 4.13.3. State 77 4.13.4. The HTTP-ng.RemoteObjectBase Type 78 4.13.5. Distributed Garbage Collection of Objects 79 4.14. The HTTP-ng.TypeReference Type 80 5. Application Program Architectures 81 6. References 82 7. Address of Authors 84 1. Introduction 85 **************** 87 This document describes a new architecture for HTTP, and the part of 88 the World Wide Web that is built on top of the HTTP infrastructure. 89 This work has been motivated by some observations about the current 90 HTTP 1.x infrastructure. 92 HTTP began as a generic request-response protocol, designed to 93 accommodate a variety of applications ranging from document exchange 94 and management to searching and forms processing. As HTTP has 95 developed, though, the request for extensions and new features has 96 exploded; such extensions range from caching, distributed authoring and 97 content negotiation to various remote procedure call mechanisms. By not 98 having a modularized architecture, the price of new features has been 99 an overly complex and incomprehensible protocol with the following 100 drawbacks: 102 * Complexity 103 Even though HTTP/1.1 provides a number of interesting features it 104 does not provide a clean framework for defining their interaction. 105 This has resulted in the large and complex HTTP specification. 107 * Poor Extensibility 108 Acknowledging a large number of proposed extensions as part of the 109 core protocol has stretched HTTP/1.1. The interactions between the 110 extensions are complex at best, often unspecified or even broken. 112 * No Application Deployment Model 113 Many applications and services are being deployed on the web that 114 are not, in fact, retrieval of documents. Some applications are 115 tunnelled through HTTP but would be more appropriately deployed as 116 applications of a distributed object systems. Tunnelling itself 117 is being done in a variety of different ways, which causes 118 problems for firewalls and other filtering intermediaries. The 119 proliferation of application deployment schemes has increased 120 developer confusion over how to use the Web. 122 * Alternative Technologies 123 Alternative distributed-application deployment technologies, such 124 as DCOM, CORBA, and Java RMI, have proposed different models of 125 application development which don't integrate well with the 126 current HTTP. As a result, these protocols have come to use HTTP 127 and the Web either as a `initialization service', delivering some 128 startup code and/or application which then uses a non-Web 129 technology, or as an expensive, albeit widespread, reliable 130 datagram delivery service. These very similar distributed object 131 systems tend to find different solutions to the same problems, 132 which again increases overhead and decreases interoperability. 134 * Poor Scalability 135 At the time it was designed, the HTTP/1.0 protocol still 136 represented a very low fraction of today's Internet traffic. 137 Caching and connection management has improved HTTP/1.1 but recent 138 measurements show that the protocol overhead can still be much 139 improved in terms of CPU and network efficiency. 141 These concerns have driven the design of the HTTP-ng architecture. 142 The basic approach is to define a layered HTTP framework which provides 143 both a Web distributed-object system, and transport layers which 144 address the interaction with other Internet protocols. The layering 145 allows modularization of the implementation framework, so that the 146 effect of changes in one part of the system have minimal impact on 147 other parts of the system. The distributed-object system allows 148 application-specific interfaces to be defined, and provides an 149 application deployment model; it keeps different applications from 150 interfering with each other. The distributed-object system itself 151 provides the core functionality of the distributed-object systems 152 defined by DCOM, CORBA, and Java RMI; the intent is to make it directly 153 usable by those technologies so that tunnelling becomes unnecessary. 154 Elements of this architecture have been drawn from HTTP 1.1 [RFC 2068], 155 ILU [ILU], PEP [PEP], DCOM [DCOM], CORBA [CORBA], and Java RMI [Java 156 RMI]. 158 2. Overview of Distributed Object Systems 159 ****************************************** 161 Remote or distributed applications typically have a defined 162 interface; this consists of a set of operations which participants in 163 the application invoke on other participants. These operations 164 typically are defined in terms of input parameters and output results; 165 sometimes exceptional results, or exceptions, are also specified for 166 the operation. In standard Internet usage, an application such as 167 Telnet or FTP is described in a document which specifies an abstract 168 model of operation, and enumerates the operations by describing the 169 form of a message which conveys that operation when marshalled onto an 170 appropriate transport substrate. Some Internet standards define an 171 application framework, which is a set of general information that 172 applies to a family of applications, related by all using that 173 framework. The RFC 1831 for RPC is such a framework specification. 174 Finally, some specifications, such as HTTP, define both a framework, 175 and a particular application (the Web), which uses that framework. It 176 does this by defining an extensible system of messages in a 177 request/response context, then defines several specific messages 178 (`GET', `HEAD', `POST', etc.) and the context of a distributed 179 application that uses them. 181 +----------+ +----------+ 182 | | operation invocation | | 183 | Caller |>----------------------------------->| Server | 184 | (client) |<-----------------------------------<| (callee) | 185 | | operation result | | 186 +----------+ +----------+ 188 Figure 2a. Elements of a Distributed Application 190 Though there may be many participants or threads of control in the 191 application, they conventionally engage in two-party interactions. 192 These two parties can be categorized as the caller or client, which is 193 the participant which invokes an operation, and the callee, or server, 194 which is the participant implementing or responding to the operation. 195 When there are many participants in the applications, the role each 196 plays may shift continuously. These participants are said to reside in 197 different compatibility domains; the distributed application serves as 198 a bridge between these domains. There is some essential element which 199 separates the domains; it is typically the fact that the participants 200 are on different computers, but it may also be other factors such as 201 that the two participants are operating under the aegis of different 202 security principals, or are implemented in different programming 203 languages. 205 Distributed object systems are application frameworks that try to 206 simplify and optimize the definition and use of an application. They 207 typically have an interface definition language (often called IDL), 208 which make it easier to talk about the components of an interface. 209 They often have standards for marshalling the parts of a message into 210 binary forms, or for discovering resources, or for recovering from 211 certain types of errors, or for exporting the interface defined in 212 their IDL to a particular programming language for use in a larger 213 program. This separation of concerns allows each part of the 214 application framework to be small and cohesive, but allows the 215 development of large applications. They allow the different 216 participants to interact with each other having only limited, but 217 precise, understanding of the other participants' capabilities. 219 Some distributed object systems use the procedure call as a metaphor 220 of operation; these are called RPC systems. Others use a messaging 221 model, and are typically called messaging systems. Some modern 222 distributed object systems have support for both RPC and messaging. 224 In a typical distributed-object system, an interface definition 225 consists of a set of inter-related types, exceptions, and methods. 226 Methods are packaged in object types, developed with a partitioning of 227 them according to object-oriented methodologies. A callee is 228 represented by an instance of an object type. Operations are invoked 229 on the callee by calling one of its methods. If the caller of a method 230 and the callee of the method exist in different compatibility domains, 231 they are connected with a connection, which carries messages back and 232 forth between the compatibility domains, and has an associated protocol 233 and transport stack. The message is the basic unit of communication; 234 the connection's protocol specifies the set of messages which can be 235 sent, and their syntax; the connection's transport stack, which 236 typically consists a series of individual transport elements, specifies 237 how the messages are carried between the two domains. Most protocols 238 define two distinguished messages, a request message, which invokes a 239 service in the callee, and a response message, which provides a 240 response about an invocation back to the caller, along with some other 241 control messages used to synchronize state between the two domains. We 242 typically distinguish between transport elements called transport 243 filters, which modify the bits of message passing through them 244 (encryption, compression, etc.) and other elements transport 245 endpoints, which actually convey the message to a different 246 compatibility domain (TCP/IP, UDP/IP, etc.). 248 An implementation of an object type is called a class. An 249 implementation of one or more of the object types defined in an 250 interface, along with whatever additional code is necessary to perform 251 any ancillary tasks such as creating initial instances of a class, or 252 registering instances with a name service, is called a module. A 253 program typically consists of several modules, each of contains one or 254 more classes which implement object types, either by dispatching 255 messages to a module exported from another compatibility domain 256 (classes which do this are called surrogate classes), or by directly 257 performing the functionality of the object type (classes which do this 258 are called true classes). Programs which tend to have many true 259 classes and relatively few surrogate classes are typically called 260 servers, and programs which have few true classes and relatively many 261 surrogate classes are typically called clients; these terms should be 262 used with caution, since they are only appropriate in a specific 263 context. A server is typically made available by a publisher, which is 264 the principal responsible for the services encapsulated in the true 265 instances of object types provided by the module. The principal 266 responsible for accessing the services provided by the publisher is 267 sometimes known as the user. 269 3. Architecture of an HTTP-ng-based Web 270 *************************************** 272 In the HTTP-ng architecture, the Web is defined as an application on 273 top of the HTTP-ng framework. A typical HTTP-ng application would be 274 layered as described in Section 2. The lowest layer, the transport 275 layer, would typically (but not necessarily always) consist of a series 276 of transport elements. A simple layering might consist of a MUX 277 [HTTP-ng-webmux] transport filter over a TCP/IP transport endpoint; a 278 more complicated transport layering might introduce layers concerned 279 with connection management, security, compression, or other issues. 281 The MUX layer seems particularly useful; it is used to provide 282 multiple connections over a single TCP/IP connection, bi-directional use 283 of the TCP/IP connection for callbacks, and message-marking for the 284 higher layers. We call the MUX connection a session to distinguish it 285 from TCP/IP connections. Similarly, we call the MUX port (the thing to 286 which MUX connections are made, like a TCP/IP port), a channel, to 287 similarly distinguish it. The set of MUX channels which can be 288 connected to over a TCP/IP connection to a particular IP host machine 289 is called a "MUX endpoint". Typically, this endpoint identifies a 290 particular address space or process on an IP host. Note that a single 291 MUX endpoint (and all the MUX channels at that endpoint) may be 292 available via a number of different TCP ports. This means that the TCP 293 port used in the transport stack does not explicitly identify a set of 294 MUX channels; rather, the set of MUX channels are identified by the MUX 295 endpoint. 297 The next layer, the operation invocation layer, would consist of the 298 object-oriented HTTP-ng messaging protocol, which maximizes use of 299 protocol features found to be successful in existing Internet protocols. 300 This layer is a generic messaging layer - it does not provide any 301 application-specific services like security or caching, or any other 302 application layer functionality. It does provide an extensible and 303 regular mechanism for forming and handling messages described by 304 application-level interfaces without knowledge of semantic information 305 that is application-specific. It provides a standard type system for 306 defining application interfaces. It provides a distributed 307 garbage-collection facility which can be used for automatic management 308 of application objects. This layer also has associated machinery which 309 allows automated uses of interface descriptions written in an interface 310 description language, such as client-stub-code and 311 implementation-skeleton generation. This layer may use a number of 312 different, but equivalent, protocols; we expect the major one will be 313 the efficient binary wire protocol [HTTP-ng-wire] defined in this suite 314 of documents, but any protocol that properly supports the HTTP-ng type 315 system can be used. 317 Given this protocol framework, the Web application is defined at the 318 third and highest layer, the application layer. This layer is 319 "application-specific", meaning that it varies from application to 320 application. For example, "The Classic Web Application" (TCWA) would 321 have a different layer here than the WebDAV application (though they 322 might share some common part). The HTTP-ng architecture allows 323 multiple applications to co-exist at this level, and provides a 324 mechanism to add new applications easily without disturbing existing 325 applications. The Web application is defined both statically, in terms 326 of the type system at the second layer, and dynamically, in terms of 327 the transport elements of the first layer. An associated document 328 provides an initial sketch of what the interface definition for the Web 329 application might look like [HTTP-ng-interfaces]. 331 4. The HTTP-ng Type System 332 *************************** 334 Interfaces for applications are defined with a "type system". This 335 section describes the proposed type system for HTTP-ng. It consists of 336 two kinds of types, "primitive types" and "constructed types". Only 337 two primitive types, or pre-defined types, are included, boolean and 338 pickle. All other types are constructed from parameters and other 339 types using "constructors", like sequence types and record types. Note 340 that this type system provides support for both statically typed 341 interfaces, and, with the pickle type, dynamically typed interfaces. 343 Note: This section currently uses the interface specification 344 language ILU ISL [ISL]; it is not meant to be prescriptive. Any other 345 interface language which captures this type system could be used 346 instead. We expect that current widely used interface definition 347 languages, such as DCOM MIDL or OMG IDL, will be adapted for use with 348 HTTP-ng. 350 4.1. Type IDs 351 ============== 353 All types have a single associated universally and globally unique 354 identifier, called the "type ID", which can be expressed as a URI. 355 Type IDs from different UUID spaces may be mixed. An implementation of 356 the type system should allow explicit identification of type IDs with 357 types, but should also provide a default type ID for every type in a 358 consistent and predictable fashion. [ We need to define the algorithm 359 here. ] 361 4.2. Identifiers 362 ================= 364 The rules governing the syntax of identifiers are the same as for 365 Standard C; that is, uppercase and lowercase alphabetic characters and 366 digits from the ASCII character set, along with the underscore 367 character, may be used, and the first character of the identifier must 368 be an alphabetic character. Case is significant. 370 4.3. Boolean Types 371 =================== 373 The single boolean type, the primitive type boolean, has exactly two 374 values, `True' and `False'. 376 4.4. Enumerated Types 377 ====================== 379 An enumerated type is an abstract type the values of which are 380 explicitly specified. It is specified with one parameter, a set of 381 values, specified as identifiers. Enumerated types are not numeric 382 types, and the values of an enumerated type do not have intrinsic 383 numeric values associated with them; however, some programming 384 languages may use numeric types to represent enumerated types. 386 4.5. Numeric Types 387 =================== 389 The type system includes two different kinds of numeric types, 390 "fixed-point" and "floating-point". All numeric types are constructed; 391 that is, there are no pre-defined "primitive" integer or floating-point 392 types. 394 4.5.1. Fixed-point Types 395 ------------------------- 397 A fixed-point type is defined with three parameters: a denominator, a 398 maximum numerator value, and a minimum numerator value. These define a 399 series of rational values which make up the allowable values of that 400 fixed-point type. The numerator and denominator are integer values; 401 the denominator is either a positive integer value greater than zero, 402 or the reciprocal of a positive integer value greater than zero. Each 403 value of a fixed-point type abstractly exists as a rational number with 404 a numerator in the range specified for numerators, and a denominator of 405 the specified denominator value. For example, one could define a 406 fixed-point type which would cover the 16-bit unsigned integer space 407 with a denominator of one (all integer types have denominators of one), 408 a maximum numerator of 65535 and a minimum numerator of zero. One 409 could define a fixed-point type `dollars' for business purposes with a 410 denominator of 100 (two decimal places for `cents'), a maximum 411 numerator of 100000000 (1 million dollars) and a minimum numerator of 412 -100000000 (1 million dollars). There are no limits on the sizes of 413 denominators, maximum numerators, or minimum numerators. 415 We use this approach, instead of specifying a procrustean flock of 416 predefined integer types as in DCOM or CORBA, to simplify the underlying 417 system in several ways. 418 1. Small applications can handle all fixed-point values of a 419 particular type as `bignum' value (the numerator), and not have to 420 have any special-case code for any primitive integer types. 421 However, any primitive integer types they care about can be 422 special-cased and handled efficiently. 424 2. This approach also supports the CORBA `fixed' data type, but does 425 so more effectively by additionally providing for non-decimal 426 fixed-point fractional types: types such as sixteenths can also 427 be defined directly for stock market applications by using a 428 denominator of 16, while egg producers can also deal in dozens by 429 specifying a denominator of 1/12. 431 3. Programming language mappings of this type system can special-case 432 those integer types they support internally directly, and handle 433 all other fixed-point types in a generic fashion. This eliminates 434 the need to `shoehorn' some numeric types into language types not 435 quite right for them, such as the representation of CORBA 436 `unsigned' types in the Java programming language. 438 4.5.2. Floating-point Types 439 ---------------------------- 441 Floating-point types are specified with eight parameters: 442 * the size in bits of the significand, 444 * the base of the exponent, 446 * the maximum exponent value, 448 * the minimum exponent value, 450 * whether they support a distinguished value for `Not-A-Number', 452 * whether they support a distinguished value for `Infinity', 454 * whether denormalized values are allowed, and 456 * whether the zero value is signed (whether they can have both +0 457 and -0). For instance, the floating point type usually described 458 as IEEE 32-bit floating-point has the parameters significand-size=24, 459 exponent-base=2, maximum-exponent-value=127, 460 minimum-exponent-value=-126, has-Not-A-Number=TRUE, has-Infinity=TRUE, 461 denormalized-values-allowed=TRUE, and has-signed-zero=TRUE; the 462 floating point type usually described as IEEE 64-bit floating-point has 463 the parameters significand-size=53, exponent-base=2, 464 maximum-exponent-value=1023, minimum-exponent-value=-1022, 465 has-Not-A-Number=TRUE, has-Infinity=TRUE, 466 denormalized-values-allowed=TRUE, and has-signed-zero=TRUE. We expect 467 that interface description languages for the HTTP-ng type system will 468 provide shorthand notation for certain floating-point type patterns, 469 such as those corresponding to IEEE single and double precision 470 floating point. 472 We use this approach because CORBA and similar systems have a 473 problem in that they have no way to represent the variety of floating 474 point numbers available, particularly the different variants of IEEE 475 `extended'. In addition, this system allows representation of older 476 floating-point types still in wide circulation, such as IBM, VAX, and 477 CRAY floating-point, in an simple fashion. 479 4.6. String Types 480 ================== 482 "String" types are defined with two parameters: the maximum length 483 in bytes of the string values, and the language [RFC2277] used in the 484 string. If no language is specified, the language defaults to the 485 Internet default language `"i-default"'. The maximum length must be 486 less than or equal to 0x7FFFFFFE, or it may also be omitted, in which 487 case a maximum length of 0x7FFFFFFE (2^31-2) is used. The character 488 set (or sets) used in the string is that identified by the string's 489 language. The codeset used in representations of the string is not 490 specified at this level. This type system does not have any 491 representation for individual characters or character codes; integer 492 types should be used for that purpose. 494 [ Note that there is no such thing as a "NULL string", as occurs in 495 C or C++. However, a similar type can be constructed with the optional 496 type constructor, using a string type as the base type. ] 498 4.7. Sequence Types 499 ==================== 501 Sequence types are variable-length one-dimensional arrays of some 502 other type. They are defined with two parameters: the "base" type of 503 the sequence, and optionally a maximum number of values in the 504 sequence, which must be a value less than or equal to `0x7FFFFFFE'. If 505 no maximum length is specified, a default maximum length of 506 `0x7FFFFFFE' is assumed. 508 4.8. Array Types 509 ================= 511 Array types are fixed-length multi-dimensional arrays of some other 512 type. They are defined with two parameters: the "base" type of the 513 sequence, and a sequence of dimensions, each of which is an integer 514 value less than or equal to `0x7FFFFFFE'. Arrays are in row-major 515 order. 517 4.9. Record Types 518 ================== 520 A record type is defined with a single parameter, a sequence of 521 fields. Each field is specified with an identifier, unique within the 522 scope of the record type, and a type. 524 4.10. Union Types 525 ================== 527 Union types are defined with a single parameter, a set of fields. 528 Each field is specified with an identifier, unique within the scope of 529 the union type, and a type for the field. The same type may be used 530 multiple times for different fields of the union. The value of a union 531 type with N fields consists of a single value of the type of one of the 532 fields, and an unsigned integer value in the range [0..N-1] identifying 533 which field is represented. 535 4.11. Pickle Type 536 ================== 538 A special type that can hold a value of any other type is known as 539 the pickle type. This type essentially provides an escape mechanism 540 from the static typing of the HTTP-ng type system; every pickle value 541 is dynamically typed. A value stored in a pickle has a standard 542 representation as a sequence of octet values; this representation of 543 the value of the pickle may be accessed as used as an externalized form 544 of the value. Pickles are opaque, by which we mean that the value 545 stored in a pickle cannot be manipulated directly, but only through a 546 procedural interface. 548 [ This is similar to the `any' type in CORBA, but also provides a 549 standard externalization form for values. The opacity of the pickle 550 also provides important marshalling efficiency gains over the `any'. ] 552 4.12. Reference Types 553 ====================== 555 Reference types are specifically designed to support recursion 556 through the type system, and must be mapped to a pointer type of some 557 type in those programming languages which distinguish between value 558 types and pointer types. Each use of a reference type constructor adds 559 another level of indirection. Reference types are defined with a 560 parameter, another type, called the base type of the reference type, 561 and two optional modifiers optional and aliased. Thus it's possible to 562 have non-aliased non-optional reference types, optional non-aliased 563 reference types, non-optional aliased reference types, and optional 564 aliased reference types. 566 If the reference type is declared optional, a value of the reference 567 type may be either NIL or a value of its base type. This type allows 568 the description of data structures like binary trees. 570 If the reference type is declared aliased, the reference type is 571 distinguished in that multiple references to the same value of an 572 aliased type in a single `scope' will be passed between compatibility 573 domains as a single value. This avoids the problem in some type 574 systems of converting graph data structures to trees when transferring 575 them between compatibility domains. 577 The scope of an aliased type varies depending on its use. When a 578 value of an aliased type is being sent as an input or output parameter 579 in a method call, the scope of the type is the whole message in which 580 the value is being sent; that is, the invocation or result of the 581 method call. When it is being pickled, the scope of the value type is 582 the pickle. 584 [ These types effectively cover the practical uses of reference 585 types in the CORBA objects-by-value spec, the Java RMI spec, and the 586 DCE RPC / DCOM system. ] 588 4.13. Object Types 589 =================== 591 In the HTTP-ng type system, operations are modeled as method calls 592 on an instance of an object type which supports that method. There are 593 two kinds of object types, "local" and "remote". Instances of remote 594 object types have a global identity, and are always passed between 595 compatibility domains by reference; the original object value is called 596 the "true instance", and references to that true instance are called 597 "surrogate instances". Passed instances of any remote object type are 598 always surrogate instances, except in the compatibility domain of the 599 true instance, where it will be the true instance. Instances of local 600 object types have no global identity, and are always passed between 601 compatibility domains by copying the "state" of the local instance to 602 the new compatibility domain, where a new instance of that object type 603 (or a subtype of the object type) is created from the state. A local 604 instance in one compatibility domain and copy of that local instance in 605 a different compatibility domain have no explicit association after the 606 copy has been made. The behavior of a local object type must be 607 provided locally, but it may be provided statically at link time, or 608 dynamically at runtime via dynamic loading of class code, as is done in 609 Java RMI. The HTTP-ng system does not define any particular system for 610 dynamic loading of behavior. 612 Both local and remote object types are defined by specifying three 613 parameters: a sequence of supertypes, a sequence of methods, and the 614 state of the object type. Note that the ordering of the elements of 615 each of these parameters is significant. Any of these parameters may be 616 empty. 618 [ Note that there is no such thing as a "NIL object", as occurs in 619 the CORBA system. However, an equivalent construct may be obtained 620 where necessary by using the optional type constructor, using an object 621 type as the base type. ] 623 4.13.1. Supertypes and Inheritance 624 ----------------------------------- 626 Each object type may have one or more object types as supertypes. 627 An object type with supertypes is said to "inherit" the methods and 628 state of its supertypes, which means that it provides all of the 629 methods provided by any of its supertypes, and any of their supertypes, 630 and so forth. An object type may occur more than once in the supertype 631 inheritance graph of an object type. Note that the inheritance 632 provided in this model is that of interface inheritance. In 633 particular, it does not guarantee or prohibit polymorphic dispatching 634 of methods. 636 Object types may be "sealed". A sealed object type may not be used 637 as a supertype for another object type. 639 4.13.2. Methods 640 ---------------- 642 A "method" is a way of invoking an operation on an instance of an 643 object type. Each HTTP-ng method has a three required parameters: a 644 synchronization attribute which may either be "synchronous" or 645 "asynchronous"; an identifier, unique within the scope of the object 646 type, called the "method name"; and an "invocation", which is specified 647 as a sequence of named and typed input parameters. Synchronous methods 648 may also have additional parameters: a "normal result", which is 649 specified as a sequence of named and typed output parameters, and zero 650 or more "exceptional results", each specified as a sequence of named 651 and typed output parameters. Exceptional results should only be used 652 to describe results that occur infrequently, as the overhead of 653 handling exceptional results in most programming languages that support 654 them is higher than the overhead of handling a normal result. Input 655 parameters and output parameters are each specified with an identifier, 656 unique within the scope of the method, and a type. [ Note additional 657 restriction on the names of exception parameters. ] 659 Asynchronous methods transfer the invocation parameters to the 660 compatibility domain of the true instance, and invoke the operation. 661 The caller-side control flow for an asynchronous method returns to the 662 caller of an asynchronous method after the message has been handed to a 663 reliable transport mechanism for transfer to the compatibility domain 664 of the true instance; the remote method itself may not be executed for 665 an arbitrary length of time after that return. Asynchronous methods 666 may be thought of as "messages". 668 Synchronous methods transfer the invocation parameters of the method 669 to the compatibility domain of the true instance, where the method is 670 invoked as a local method on that instance. The result from that 671 invocation, normal or exceptional, is transferred back to the caller's 672 compatibility domain, if different, and returned as the result of the 673 method. 675 [ Do we need some set of `standard' exceptions? If so, what are 676 they? A small starting list might be: 677 * communications failure - underlying failure in the message 678 transport subsystem 680 * no such object - server can't identify instance on which the 681 method was invoked 683 * bad type - object doesn't have type specified in operation 684 identifier 686 * no such type - type specified in operation identifier unknown at 687 server 689 * internal local before - something in the middleware system failed 690 in this compatibility domain, before the invocation was attempted 692 * internal local after - something in the middleware system failed 693 in this compatibility domain, after a result was received 695 * internal remote before - something in the middleware system failed 696 in the remote compatibility domain, before the invocation was 697 attempted 699 * internal remote after - something in the middleware system failed 700 in the remote compatibility domain, after the invocation of the 701 true method had begun ] 703 4.13.3. State 704 -------------- 706 Each object type may have state associated with it. The state of an 707 object type is specified as a sequence of attributes, where each 708 attribute has an identifier unique within the scope of the object type, 709 and an associated type. When an instance of this object type is passed 710 between compatibility domains, the values of these attributes are 711 passed. This is the normal way of passing the state of a local object 712 type. [ TBD - for remote object types, the state may act as the 713 initial values for surrogate instance caching of remote object state, 714 or as a way of passing immutable metadata about the instance with the 715 object reference.] 717 Attribures may also be marked as "public" or "private". This has no 718 effect on their handling at the lower levels of the system, but may 719 influence the way in which mappings to programming languages deal with 720 them. For example, a programming language object type might provide 721 public accessors for public attributes, but not for private attributes. 723 4.13.4. The HTTP-ng.RemoteObjectBase Type 724 ------------------------------------------ 726 All remote object types must inherit directly or indirectly from the 727 object type HTTP-ng.RemoteObjectBase. 729 INTERFACE HTTP-ng BRAND "http-ng.w3.org"; 730 ... 731 TYPE UUIDString = STRING LANGUAGE "i-default" 732 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/UUIDString"; 734 TYPE TypeIDTreeNode = RECORD 735 type-id : UUIDString, 736 "supertypes" : InheritanceHierarchy 737 END TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/TypeIDTreeNode"; 739 TYPE TypeIDTreeNodeRef = ALIASED REFERENCE TypeIDTreeNode 740 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/TypeIDTreeNodeRef"; 741 TYPE InheritanceHierarchy = SEQUENCE OF TypeIDTreeNodeRef 742 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/InheritanceHierarchy"; 744 TYPE RemoteObjectBase = OBJECT 745 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/RemoteObjectBase" 746 METHODS 747 GetTypeHierarchy () : TypeIDTreeNodeRef 748 "Returns the type ID hierarchy for the object, rooted 749 at the most-derived type of the object" 750 END; 751 ... 753 4.13.5. Distributed Garbage Collection of Objects 754 -------------------------------------------------- 756 A simple form of garbage collection is defined for HTTP-ng objects. 757 If an object type inherits from HTTP-ng.GCCollectibleObjectBase, a 758 module that implements objects of that type expects clients holding 759 surrogate instances to register with it, passing an instance of a 760 callback object. When a client finishes with the surrogate, the client 761 unregisters itself. Thus the server may maintain a list of clients 762 that hold surrogate instances. If no client is registered for an 763 object, and the object has been dormant (had no methods called on it by 764 a client from a different compatibility domain) for a period of time 765 T1, the module may feel free to garbage collect the true instance. T1 766 is determined both by human concerns and network performance: T1 is 767 set long enough to allow useful debugging of a client, and longer than 768 the typical transmission delay between all participants in a program. 770 To deal with possible failure of a client process, we introduce 771 another time-out parameter. If an instance with registered clients has 772 been dormant for a period of time T2, the server uses the callback 773 instance associated with each client to see if the client still exists. 774 If the client cannot be contacted for the callback, the server may 775 remove it from the list of registered clients for that instance. 777 Object types which participate in distributed garbage collection 778 must inherit from HTTP-ng.GCCollectibleObjectBase. 780 INTERFACE HTTP-ng BRAND "http-ng.w3.org"; 781 ... 782 TYPE Seconds = FIXED-POINT DENOMINATOR=1 783 MIN-NUMERATOR=0 MAX-NUMERATOR=0xFFFFFFFF 784 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/Seconds"; 786 TYPE GCCallBackObject = OBJECT SUPERTYPES RemoteObjectBase END 787 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/GCCallBackObject" 788 METHODS 789 StillInterested (obj : GCCollectibleObjectBase) : BOOLEAN 790 "Should return TRUE if the callback object is still interested in 791 using the remote object 'obj', FALSE otherwise. An error return 792 is counted as a FALSE return." 793 END; 795 TYPE GCCollectibleObjectBase = OBJECT SUPERTYPES RemoteObjectBase END 796 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/GCCollectibleObjectBase" 797 METHODS 798 RegisterGCInterest (user : GCCallBackObject) 799 "Indicates that the caller, indicated by the 'user' parameter, is 800 interested in using the object, and should be considered a reference 801 for the purposes of distributed garbage collection. This may be 802 called multiple times with the same 'user' parameter, but only one 803 reference per distinct 'user' parameter will be registered.", 804 UnregisterGCInterest (user : GCCallBackObject) 805 "Indicates that the caller, indicated by the 'user' parameter, is 806 no longer interested in using the object, and should no longer be 807 considered a reference for the purposes of distributed garbage 808 collection. It is not an error to call this for objects which have 809 not previously registered interest.", 810 GetTimeoutParameters(OUT t1 : Seconds, OUT t2 : Seconds) 811 "Returns the T1 and T2 garbage collection parameters used by the 812 server.", 813 Ping() 814 "Can be used by surrogate users of the instance to refresh the T1 815 timeout of the instance, and prevent server-side outcalls to the 816 callback object." 817 END; 818 ... 820 4.14. The `HTTP-ng.TypeReference' Type 821 ======================================= 823 It's often useful to have a standard data representation for the 824 description of a type. CORBA, for example, defines the pseudo-type 825 `Typecode', which is defined to be a type which makes various 826 attributes of the description of another type available to the 827 application program. Rather than defining a pseudo-type, the HTTP-ng 828 interface simply defines a representation of a type description in the 829 type system itself. Many other possible ways of representing the type 830 description are also possible; the type `HTTP-ng.TypeReference' is 831 defined as a convenience. 832 INTERFACE HTTP-ng BRAND "http-ng.w3.org"; 833 ... 834 TYPE Identifier = STRING LANGUAGE "i-default" 835 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/Identifier"; 837 TYPE PrimitiveTypeDescription = ENUMERATION "boolean", "pickle" END 838 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/PrimitiveTypeDescription"; 840 TYPE EnumeratedTypeDescription = SEQUENCE OF Identifier 841 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/EnumeratedTypeDescription"; 843 TYPE IntegerLiteral = FIXEDPOINT DENOMINATOR 1 844 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/IntegerLiteral"; 845 TYPE NonNegativeNonZeroIntegerLiteral = FIXEDPOINT MIN-NUMERATOR 1 DENOMINATOR 1 846 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/NonNegativeNonZeroIntegerLiteral"; 847 TYPE OptionalNonNegativeNonZeroIntegerLiteral = OPTIONAL NonNegativeNonZeroIntegerLiteral 848 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/OptionalNonNegativeNonZeroIntegerLiteral"; 850 TYPE FixedPointTypeDescription = RECORD 851 "denominator" : NonNegativeNonZeroIntegerLiteral, 852 denominator-reciprocal : BOOLEAN, 853 "min-numerator" : OptionalNonNegativeNonZeroIntegerLiteral, 854 "max-numerator" : OptionalNonNegativeNonZeroIntegerLiteral 855 END TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/FixedPointTypeDescription"; 857 TYPE FloatingPointTypeDescription = RECORD 858 significand-size : NonNegativeNonZeroIntegerLiteral, 859 exponent-base : NonNegativeNonZeroIntegerLiteral, 860 min-exponent : IntegerLiteral, 861 max-exponent : IntegerLiteral, 862 has-Not-A-Number : BOOLEAN, 863 has-Infinity : BOOLEAN, 864 denormalized-values-allowed : BOOLEAN, 865 has-signed-zero : BOOLEAN 866 END TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/FloatingPointTypeDescription"; 868 TYPE LimitInteger = FIXEDPOINT MIN-NUMERATOR 1 MAX-NUMERATOR 0x7FFFFFFE DENOMINATOR 1 869 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/LimitInteger"; 870 TYPE StringLanguage = STRING LANGUAGE "i-default" 871 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/StringLanguage"; 873 TYPE StringTypeDescription = RECORD 874 "limit" : LimitInteger, 875 "language" : StringLanguage 876 END TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/StringTypeDescription"; 878 TYPE SequenceTypeDescription = RECORD 879 "limit" : LimitInteger, 880 base-type : TypeReference 881 END TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/SequenceTypeDescription"; 883 TYPE ArrayDimensions = SEQUENCE OF LimitInteger 884 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/ArrayDimensions"; 886 TYPE ArrayTypeDescription = RECORD 887 dimensions : ArrayDimensions, 888 base-type : TypeReference 889 END TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/ArrayTypeDescription"; 891 TYPE RecordOrUnionField = RECORD 892 name : Identifier, 893 "type" : TypeReference 894 END TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/RecordOrUnionField"; 896 TYPE RecordTypeDescription = SEQUENCE OF RecordOrUnionField 897 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ngRecordTypeDescription/"; 899 TYPE UnionTypeDescription = SEQUENCE OF RecordOrUnionField 900 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/UnionTypeDescription"; 902 TYPE ReferenceTypeDescription = RECORD 903 "optional" : BOOLEAN, 904 "aliased" : BOOLEAN, 905 base-type : TypeReference 906 END 907 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/ReferenceTypeDescription"; 909 TYPE ObjectSupertypeSequence = SEQUENCE OF TypeReference 910 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/ObjectSupertypeSequence"; 911 TYPE ObjectStateField = RECORD 912 name : Identifier, 913 "type" : TypeReference, 914 "private" : BOOLEAN 915 END TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/ObjectStateField"; 916 TYPE ObjectState = SEQUENCE OF ObjectStateField 917 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/ObjectState"; 919 TYPE MethodSynchronization = ENUMERATION "synchronous", "asynchronous" END 920 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/MethodSynchronization"; 922 TYPE ParameterDescription = RECORD 923 name : Identifier, 924 "type" : TypeReference 925 END TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/ParameterDescription"; 927 TYPE MethodInvocationParameterDescriptions = SEQUENCE OF ParameterDescription 928 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/MethodInvocationParameterDescriptions"; 930 TYPE MethodResultParameterDescriptions = SEQUENCE OF ParameterDescription 931 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/MethodResultParameterDescriptions"; 933 TYPE MethodResultDescriptions = SEQUENCE OF MethodResultParameterDescriptions 934 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/MethodResultDescriptions"; 936 TYPE MethodOptionalResultDescriptions = OPTIONAL REFERENCE MethodResultDescriptions 937 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/MethodOptionalResultDescriptions"; 939 TYPE MethodDescription = RECORD 940 name : Identifier, 941 synchronization : MethodSynchronization, 942 invocation : MethodInvocationParameterDescriptions, 943 results : MethodOptionalResultDescriptions 944 END TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/MethodDescription"; 946 TYPE ObjectMethodSequence = SEQUENCE OF MethodDescription 947 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/ObjectMethodSequence"; 949 TYPE ObjectTypeDescription = RECORD 950 "local" : BOOLEAN, 951 "sealed" : BOOLEAN, 952 "supertypes" : ObjectSupertypeSequence, 953 "state" : ObjectState, 954 "methods" : ObjectMethodSequence 955 END TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/ObjectTypeDescription"; 957 TYPE ConstructedTypeDescription = UNION 958 "enumerated" : EnumeratedTypeDescription, 959 "fixedpoint" : FixedPointTypeDescription, 960 "floatingpoint" : FloatingPointTypeDescription, 961 "string" : StringTypeDescription, 962 "sequence" : SequenceTypeDescription, 963 "array" : ArrayTypeDescription, 964 "record" : RecordTypeDescription, 965 "union" : UnionTypeDescription, 966 "reference" : ReferenceTypeDescription, 967 "object" : ObjectTypeDescription 968 END TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/ConstructedTypeDescription"; 970 TYPE TypeDescription = UNION 971 primitive : PrimitiveTypeDescription, 972 constructed : ConstructedTypeDescription 973 END TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/TypeDescription"; 975 TYPE UnaliasedTypeReference = RECORD 976 uuid : UUIDString, 977 description : TypeDescription 978 END TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/UnaliasedTypeReference"; 980 TYPE TypeReference = ALIASED REFERENCE UnaliasedTypeReference 981 TYPEID "http-ng-typeid://http-ng.w3.org/HTTP-ng/TypeReference"; 982 ... 984 5. Program Architectures 985 ************************ 987 Figure 5a illustrates the general arrangement of layers an 988 HTTP-ng-enabled program. Each application would contain 989 application-specific code to use the classes of interfaces it imports, 990 and to provide the functionality of classes it exports. Any number of 991 different applications can be supported on a common base. Note that 992 multiple protocols (message formats) can co-exist simultaneously; note 993 that several different transport chains can share a single TCP/IP port 994 or connection by using the MUX protocol; note that additional 995 processing of messages, such as compression, can be performed by using 996 an appropriate transport chain in the transport layer. 998 +--------+---------+--------+------------+ 999 | | | | | 1000 Applications | | | | | 1001 layer ------>| TCWA | Banking | WebDAV | (other app | 1002 | Ifc | Ifc | Ifc | Ifcs...) | 1003 | | | | | 1004 +========+=========+========+============+ 1005 Messaging | | 1006 layer ------>| HTTP 1.1 protocol w3ng 1.0 protocol | 1007 | | 1008 +=============+============+=============+ 1009 | Compression | | 1010 +-------------+ | 1011 Transport | WebMUX | 1012 layer ------>| +---------------------+ 1013 | | SSL | 1014 +------------------+---------------------+ 1015 | TCP | 1016 +------------------+---------------------+ 1018 Figure 5a. Layers of a Sample Program 1020 In an application like the Web, there would be at least two programs 1021 involved in an interaction: a web browsers, and one or more web servers 1022 and/or proxies. At the gross level, the programs would appear similar, 1023 as each has this layered architecture. With a more detailed 1024 inspection, differences corresponding to the essential client-like 1025 behavior of the browser and server-like behavior of the web server 1026 appear. For instance, the browser tends to have more surrogate classes 1027 for the object types defined in the Web interface, and the server tends 1028 to have more true classes. The server may also have more different 1029 kinds of protocols and transport elements, in order to cope with a 1030 wider variety of possible clients. 1032 For example, a server might speak both HTTP and w3ng; the browser 1033 might speak only w3ng. The server might support HTTP-ng messages over 1034 transports other than TCP/IP, while the browser might expect every 1035 server to have both webmux and TCP capability. Each might be capable of 1036 handling digitally signed documents. Both client and server might be 1037 able to use a compression transport filter on their message streams. 1038 Many other possible combinations of transport filters and protocols are 1039 possible on both sides. Some programs, such as proxy servers, might 1040 combine all the attributes of clients and servers, and add others, such 1041 as special interface extensions for caching. 1043 6. References 1044 ************** 1046 [CORBA] CORBA/IIOP 2.2 Specification; Object Management Group, 1998. 1047 (See `http://www.omg.org/corba/corbiiop.htm'.) 1049 [DCOM] Distributed Component Object Model; Microsoft, 1998. (See 1050 `http://www.microsoft.com/com/dcom.htm'.) 1052 [HTTP-ng-goals]: HTTP-ng Short- and Long-term Goals. (See 1053 `http://www.w3.org/TR/WD-http-ng-goals'.) 1055 [HTTP-ng-interfaces] HTTP-ng Web Interfaces. (See 1056 `http://www.w3.org/TR/WD-HTTP-NG-interfaces'.) 1058 [HTTP-ng-webmux] HTTP-ng WEBMUX Protocol Specification. (See 1059 `http://www.w3.org/TR/WD-mux'.) 1061 [HTTP-ng-wire] w3ng: Binary Wire Protocol for HTTP-ng. (See 1062 `http://www.w3.org/TR/WD-HTTP-NG-wire'.) 1064 [ILU] ILU Reference Manual, W. Janssen, M. Spreitzer, 1998. (See 1065 `ftp://ftp.parc.xerox.com/pub/ilu/ilu.html') 1067 [ISL] ILU Reference Manual, Chapter 2: "The ISL Interface 1068 Specification Language", W. Janssen, M. Spreitzer, 1998. (See 1069 `ftp://ftp.parc.xerox.com/pub/ilu/2.0a12/manual-html/manual_2.html'.) 1071 [Java RMI] RMI - Remote Method Invocation; Sun Microsystems, 1997. 1072 (See `http://java.sun.com/products/jdk/1.1/docs/guide/rmi/index.html'.) 1074 [RFC 2277] RFC 2277, IETF Policy on Character Sets and Languages; H. 1075 Alvestrand, January 1998. (See 1076 `http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2277.txt') 1078 [RFC 2068] RFC 2068, Hypertext Transfer Protocol - HTTP/1.1; R. 1079 Fielding et. al., January 1997. (See 1080 `http://www.w3.org/Protocols/rfc2068/rfc2068'.) 1082 [PEP] PEP - An Extension Mechanism for HTTP; W3C, 1998. (See 1083 `http://www.w3.org/Protocols/PEP/'.) 1085 7. Address of Authors 1086 ********************** 1088 Bill Janssen 1089 Mail: Xerox Palo Alto Research Center 1090 3333 Coyote Hill Rd 1091 Palo Alto, CA 94304 1092 USA 1093 Phone: (650) 812-4763 1094 FAX: (650) 812-4777 1095 Email: janssen@parc.xerox.com 1096 HTTP: `http://www.parc.xerox.com/istl/members/janssen/' 1098 Henrik Frystyk Nielsen 1099 Mail: World Wide Web Consortium 1100 MIT/LCS NE43-348 1101 545 Technology Square 1102 Cambridge, MA 02139 1103 USA 1104 Phone: + 1.617.258.8143 1105 FAX: + 1.617.258.5999 1106 Email: frystyk@w3.org 1107 HTTP: `http://www.w3.org/People/Frystyk/' 1109 Mike Spreitzer 1110 Mail: Xerox Palo Alto Research Center 1111 3333 Coyote Hill Rd 1112 Palo Alto, CA 94304 1113 USA 1114 Phone: (650) 812-4833 1115 FAX: (650) 812-4471 1116 Email: mike-spreitzer@acm.org 1117 HTTP: `http://www.parc.xerox.com/csl/members/spreitze/'