Subject: LTAP - XML Schema considerations

From: "Paweł Skarżyński" <[email-masked]>
Date: Wed, 20 Aug 2008 03:47:37 +0200

Hello!

I am currently implementing trusted archive following LTAP RFC draft #6.
The implementation is based on XML. While analysing the specification,
I found some things at least 'unclear':

1.
I'm a little stuck because of LISTIDS implementation.
On page 50 first paragraph after bullets is:
"The LTA returns a list of references as a sequence of DataOrTransaction items."

LTA have the signed LISTIDS request containing an artifact, found some objects'
ids so it is preparing response.

Type of top level element "Response" is "Response (page 42)
Response schema on page 36 contains single element "operationResponse"
of type "OperationResponse
(or single element 'errorNotice' of type 'StatusNotice').

OperationResponse type is a sequence of three elements (again on page 42):
a) "information" of type "RequestInformation", which I think, should
be a copy of "information" from obtained Request.
b) "status" of type "StatusNotice"
c) "data" of type "Data"

LISTIDS should return "a list of references as a sequence of
DataOrTransaction items".
I believe, all of the 'real' response content should be put in to
<data> element.
But definition of type "Data" does not allow me to put a sequence of
DataOrTransaction items!

On page 27 there ist "Data" XML Schema. It is a sequence containing:
a) One "dataReference" element of type "DataOrTransaction"
b) One "metaData" element of type "MetaData"
c) One "messageImprint" element of type "MessageDigest"

So according to above, it is impossible to put such sequence of DOT items.

2.
The initial request of LISTIDS should contain "data" element. What
should be a content of
"dataReference" (DOT type) is not written in the specification.
DOT can contain data (which in LISTIDS is meaningless), an artifact or
a reference (which is also
meaningless). So I assume, an artifact should be the right choice. If
I assumed correctly, such
assumption should be written somewhere in the chapter 6.6  (LISTIDS operation).
If a sequence of DOT items would be allowed, it should be specified
that if the request contained
an artifact, the first DOT item in sequence should  containt that artifact.

3.
Another thing is messageImprint. It is not clear, what should be
digested. dataReference?
metaData? concatenation of them? I assumed only dataReference.
After allowing many dataReferences it will be much more unclear.

4.
On page 42 there are XML top level definitions.
Type LTAPResponse is a choice of three elements.
In my opinion, the first choice, element "response", should be of type
"Response",
not "Request".

5.
The Artifact type - page 22.
If I think correctly, it is not important what's the content as far,
as it is a PrintableString.
For example, it may initially contain random floating point number. Am
I correct?

6.
The IA5String type... It took me more than a while to find out, that
it is a string with
double quotes in the begining and in the end without double quote
character in the content.
It really should be mentioned somewhere in the LTAP spec.

Uff, for now it's all. I made some assumptions, which may be wrong. I
am not an expert,
so please, feel free to point me where I'm thinking wrong :-)

Pawel Skarzynski

---

From: "Paweł Skarżyński" <[email-masked]>
Date: Sat, 23 Aug 2008 15:51:48 +0200

I forgot to mention another confusion:

On page 36 in section 5.4 there is a Response type schema.
The <Response> element may contain eihter an <operationResponse> or
<errorNotice>

errorNotice is of type StatusNotice, which is defined on page 35 in section 5.2
It contains a sequence of two elements:
a) <status> (of type StatusInformation)
b) <errorInformation> which contains UTF8String

When considering the <Response> which is an <errorNotice> - it is
obvious and clear.
But <Response> may be of type <operationResponse>.

<operationResponse> is a sequence of three elements:
a) <information>
b) <status> of type StatusNotice
c) <data>

Let's look closer at b). Now the response contains some real data. It
also contains status
which may be helpful for the client to show the response to the end-user.
But <status> is of type <StatusNotice> which enforces the LTA to return
<errorInformation> even, if the status is e.g. 'correct' or similar
positive value.

So in my opinion, the StatusNotice type should be modified, to enable
itself to contain
some 'positiveInformation' type.
For example the name of '<errorInformation>' may be changed to
'<statusData>' or other
'neutral' name.

Pawel Skarzynski