`
`H DTP
`SPECIFICATION
`
`Vers-ion 1
`
`-1—DRAFT
`
`UNWIRED PLANET, INCORPORATED
`
`390 Bridge Parkway
`Redwood Shores, California 94065
`USA
`
`Part Number HDTP-SPEC-DOC-101
`July 15, 1997
`
`
`
`APPLE 1013
`
`1
`
`APPLE 1013
`
`

`

`
`
`IMPORTANTNOTICE
`90
`
`COPYRIGHT INFORMATION
`Copyright 1997 UnwiredPlanet, Inc. All rights reserved.
`’ Permission to use, copy, modify,distribute, and create derivative worksofthe
`Handheld Device Transport Protocol (““HDTP”) is hereby granted, subject to
`the following -termsand conditions:
`
`1 Redistribution ofthe HDTP anddistribution ofanyderivative works thereof
`mustretain the following disclaimer.
`THIS HDTP IS PROVIDED BYUNWIRED PLANET “AS IS” AND TO
`THE MAXIMUM EXTENT PERMITTED BY LAW, UNWIRED PLANET
`MAKES NOREPRESENTATIONS OR WARRANTIES, EXPRESS OR
`IMPLIED, AND EXPRESSLY DISCLAIMS ANY EXPRESS OR IMPLIED
`WARRANTIES, REGARDING THE HDTP, INCLUDING, BUT NOT
`LIMITED TO, ANY IMPLIED WARRANTIES OF
`MERCHANTABILITY,FITNESS FOR A PARTICULAR PURPOSE, OR
`NON-INFRINGEMENT. UNWIRED PLANET DOES NOT WARRANT,
`GUARANTEE, OR MAKE ANY REPRESENTATIONS REGARDING
`THE USE OF, OR THE RESULTS OF THE USE OF THIS HDTP
`SPECIFICATION IN TERMSOFITS CORRECTNESS, ACCURACY,
`RELIABILITY OR OTHERWISE, IN NO EVENT SHALL UNWIRED
`PLANET BE LIABLE FOR ANY DAMAGES RESULTING FROM OR
`ARISING OUT OF YOUR USE OF THE HDTP SPECIFICATION,
`INCLUDING, WITHOUT LIMITATION,ANY DIRECT,INDIRECT,
`CONSEQUENTIAL, OR PUNITIVE DAMAGES (INCLUDING, BUT
`NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
`SERVICES, LOSS OF USE, DATA, OR PROFITS, OR BUSINESS
`INTERRUPTION) RESULTING FROM THE USE, MODIFICATION, OR
`DISTRIBUTION OF THE HDTP SPECIFICATION, AND HOWEVER
`CAUSED AND ON ANY THEORYOFLIABILITY, WHETHER IN
`CONTRACT,STRICT LIABILITY, OR TORT, EVEN IF ADVISED OF
`THE POSSIBILITY OF SUCH DAMAGE.
`TRADEMARK INFORMATION
`Unwired Planet, the Unwired Planet logo, UP.Link Platform, UP.Link
`Gateway and UP.Browser are either trademarks or registered trademarks of
`
`Unwired Planet,Inc. in the United States,
`
`2
`
`

`

`Preface 5
`5
`Introduction
`Hand-held Devices
`HDTP Origins
`6
`
`5
`
`1 Overview 7
`Features
`8
`8
`Sessions
`9
`Security
`PDUPiggybacking 9
`Versioning 9
`
`11
`
`2 Message Formats
`Data Formats
`11
`12
`Message Structure
`Long Header 12.
`Short Header
`12
`Protocol Data Units (PDUs)
`PDU Categories
`13
`PDU CommonFields
`Request PDUs
`16
`Reply PDUs=20
`Acknowledgment PDUs
`23
`OtherPDUs 24
`
`13
`
`14
`
`'3 Protocol Operations 25
`Protocol Stack 25
`25
`Session Management
`Session Creation 25
`Session Errors
`27
`Nomnmal Transactions
`30
`30
`Three-Way Handshake
`Lost Messages and Retries
`HoldOn
`32
`Transaction Errors
`Cancellation
`33
`Notifications
`34
`
`32
`
`30
`
`A Assigned Numbers 35
`
`B Bibliography 39
`
`———
`July 15, 1997
`,
`HDTP 1.1 Draft Specification
`3
`
`SO
`
`3
`
`

`

` 4
`
`HDTP 1.1 Draft Specification
`
`July 15, 1997
`
`
`
`4
`
`

`

`Preface
`
`The Handheld Device Transport Protocol (HDTP)is a datagram protocolto perform
`secure,lightweight client/server transactions. This specification defines HDTP version
`11.
`
`DISCLAIMER:Thisis a draft specification. The contents herein are subject to
`change.
`.
`
`Introduction
`
`:
`
`The World Wide Webprovides a robust, flexible, and ubiquitous model for
`information access. The adoption of the WWW asthe preferred means of
`disseminating and accessing information from desktop PCs and workstations has
`created a demandfor access to the same information from other devices. These devices
`or “alternate platforms” range from voice- and fax-based user agents to low-cost
`Network Computers to hand-held devices such as mobile phones and PDAs.
`While the web's infrastructure and protocols fully support mostof these alternate
`platforms, manyofthe protocols are neither practical nor easily implemented on
`certain devices. In particular, the reliance of HTTP on the TCP/IP protocol stack and ”
`the packet, processing and memory overhead of SSL make them poorprotocols for
`many wireless networks. HDTP provides a protocol semantically equivalent to HTTPS
`(HTTP and SSL), allowing hand-held devices on low-performance, high-cost networks
`to function as full-fledged webclients.
`
`Hand-held Devices
`
`While there are manytypes,styles, and classes of hand-held devices,this specification
`is useful for a significantly larger class of devices with similar physical characteristics.
`Those characteristics include:
`.
`:
`:
`*
`limited bandwidth
`
`*
`
`limited resources such as memory, processing power, permanentstorage
`
`Network bandwidth is usually low dueto limitations of the network technology or
`simple economics. The same goes for other resources: memory, processing power,
`evenbattery life. While some hand-held devices do have large amounts of memory or
`
`
`
`July 15, 1997
`
`HDTP 1.1 Draft Specification
`
`5
`
`5
`
`

`

`rE TS ee
`Preface
`too
`.
`
`HDTP Origins .eSeee
`
`HDTP Origins
`
`processing power,these devicesare the exception. Mass market and consumer-targeted
`devices will continue to have these constraints for many years.
`This specification uses theterm “hand-held,”recognizingthat the term is not inclusive
`ofall devices which would benefit from HDTP.
`
`HDTP originated with the Unwired Planet UP.Link Platform™ as the protocol
`betweenan ultra-lightweight web browser, the UP.Browser™,and a proxyserver,the
`UP.Link Gateway™,As such,the protocolis tuned for browser-proxy communication,
`butthat should not preventthe protocol from being used for more general applications.
`Thefirst incarnation of HDTP was UGP,the UP.Link Gateway Protocol. The second
`incarnation ofthe protocol was SUGP,the Secure UP.Link GatewayProtocol. In
`SUGP,security was added,the notification model was restructured, andthe protocol
`was further generalized. HDTP 1.1 is derived from SUGP1.0, with more
`generalization, removal of quirks, and a tighter coupling to HTTP.
`i
`
`6
`
`HDTP 1.1 Draft Specification
`
`.
`
`July 15,.1997
`
`
`
`6
`
`

`

`Overview
`
`HDTP (Handheld Device Transport Protocol) is an application- and session-level
`protocol for remote operations between a client and proxy or server.It provides the
`samebasic functionality of HTTPS(i.e., HTTP over SSL), namely:
`¢ Extensible request methods
`¢ Typing and negotiation of data representation
`
`© Messageprivacy, integrity and authentication
`Moreover, HDTP has been optimized for small clients (such as handheld devices) and
`low-performance networks in the following ways:
`The protocol is datagram-based rather than stream-based allowing for a simpler
`underlying protocol stack.
`
`Header names and other well-known values are encoded wherever possible.
`Session contexts reduce transmission of redundantdata.
`
`Asynchronousnotifications support data push withoutthe polling of traditional push
`systems.
`Security and cipher algorithms used can be implemented on small devices.
`FIGURE 1-1, HDTP Protocol Stacks
`
`Proxy or
`
`Server
`
`Datagrams (e.g., UDP)
`
`a H
`
`July 15, 1997
`
`DTP 1.1 Draft Specification
`
`7
`
`
`
`7
`
`

`

`j
`
`1 . Overview
`Features
`
`Features
`
`The following features are provided by HDTP.
`
`HTTP Semantics
`
`HDTP provides semantics similar to HTTP. Server requests and responses mayinclude
`both headers (meta-information) and content. The following HTTP methods are
`supported:
`¢ OPTIONS
`° GET
`
`¢ HEAD
`* POST
`
`_¢ PUT
`_¢ DELETE|
`
`Sessions
`
`Requests andreplies are performed within the contextof a session. The session context
`typically contains the following information:
`© Client and Server SessionId
`
`° Session Key
`¢ Cipher
`© Protocol Version
`
`¢ Current Requestld |
`¢ Deviceld
`
`'
`
`A special meta-session (session 0) is reserved for the creation of sessions. Session 0 is
`unencrypted and unauthenticated, and can accept any protocol version.
`Eachsession has associated server and client session identifiers. Requests carry a four
`byte server session id so that the server can support simultaneous sessions with a large
`number of clients. Replies carry a onebyte client session id so that the client can
`maintain multiple simultaneoussessions as well. Only one byte is used forreplies to
`reduce packet size and becauseitis anticipated’thatclients will have no more than 255
`active sessions.
`
`As part of the session creation process, protocolversion, cipher algorithm, and session
`key are negotiated betweenclient and server. Also, constant request headers, and other
`parameters are exchanged betweenthe client and server.
`Session creation is designed to locate the complex calculations on the server. For
`example, the random session key is generated by the server and communicated to the
`client,
`
`(
`
`
`8
`
`HDTP1.1 Draft Specification
`
`
`
`July 15, 1997
`
`8
`
`

`

`1
`Overview
`Features
`aNee
`
`—_— ieen :
`
`Securityi
`HDTP provides a numberof security features.
`
`Authentication, Privacy, and Integrity
`
`HDTP provides for authentication, privacy and integrity. Sessions are authenticated.
`Thesession authentication between a client and server is conducted by using shared
`secret key and a noncechallenge. All protocol data units (PDUs)sentin a session are
`encrypted. Messageintegrity is enforced by performing a checksum ofthe entire PDU
`and encrypting the checksum together with the PDU.
`HDTP provides meansto support different cipheralgorithms. As part of a session
`creation request,the cipheralgorithm is negotiated between client and server.
`Note that key management, namelythe provisioningofthe shared secret key, is outside
`the scope ofthis specification.
`
`Counteracting Playback Attacks
`Playbackis a very commonsecurity attack. The playback attack scenario isthat an
`attacker makes copies of messagessent from client to server, and plays them backat a
`later date, trying to cause the server to respond to the forged requests. HDTP provides
`meansto counteract playbackattacks.
`Forregular transactions, a requestidentifier (Requestld)is used to detect playback
`requests. The Requestldis encrypted in the protocol PDU.Every request and reply
`mustcarry a Requestld, Duringthelifetime of a session, any Requestld in requests and
`replies must equal to the current Requestld in both server andclient.
`Forthe session creation process,both client and server challenge each other by using a
`nonceas a challenge and nonce + 1 as a response to the challenge to avoid playback of
`session creation requests.
`
`PDU Piggybackingeeeee
`Where possible, HDTP allows PDUpiggybackingto reduce the number ofpackets sent
`over the network. For example,the session creation process requires the client to send
`at least two messages (Session Request and Session Complete)to the server. The
`second message (Session Complete) can be combinedwith the regular service request
`that triggered the session creation inthefirst place.
`
`Versioning
`HDTP provides a version negotiation mechanism,so that the protocol may evolve
`while remaining backwardsor forwards compatiblein the future. The protocol version
`is negotiated during session creation.
`
`July 15, 1997
`
`
`
`HDTP 1.1 Draft Specification
`
`9
`
`9
`
`

`

`1
`
`Overview
`
`
`
`a 1
`
`0 HDTP 1.1 Draft Specification
`
`
`
`July 15, 1997
`
`10
`
`

`

`Message Formats
`
`This section describes the data formats used to exchange HDTP messages between
`client and server.
`
`Data Formats
`
`Thefollowing data types are used in the message formatdefinitions.
`TABLE 2-1. FormatDefinition Data Types
`bytei: 16 bit signed integer
`
`
`
`Data Type_| Delinltlonid
`1 bit of data
`:
`
`
`
`
`
`
`
`
`
`8 bits of opaque data
`8 bit signed integer
`8 bit unsigned integer
`
`u_short
`
`16 bit unsigned integer
`32 bit signed integer
`32 bit unsigned integer
`
`Network byte order for multi-byte integer values is “big-endian”. In other words,the
`mostsignificantbyte is transmitted on the networkfirst followed subsequently by the
`less significant bytes.
`Network bit ordering forbit fields within a byte is “big-endian”. In other words,bit
`fields described first are placed in the mostsignificantbits of the byte.
`©
`
`
`
`
`
`July 15, 1997
`
`
`
`HDTP 1.1 Draft Specification
`
`11
`
`11
`
`

`

`‘
`Message Formats +
`Message Structure
`
`Message Structure
`
`FIGURE 2-2. Message Formats
`
`Every message has a header, a body anda trailer. The header identifies the session the
`message is destined for. The body contains one or more Protocol Data Units (PDUs).
`Each PDUperforms a particular function in the protocol and contains type-specific
`content. The trailer contains any encryption-related data required by the session’s
`cipher algorithm, such as checksums, padding bytes andinitialization vectors.
`There are two kinds of headers: long and short. The longheader has4 bytes and is used
`for messagessentfrom theclientto the server. The short has 1 byte and is used for
`messages sent from the server to theclient.
`The maximumlength ofthe entire message is determined by the underlying disfagrams
`transport.
`
`Long Header
`The long header is used in messages destined for the HDTP server.
`
`_ TABLE 2-3, Long Header Fields
`SSSSSS[Session[wint|Serversesionidentfier=
`
`_—
`
`:
`
`|
`
`.
`
`Server SessionId values are specified in Table A-1 in Appendix A.
`Session 0 is a special session used to create user sessions and perform other meta-
`functions. Session0 is inherently unencrypted and unauthenticated. This means:
`© Session 0 will respond only to PDUsthat include authentication information.
`© Any encryption required in a PDU destined for session 0 is defined in the PDU
`format.
`
`.
`
`* Thetrailer is of length zero.
`Sessions 0x00000001--0x0000000Fare reserved for future use. Sessions 0x00000010—
`OxFFFFFFFF are used for user sessions.
`:
`
`Short Header
`
`The short header is used in messages destined for the HDTP client.
`
`
`
`e-—-——— ------——————————
`
`12 HDTP 1.1 Draft Specification
`
`July 15, 1997
`
`
`
`12
`
`

`

`)
`--
`Message Formats 2
`Protocol Data Units (PDUs)
`
`TABLE 2-4. Short Header Fields
`
`|Name"_|Type__|Purpose—‘isCiz*C
`
`|.Sessionld|u_char|Clientsessionidentifier
`Client SessionId values are specified in Table A-2 in Appendix A.
`Session 0 is a special session used for certain meta-functions and error messages.
`Session 0 is inherently unencrypted and unauthenticated. This means:
`
`
`
`* Session 0 will only accept PDUsthatinclude some form ofauthentication or
`validation information.
`
`’
`
`* Any encryption required in a PDU destinedfor session 0 is defined in the PDU
`format.
`:
`
`¢ Thetrailer is of length zero.
`Sessions 0x01—Ox02are reserved for SUGP backwards compatibility. Sessions 0x03-
`OxOFare reserved, Sessions 0x10-OxFF are usersessions.
`
`Protocol Data Units (PDUs)
`
`The body of an HDTP message contains one or more protocol data units (PDUs). Each
`PDUserves a particular function in the protocol and contains type-specific
`information,
`
`PDU Categories
`PDUsfall into one offour categories: requests, replies, acknowledgments or other. The
`basic protocol is a three-way handshake, where the client sends a request, the server a
`reply, and the client an acknowledgment. This is described further in "Protocol
`’ Operations”.
`
`Requests
`The following PDUsare considered requests:
`¢ SessionRequest
`© Get
`© GetNotification
`
`* Post
`
`© Options
`© Head
`¢ Put
`
`e Delete
`
`oo
`July 15, 1997
`:
`HDTP 1.1 Draft Specification 13
`
`
`
`13
`
`

`

`-
`
`2 Message Formats| |
`
`Protocol Data Units (PDUs)
`
`/
`
`Ss 7
`
`:
`
`Replies
`The following PDUsare considered replies:
`¢ SessionReply -
`° Reply
`° Error
`* Redirect
`
`Acknowledgments
`The following PDUsare considered acknowledgments:
`
`© SessionComplete
`* Cancel
`« Ack
`
`,
`
`Other
`
`The following PDUsperform other functions:
`¢ HoldOn
`
`° Signal
`
`PDUCommon Fields
`
`‘This section describes fields that are commonacross all or many PDUs.
`
`PDU Header
`
`FIGURE 2-5. PDU Header Format
`
`PDU Body
`
`| —
`
`/
`NotLast
`Every PDUstarts with a request identifier (Requestld), a NotLast bit, andtype
`identifier (Type).
`:
`
`
`
`14 HDTP 1.1 Draft Specification
`
`July 15, 1997
`
`14
`
`
`
`TABLE 2-6. PDU HeaderFields
`
`
`
`[Name|Type[Purpose
`[Requestld[u_char|Request identifier
`
`
`|NotLast|1bit|Notthe last PDU in the message :
`
`:
`Type and function of this PDU
`
`
`
`14
`
`

`

`a
`Message Formats 2
`oe
`Protocol Data Units (PDUs)I
`
`_ The Requestldfield is used to identify‘duplicate messages and to counteract playback
`attacks. All request, reply, and error PDUsassociated with a single transaction share
`the same Requestld.
`Requestld’s must be monotonically increasing, and maynot be repeated. A side-effect
`ofthis is that there can be no more 256transactions during the lifetime of a session.
`Thisis an intentional counter to a clear-text attack on the session key.
`The NotLastbit indicates that this PDUis not the last PDU in the message. In other
`words, another PDU immediately follows this PDU.
`
`The Type field specifies the function of the PDU. Therest of the PDUis type-specific
`information, referred to as the contents. The following sections describe the formatof
`the contents for each PDU type. The type numbersfor the various PDUsare
`summarized in Table A-3 in Appendix A.
`
`In the interest of brevity, the PDU header has been omitted from the description of each
`PDUinthe sections that follow.
`
`Headers
`
`Many PDUtypescontain a headers field. The headers field contains zero or more key-
`value pairs ofstrings. Headers usually contain meta-information about the request or
`response.
`
`Each key-valuepair in the headers is comprised of two null (0x00) terminated strings,
`the key andthe value. For example, if there were a header with the key “Name”andthe
`value “Bob”, it would be encoded as follows:
`
`'N’
`
`fart
`
`fm!
`
`’e’ 0x00 ’B’
`
`‘0’
`
`‘b’ 0x00
`
`Well-knownand frequently used header keys and values may be encoded asasingle
`character string where the character is between hexadecimal 0x80 and OxFF. For
`example the HTTP “Content-type” header key is encoded as decimal 0x9A,and the
`content-type value “application/x-hdmlc”is encoded as 0x81. Thus, the header
`“Content-type: application/x-hdmlc” can be encodedas follows:
`Ox9A 0x00 0x81 0x00
`
`Notethat the following encodings of “Content-type: application/x-hdmlc” are
`considered equivalentto the previous one:
`
`‘1’ he teh fat
`‘p’
`‘p’
`Ox9A 0x00 ‘a’
`fat
`the fat
`ome 41) vet 0x00
`
`ttt fa fot
`
`int
`
`fst
`
`tx!
`
`"C’
`
`fot Un’ "tt
`
`fet
`
`int *te fat pe ty!
`
`‘pt
`
`ter 0x00 0x81 0x00
`
`ty!
`fo! ne "te et me th fet Ope
`"Cc!
`'p’ "hd?
`tat
`fet
`fal "te "ET!
`fot ip tft
`1°"
`‘oc’ 0x00
`
`‘p’
`tyr
`
`'p’
`te’ 0x00 ‘a’
`fae he "a om
`.
`
`Well-known header keysare listed in Table A-5 in Appendix A. Well-known header
`values for particular header keysare listed in subsequenttables.
`
`
`
`July 15, 1997
`
`
`
`HDTP 1.1 Draft Specification 15
`
`15
`
`

`

`2 Message Formats \
`Protocol Data Units (PDUs)
`
`
`,-
`
`Request PDUs
`
`SessionRequest
`SessionRequestis a request PDUto initiate the creation of a session.
`
`TABLE 2-7. SessionRequest Contents
`
`a [
`
`Version[war|HDTPprowcolvenion
`
`
`
`
`[Clensessonld|a.char|Clintidentififorenewsession|
`[Devicciten[usher[LengofDevied@feld—___—|
`
`
`
`
`
`
`
`
`
`
`
`
`
`Device identifier (max, 255 bytes)
`
`Headers
`
`Session headers (max. 65535 bytes)
`
`DeviceldLen
`bytes
`HeadersLen
`bytes
`jClientOnce;|u_short Client nonce challenge for authentication
`
`
`|variable|Trailer for nonce encryption
`
`
`The SessionRequest PDU is unusualin that someofits fields, namely the ClientNonce
`and EncryptionTrailer are encrypted. The namesof the encrypted fields are shown in
`gray in the abovetable. Normally, the SessionRequestis sent to session 0 which, by
`definition, is an unencrypted session.If the SessionRequestis sent to an encrypted user
`session, the net result will be that the aims fields in the PDU will be doubly
`encrypted.
`The Cipherfield identifies the cipher algorithm andits cipher-specific parameters used
`bythe device to encrypt the encrypted fields.It also acts as the proposed cipherto be
`“used for the new session. Thefirst byte of the Cipher field contains the cipher
`algorithm. Encoded values for the cipher algorithm are listed in Table A-4 in
`Appendix A. The second byte of the Cipherfield contains cipher-specific parameters.
`TheVersionfield identifies the version of the HDTP protocol. This is used to
`determine the formats of this and all subsequent PDUs.The version numberis encoded
`as follows: The major numberofthe version is stored in the high-order4 bits, and the
`minor number is stored in the low-order4bits.
`
`-
`
`The ClientSessionId field contains the client session identifier to use when sending
`messagesto the new session ontheclient.
`The DeviceldLen and HeadersLenfields specify the length of the Deviceld and
`Headers fields respectively.
`
`The Deviceld field contains an opaque device identifier. The contents of the device
`identifier are defined by the server.
`The Headers field contains headers that apply to the entire session. Depending on the
`headerkey, these can be headers that will be automatically attached to subsequent
`service requests, or they can be session-specific parameters.
`
`
`
`16 HDTP 1,1 Draft Specification
`
`mo
`
`“July 15, 1997
`
`16
`
`

`

`:
`
`‘
`
`:
`
`ws
`Message Formats 2
`Protocol Data Units (PDUs)
`
`The ClientNoncefield contains a nonceto be used as an authentication challengeto the
`server. Playback attacks are prevented byvirtue of the fact that a nonce is a non-
`repeating number. Thus, every SessionRequestis unique in thatit will always have a
`different nonce,
`
`Get
`Getis a request PDU analogous to the HTTP GET method.It is sent to get whatever
`information is associated with a given URL.
`TABLE2-8, Get Fields
`[Name]Type]Purpose
`
`
`
`
`
`
`
`
`Headers HeadersLen|Request headers
`bytes
`UriLen
`bytes
`
`
`
`URL toget
`
`| Url
`
`The HeadersLen and UrlLenfields specify the length of the Headers and Url fields
`respectively.
`The Headers field contains the headers associated with the request.
`
`
`
`
`
`
`The Urlfield contains the Url to get.
`
`GetNotification
`
`GetNotification is a request PDUsentto retrieve any outstanding data pushes. The _
`GetNotification PDU has no type-specific contents. The server will respond with a
`Reply PDUcontaining the pushed data.
`GetNotification differs from Getin that it does not request a particular URL. The server
`knows the URL for the notification, notthe client. The reply from the server should
`include the “Location” headerto indicate the URL of the data pushed.
`
`Post
`
`Post is a request PDU analogous to the HTTP POST method. It is used to requestthat
`the server acceptthe entity enclosed in the request as a new subordinate of the resource
`identified by the URL.
`
`.
`TABLE 2-9. Post Fields
`
`
`[Name[Types«[PuposeC*d
`[HeadersLen|ushort|Length of Headers field
`
`
`ee
`
`
`[Daaten|v.stor|tang of as ed
`Headers HeadersLen|Request headers
`
`
`
`bytes
`
`
`
`July 15, 1997
`
`.
`
`HDTP 1.1 Draft Specification 17
`
`
`
`17
`
`

`

`eee |eeAEtSicenaeSS
`2 Message Formats‘.
`”
`‘?
`Protocol Data Units (PDUs)
`
`
`
`Data to be posted
`
`(Ramis95rp
`UriLen bytes
`DataLen
`bytes
`The HeadersLen, DataLen and UrlLenfields indicate the size of the Headers, Data, and
`Urlfields respectively.
`. The Headers field contains the headers associated with the request.
`The Urlfield contains the Urlto postto.
`The Data field contains the data associated with the request.
`
`
`
`
`
`
`Options
`Options is a request PDU analogous to the HTTP OPTIONS method.It is used as a
`request for information about the communication options available on the
`request/response chain identified by the URL. This method allowsthe client to
`. determine the options and/or requirements associated with a resource,or the
`capabilities of a server, without implying a resource actionorinitiating a resource
`retrieval.
`
`TABLE2-10. Options Fields
`
`ame
`
`y|N
`
`
`
`jtype__+|Purpose
`
`Length of Headers field
`Length of Us field
`Request headers
`HeadersLen
`:
`‘
`bytes
`"|
`UriLen bytes|URL for the options to get
`
`
`
`
`
`
`Headers
`
`
`
`
`The HeadersLen and UriLenfields indicate the size of the Headers and Url fields
`respectively.
`
`The Headers field contains the headers associated with the request.
`The Urlfield contains the Url forthe options to get.
`
`Head
`Head is a request PDU analogous to the HTTP HEAD method. The Head PDUis
`identical to Get except that the server MUST NOTreturn a message-bodyin the
`response. The meta-information containedin the headers in response to a Head request
`SHOULDbe identical to the information sentin response to a Get request. This method
`can be used for obtaining meta-information aboutthe entity implied by the request
`withouttransferring the entity-bodyitself. This method is often used for testing
`hypertextlinks for validity, accessibility, and recent modification.
`
`TABLE 2-11, Head Fields
`
`
`
`
`[Name|Type]Purpose
`
`
`
`
`
`
`18 “HDTP 1.1 Draft Specification
`:
`
`July 15, 1997
`
`18
`
`

`

`)
`Message Formats 2
`Protocol Data Units (PDUs)
`
`HeadersLen
`bytes
`UriLen bytes|URL for the headers to get
`The HeadersLen and UrlLenfields indicate the size of the Headers and Urlfields
`respectively.
`
`
`
`
`Request headers
`
`
`
`
`The Headers field contains the headers associated with the request.
`The Url field contains the Url for the headers to get.
`
`Put
`
`Putis a request PDUanalogousto the HTTP PUT method. It is used to requestthatthe
`enclosed entity be stored under the supplied URL. If the URL refers to an already
`existing resource, the enclosed entity should be considered as a modified version ofthe
`one residing ontheorigin server.If the URL doesnotpointto an existing resource, and
`that URL is capable of being defined as a new resource by the requesting user agent,
`the origin servercan create the resource with that URL.
`TABLE 2-12. Put Fields
`
`[Name[Type|Purpose
`Leng of Header fil
`[UaiLen|aston|Leng ofUt ft
`DataLen
`Length of Data field
`
`
`
`
`
`
`The HeadersLen, UrlLen and DataLenfields indicate the size of the Headers, Url, and
`Data fields respectively.
`
`The Headers field contains the headers associated with the request.
`The Urlfield containsthe Url to put.
`
`The Data field contains the data associated with the request.
`
`Delete
`
`Delete is a request PDU analogousto the HTTP DELETE method.It is used to request
`thatthe serverdelete the resource identified by the URL.
`TABLE 2-13. Post Fields
`
`
`[Name Type____|Purpose
`
`[engh of eae fl
`
`
`[Utes|esto|Length of Ut etd
`
`
`
`July 15, 1997
`HDTP 1.1 Draft Specification
`19
`
`
`
`19
`
`

`

`a et
`‘_ ”
`“?
`Message Formats
`Protocol Data Units (PDUs)
`
`[Name|Typo|Purpose
`. HeadersLen|Request headers
`
`bytes
`:
`.
`Uriken be
`The HeadersLen and UrlLen fields indicate the size of the Headers and Url fields
`respectively.
`The Headers field contains the headers associated with the request.
`' The Url field contains the Url to delete.
`
`
`
`
`
`Reply PDUs
`
`SessionReply
`SessionReply is a reply PDU in response tothe SessionRequest PDU. The
`SessionReplyis sentto the client session identified in the SessionRequest. Thus,the
`entire PDU should be encrypted.
`:
`Newclientsessions, by default, expect messages to be encrypted using the cipher
`proposed in the SessionRequestand the shared secret key. The SessionReply contains a
`SessionKey and proposed cipher to be used for subsequent communication.
`
`:
`TABLE 2-14. SessionReply Fields
`
`
`
`[Name|Type|Purpose
`
`
`
`
`
`[Serveronce|u.shor’|Servernoneechallengeforauthentication|
`
`
`
`
`Server sesion enter
`
`7
`
`
`
`SessionKeyLen|u_char—_|Length of Key field
`
`Length of Headers fl
`SessionKey
`i SessionKeyLen|Session key (max 255 bytes)
`
`bytes
`,
`|
`byt
`HeadersLen
`bytes
`
`Headers |
`
`‘Session headers (max 65535 bytes)
`
`The ServerNonce field contains a nonce to be used as an authentication challenge to the
`client. Playbackattacks are prevented by virtue,of the fact that a nonceis a non-
`repeating number. Thus, every SessionReply is unique in that it will always have a
`different nonce.
`
`The ClientNoncePlusfield contains the authentication responsefrom the server which
`is the ClientNonce from the SessionRequestincremented by one.
`The ServerSessionld contains the server session identifier. The client uses this session
`identifier for all subsequent communication to the server.
`
`The Cipher field contains a proposed cipheralgorithm to use for the remainder ofthe
`session.If the client is capable of the proposed cipher, it may use it. Otherwise,it
`should use the original cipherit proposed.
`:
`
`,
`
`20 HDTP 1.1 Draft Specification
`
`.
`
`*
`
`July.15, 1997
`
`
`
`
`
`20
`
`

`

`
`
`\
`
`—
`
`Message Formats 2
`
`The SessionKeyLen and HeadersLen fields contain the length of the SessionKey and
`Headers fields respectively.
`The SessionKeyfield contains the key used to encrypt subsequentcommunicationsin
`the session.
`
`The Headers field contains headers that apply to the entire session. Depending on the
`headerkey, these can be headers that will be automatically attached to subsequent
`service responses, or they can be session-specific parameters.
`
`Reply
`
`Replyis the reply PDU usedto return information from the server in response to Get
`and Post.
`
`TABLE2-15. Reply Fields
`
`
`
`[Namie|Type__[ PurposeSS—~—SSCSC~C~*dS
`
`Length of the Headers field
`
`Length ofthe Data field
`DataLen
`Reply headers
`Headers
`
`
`
`
`
`
`
`
`
`Randonian
`bytes
`DataLen
`bytes
`
`Reply data
`
`TheHeadersLen and DataLen fields specify the length of the Headers and Data fields
`respectively.
`The Headers field contains the reply headers.
`The Data field contains the data returned from the server.
`
`Error
`
`Error is a reply PDUthat indicates that there was some form of error servicing the
`request.
`In someinstances,such as the server side of the session no longer existing, the error
`will be returned to client session 0 rather than the client session the request came from.
`Toreduce the opportunity for denial-of-service attacks, the Error PDU includesa tag
`whichis derived from the requestthattriggered the error. This allowsthe client to
`validate all errors comingto client session 0.
`As in HTTP,eacherror has an error code associated with it. Also, the error can return
`some arbitrary data (such as an HDML deck)thatfurther describesthe error and allows
`the user to take corrective action.
`
`TABLE 2-16. Error Fields
`
`
`
`
`
` i|Nataiacetagmatchingrequestthat|Validatortagmatchingthatcaused|request
`
`
`
`
`
`
`July 15, 1997
`
`oo,
`
`:
`
`HDTP 1.1 Draft Specification 21
`
`21
`
`

`

`
`‘
`2 Message Formats1
`
`‘Protocol Data Units (PDUs)
`
`
`eeee|DataLen"|Length of the Data
`
`
`
`lLengthoftheDaafield #§#|
`
`
`HeadersLen
`Error headers
`bytes
`
`
`peeee
`
`
`The Tagfield allows the client to validate that the error was actually caused by an
`outstanding request. If the request was sentto a user session (i.e., not server session 0),
`then the Tagfield will contain the SessionId from the request. If the request was sent to
`session 0, the Tag field will contain a PDU-dependentvalue.In the case of
`SessionRequest, it will contain the four-bytes starting at the ClientNoncefield.
`The Code field contains a numeric code to identify the error. Error codesare listed in
`Table A-7 in Appendix A.
`
`The HeadersLen.and DataLenfields specify the length of the Headers and Data fields
`respectively.
`
`The Headers field contains theerror headers.
`The Data field contains the data returned from the server.
`
`Redirect
`
`The Redirect PDU maybe returned in response to a SessionRequest. It contains one or
`more addresses to which the SessionRequest should be sent again. This is used to
`migrate clients to servers whose addresses have changed,or to perform a crude form of
`load balancing at session creation time.
`Note that this PDU will be sentto client session 0. Thus,it has the same validation tag
`in it that the Error PDUhas.
`‘
`
`TABLE 2-17. Redirect Fields
`
`
`
`
`
`es_—peeValidatortag|Validatortagmatchingrequestthattriggeredredirect|
`
`[Addrseen|shar|Leng ofthe Adesfl
`Addresses AddressesLen{|Oneor more addresses to which to send subsequent
`
`bytes
`SessionRequests
`
`The Tagfield contains the validator tag as described in "Error".
`- The AddressesLenfield contains the length of the Addresses field.
`The Addressesfield contains one or more newaddresses for the server. Subsequent
`SessionRequests should be sentto these addresses instead of the server address just
`tried. The formatof the addresses is dependenton the underlying datagram protocol.
`
`
`
`22 HDTP 1.1 Draft Specification
`
`
`
`July 15, 1997
`
`22
`
`

`

`ATLTEOS
`~<. Message Formats 2
`Protocol! Data Units (PDUs)
`
`Acknowledgment PDUs
`
`SessionComplete
`SessionCompleteis an acknowledgment PDUthat completes the session creation
`process.It is sent to the server session identified in the SessionReply PDU.Thus,the
`entire PDU should be encrypted.
`TABLE2-18, SessionComplete Fields
`[Name|Typ]Purpose
`ServerNoncePlus
`ServerNonce+1 response for authentication
`
`The ServerNoncePlusfield contains the authentication response from the client which
`is the ServerNonce from the SessionReply incremented by one.
`
`Cancel
`The CancelPDUcauses the current transaction to be canceled. The Cancel PDUhasno
`type specific contents.
`
`Ack
`
`The Ack PDU acknowledges that the reply has been received from the server. The Ack
`PDUprovides some information about how long the request took so that performance
`monitoring of the network can be performed atthe server.
`TABLE 2-19. Ack Fields
`
`
`fame|Type|PUNO
`[Delay|10bit|Round-trip ime for request
`
`
`|Tries|6bits|Number ofretransmitted request packets
`. The Delayfield contains the time between whenthe request was initiated and when a
`reply or error was