© 2005 Goetz Heller
Table of Contents Copyright Note backIt is quite common that during exchange of data some meta information about the data is needed which goes beyond structural information, which is delivered using XML. The most natural candidate to serve this purpose is the HTML <META> element, and exactly this idea applies in the dataPort framework. Meta has two attributes defined which we will be using throughout: name and content.
The kind of information transported via this mechanism can be classified into several domains. This classification is reflected by a prefix to the name attribute value, and is as follows:
| prefix | domain |
|---|---|
| pr | general processing |
| err | error handling |
| sec | security related |
| ses | session state handling |
| tr | transport related processing directives |
The following table summarizes the information pieces which have been identified so far to be useful in data headers.
| name | content |
|---|---|
| prRetVal | the return code issued by the server side processing module |
| prHandler | identifies a client-side routine to process the message body contents. This is meant to support workflow branching the decision point for which was met on the server. |
| errCode | code of an error condition detected by the server side processing module |
| errText | error message text |
| secAuthMethod | required authentication method |
| secChallenge | a challenge to be responded to by the client to prove authenticity |
| secSrvId | the encrypted servername which proves the server's identity |
| secEncryptionMethod | identifies the algorithm used to encrypt the data |
| secKey | encrypted key. the decrypted key can be used to decrypt the data |
| sesSid | server side session identifier |
| trBase64 | indicates that contents of message body need to be base64-decoded |
| trCompressed | indicates that contents of message body need to be decrompressed |
Note that the meta tag named prRetVal should not return application specific semantics to ease creation of standardized general protocol handling routines. Rather it should indicate normal termination, failure to handle a request (which refers to the error related meta tags for details), acknowledgement of a request, acknowledgement of a request with delayed processing and the like. Application specific information should be transported inside the message body. For the same reason, error information transported via err-meta tags should not be to specific. It should be sufficient to display a meaningful message to the user. Detailed error information (trace lists, faulty parameters etc.) should be placed into an error report inside the body. In combination with prHandler this should provide for enough flexibility to implement application specific error handling.