(* Draft ISL HTTP-NG specification. Type definitions common between the client library interface and the client/server interface. Derived from Simon Spero's 9/24/95 document. Authors: Jim Gettys Dan Connolly Question: How should strings/messages be represented in NG? Should it be Unicode? If so, what encoding? *) INTERFACE HTTPTypes; TYPE STRING = SEQUENCE of SHORT CHARACTER; TYPE MessageID = INTEGER; TYPE IntOpt = OPTIONAL INTEGER; TYPE BoolSeq = SEQUENCE of BOOLEAN; TYPE Date = RECORD seconds: INTEGER, microseconds: INTEGER END; TYPE DateOpt = OPTIONAL Date; TYPE Message = SEQUENCE of BYTE; TYPE MessageOpt = OPTIONAL Message; TYPE URI = SEQUENCE OF BYTE; TYPE URIOpt = OPTIONAL URI; TYPE Data = UNION sessionID: INTEGER, uri: URI END; TYPE HTTP1XMessage = SEQUENCE of BYTE; TYPE Value = UNION string: OctetSeq, int: INTEGER, taggedList: TaggedList, referencedValue: ReferencedValue END; TYPE ValueOpt = OPTIONAL Value; TYPE ValueSequence = SEQUENCE OF Value; TYPE ValueSequenceOpt = OPTIONAL ValueSequence; TYPE TagVal = RECORD tag: Tag, value: Value END; TYPE TaggedList = SEQUENCE OF TagVal; TYPE TaggedListOpt = OPTIONAL TaggedList; TYPE ReferencedValue = RECORD context: IntOpt, identifier: INTEGER END; (* 2.1.2.1 Request/Response ordering Messages are exchanged according to the negotiated level of synchronicity. If the level is synchronous, the server must complete the current operation before starting the next operation. All operations must be performed in the order in which they were received. If the level is set to out-of-order, the server may respond to messages in any order, but must complete each operation before beginning the next. If the level is set to interleaved, the server may respond to messages in any order, and may also begin a response without waiting for current responses to complete. If the level is set to predictive, in addition to sending interleaved responses, the server may also send responses before the corresponding request has been received. This allows servers to send documents it can predict the client will need without requiring extra round trips for the client to specifically request this. This facility is needed if the desired performance goals of 100 ms response times is to the met over wide area networks. *) TYPE SyncBehavior = ENUMERATION Sync, OutOfOrder, Interleave, Preemptive END; TYPE BitString = SEQUENCE of BYTE; TYPE BasicMetaInformation = RECORD contentLength: IntOpt, created: DateOpt, modified: DateOpt, contentType: Value, contentLanguage: ValueOpt END; TYPE BasicMetaInformationOpt = OPTIONAL BasicMetaInformation; TYPE InlinesMetaInfo = RECORD uri: URI, basicMetaInfo: BasicMetaInformationOpt, extendedMetaInfo: TaggedListOpt END; TYPE InlinesMetaInfoSeq = SEQUENCE of InlinesMetaInfo; TYPE InlinesMetaInfoSeqOpt = OPTIONAL InlinesMetaInfoSeq; TYPE OctetSeq = SEQUENCE OF BYTE; (* Contexts present ISL interesting problems: they will need to be resent when transport failures occur, so I need to retain state on the client side and retransmit before any pending operations. How do I do this in ILU/ISL? I'd like contexts to be full fledged objects, but to make them so would force round trips for their creation, a dead loss, as I read the current ISL specification. I'd also like to shadow them on the client, but I don't know how to do so. Question: Is there anyway to get resource ID's assigned on the client side? Question: what is the best way to get a bit vector? There is no fundamental type, so I guess I'll use array of BYTE for now. Question: How do I generate protocol transport errors for bad Tags? This would be a buggy client, but the server needs to indicate the bug back to a client in some form. *) TYPE ServerContextID = SHORT CARDINAL; TYPE VariableName = STRING; TYPE OptionName = STRING; TYPE Set = SEQUENCE of BYTE; (* set appropriate bit for the set *) TYPE Tag = SHORT CARDINAL; TYPE TagSeq = SEQUENCE of Tag; TYPE TagList = RECORD tag: Tag, value: TagSeq END; TYPE TagSet = RECORD tag: Tag, value: Set END; TYPE TagVariable = RECORD variableName: VariableName, value: Value END; TYPE OptionLevel = ENUMERATION Forbid, Allow, Prefer, Require END; TYPE OptionLevelOpt = OPTIONAL OptionLevel; TYPE Option = RECORD optionName: OptionName, level: OptionLevel END; TYPE Negotiate = RECORD field: Value, values: ValueSequenceOpt, level: OptionLevelOpt END; TYPE Range = RECORD (* XXX is this correct? Probably not *) begining : LONG CARDINAL, ending : LONG CARDINAL END; TYPE MetaInfoFieldsOpt = OPTIONAL MetaInfoFields; TYPE MetaInfoFields = RECORD contentLength: BOOLEAN, contentLanguage: BOOLEAN, created: BOOLEAN, modified: BOOLEAN, inlinebool: BOOLEAN, inlinemetainfo: MetaInfoFieldsOpt, extended: BOOLEAN, extendedFields: ValueSequenceOpt END; (* 2.1.2.4 Request Cancellation. A request may be canceled at any time. If a server receives a cancellation request for an operation which has not been completed, it should terminate that request. Because of latency issues, this cancellation can not the guaranteed. If the client receives an unsolicited response (one not corresponding to a previously issued request) which contains an undesired object, it should send a cancel request, even if the response has completed. This allows the server to gain better feedback to improve its prediction. In addition to canceling a request, it is also possible to issue a suspend request. This will suspend data stream until it is resumed or canceled by either the server or the client. This allows a browser to briefly interrupt the transfer of, for example, a set of inline images, if the user switches to a different page, and then resume them if the first page is revisited. *) TYPE CancelOrSuspend = ENUMERATION Cancel, Suspend END;