Re: LTAP - XML Schema considerations

["TS Glassey" <[e-mail]>]

Peter - how do you see the GEOPRIV controls fitting into LTAP?

Todd Glassey

----- Original Message ----- 
From: "Peter Sylvester" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, August 27, 2008 6:42 AM
Subject: Re: LTAP - XML Schema considerations


  PaweÅ, SkarżyÅ"ski wrote:
> Hello!
>
hello.
> I am currently implementing trusted archive following LTAP RFC draft #6.
>
Good.
> 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.
>
Indeed, that's a problem.

OperationResponse could have a SEQUENCE OF Data
or Data type could be
Data ::= SEQUENCE OF SEQUENCE {

Need to generate the xsd for both cases. ooops, the licence
for asn12xsd has expired.... will get back soon. :-)

> 2.
> The initial request of LISTIDS should contain "data" element.
I think the Data element in the request should be optional.
I had found some other point in the meantime:
The elements in the Data part should be optional.

Data ::= SEQUENCE {
dataReference DataOrTransaction ,
metaData MetaData OPTIONAL ,
messageImprint [0] MessageDigest OPTIONAL
}

<xsd:complexType name="Data">
<xsd:sequence>
<xsd:element name="dataReference" type="DataOrTransaction" />
<xsd:element name="metaData" type="MetaData"
minOccurs="0"/>
<xsd:element name="messageImprint" type="MessageDigest"
minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>

> 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.
>
The text is indeed unclear: What is intended is the following: The
'dataReference' field of the 'data ' field should have either
an 'artifact' or a 'reference'

After the correction of question 1; when there is a 'more' answer, then
the last element of the sequence SHOULD be used to request more.

> 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.
>
IMO what should be digested are the raw content octets of the data element.
The purpose is two-fold: When you repeat an archive operation without
any repsonse, a client may try the digest. If the digest is provided
also on input, then this can be used as some addition integrity check
at at application level.
This gives at least the same digest for the two textual cases in both
encodings.

> 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".
>
Yes.
> 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?
>
Well, floating point, I don't know, there is no semantics, only something
that allows a server to find a transaction that is running.

> 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.
>
double quotes??

The definition is the XER encoding of the ASN.1 IA5String type.
The "Additional XML definitions" contains a definition for the xml encoding
for IA5String. Is that what you ware looking for?

Thanks so far for the review







Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7REeY4b091242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Aug 2008 07:40:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7REeY9b091241; Wed, 27 Aug 2008 07:40:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7REeNte091222 for <[e-mail]>; Wed, 27 Aug 2008 07:40:33 -0700 (MST) (envelope-from [e-mail])
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=UBQdlbcT/JcvYJ80plybstT7s48urdq83JEBzO8SuZVoEZzVfb48spN53yzH9ozX; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [24.23.176.93] (helo=tsg1) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <[e-mail]>) id 1KYMC4-0000uJ-Fk; Wed, 27 Aug 2008 10:40:20 -0400
Message-ID: <001a01c90852$d860e8e0$6401a8c0@tsg1>
From: "TS Glassey" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: LTAP - XML Schema considerations
Date: Wed, 27 Aug 2008 07:40:22 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79558139146b80d6ca8553e68bd1a133dc350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 24.23.176.93
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Peter - how do you see the GEOPRIV controls fitting into LTAP?

Todd Glassey

----- Original Message ----- 
From: "Peter Sylvester" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, August 27, 2008 6:42 AM
Subject: Re: LTAP - XML Schema considerations


  PaweÅ, SkarżyÅ"ski wrote:
> Hello!
>
hello.
> I am currently implementing trusted archive following LTAP RFC draft #6.
>
Good.
> 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.
>
Indeed, that's a problem.

OperationResponse could have a SEQUENCE OF Data
or Data type could be
Data ::= SEQUENCE OF SEQUENCE {

Need to generate the xsd for both cases. ooops, the licence
for asn12xsd has expired.... will get back soon. :-)

> 2.
> The initial request of LISTIDS should contain "data" element.
I think the Data element in the request should be optional.
I had found some other point in the meantime:
The elements in the Data part should be optional.

Data ::= SEQUENCE {
dataReference DataOrTransaction ,
metaData MetaData OPTIONAL ,
messageImprint [0] MessageDigest OPTIONAL
}

<xsd:complexType name="Data">
<xsd:sequence>
<xsd:element name="dataReference" type="DataOrTransaction" />
<xsd:element name="metaData" type="MetaData"
minOccurs="0"/>
<xsd:element name="messageImprint" type="MessageDigest"
minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>

> 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.
>
The text is indeed unclear: What is intended is the following: The
'dataReference' field of the 'data ' field should have either
an 'artifact' or a 'reference'

After the correction of question 1; when there is a 'more' answer, then
the last element of the sequence SHOULD be used to request more.

> 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.
>
IMO what should be digested are the raw content octets of the data element.
The purpose is two-fold: When you repeat an archive operation without
any repsonse, a client may try the digest. If the digest is provided
also on input, then this can be used as some addition integrity check
at at application level.
This gives at least the same digest for the two textual cases in both
encodings.

> 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".
>
Yes.
> 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?
>
Well, floating point, I don't know, there is no semantics, only something
that allows a server to find a transaction that is running.

> 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.
>
double quotes??

The definition is the XER encoding of the ASN.1 IA5String type.
The "Additional XML definitions" contains a definition for the xml encoding
for IA5String. Is that what you ware looking for?

Thanks so far for the review






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7RDgVWt087390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Aug 2008 06:42:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7RDgVlp087389; Wed, 27 Aug 2008 06:42:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7RDgIWH087375 for <[e-mail]>; Wed, 27 Aug 2008 06:42:28 -0700 (MST) (envelope-from [e-mail])
Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 73F7A5D for <[e-mail]>; Wed, 27 Aug 2008 15:42:16 +0200 (CEST)
Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2008082715421552:92359 ; Wed, 27 Aug 2008 15:42:15 +0200 
Message-ID: <[e-mail]>
Date: Wed, 27 Aug 2008 15:42:15 +0200
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: LTAP - XML Schema considerations
X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 08/27/2008 03:42:15 PM, Serialize by Router on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 08/27/2008 03:42:16 PM, Serialize complete at 08/27/2008 03:42:16 PM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090602010000050104060305"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a cryptographically signed message in MIME format.

--------------ms090602010000050104060305
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

  Pawe=C5=82 Skar=C5=BCy=C5=84ski wrote:
> Hello!
>  =20
hello.
> I am currently implementing trusted archive following LTAP RFC draft #6=
=2E
>  =20
Good.
> 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 DataOrTransactio=
n 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 4=
2):
> 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 ite=
ms.
>  =20
Indeed, that's a problem.

OperationResponse could have a SEQUENCE OF Data
or Data type could be
Data ::=3D SEQUENCE OF SEQUENCE {

Need to generate the xsd for both cases. ooops, the licence
for asn12xsd has expired.... will get back soon. :-)

> 2.
> The initial request of LISTIDS should contain "data" element.=20
I think the Data element in the request should be optional.
I had found some other point in the meantime:
The elements in the Data part should be optional.

Data ::=3D SEQUENCE {
dataReference DataOrTransaction ,
metaData MetaData OPTIONAL ,
messageImprint [0] MessageDigest OPTIONAL
}

<xsd:complexType name=3D"Data">
<xsd:sequence>
<xsd:element name=3D"dataReference" type=3D"DataOrTransaction" />
<xsd:element name=3D"metaData" type=3D"MetaData"
minOccurs=3D"0"/>
<xsd:element name=3D"messageImprint" type=3D"MessageDigest"
minOccurs=3D"0"/>
</xsd:sequence>
</xsd:complexType>

> 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 ope=
ration).
> 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 artif=
act.
>  =20
The text is indeed unclear: What is intended is the following: The
'dataReference' field of the 'data ' field should have either
an 'artifact' or a 'reference'

After the correction of question 1; when there is a 'more' answer, then
the last element of the sequence SHOULD be used to request more.

> 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.
>  =20
IMO what should be digested are the raw content octets of the data elemen=
t.
The purpose is two-fold: When you repeat an archive operation without
any repsonse, a client may try the digest. If the digest is provided
also on input, then this can be used as some addition integrity check
at at application level.
This gives at least the same digest for the two textual cases in both
encodings.

> 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".
>  =20
Yes.
> 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?
>  =20
Well, floating point, I don't know, there is no semantics, only something=

that allows a server to find a transaction that is running.

> 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.
>  =20
double quotes??

The definition is the XER encoding of the ASN.1 IA5String type.
The "Additional XML definitions" contains a definition for the xml encodi=
ng
for IA5String. Is that what you ware looking for?

Thanks so far for the review




--------------ms090602010000050104060305
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOhTCC
BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ
IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c
IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb
zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8
oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN
rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi
XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ
TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q
M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd
UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw
MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL
PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2
pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3
0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ
RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS
J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct
BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx
RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl
X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo
ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3
6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py
UJzWSwWBel1QRyETQNwwggWVMIIDMKADAgECAgYKwoI0lJgwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDcwNjI4MTc0MDU0WhcNMTQwNTAyMTc0
MDU0WjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4GgMIGdMDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAfBgNV
HSMEGDAWgBSo2SuP1LBnur1JXLwz/HdSEblnnTANBgkqhkiG9w0BAQUFAAOCAk4AUgtIR4Jh
Ynyk939SM6X4YZPNYIgDio8Gp064P1MBILDgI/hzSwyxT5bb1qUQub+icXO9/5ufsDufr/ff
2gCzKMuo3hC26iey630PzHTvJgrTcEp9c92IZPt3UKeouqy+95Lz2r58dbfouKLZVwiKQ0jP
2c2U5tPWmzW4CAjFWUKRYlrhbt+tjzW8CAA0DHO1xrrzAuTyuGNKcH4LlLuVo7MbDPn/uLma
1fAVYvH2c6OTwGHJyKTQVveYw4UqgAhErJMFWJDKm+Q9h91mCzkjrA1Eu0nVDUTV1+dW6mNT
DPLIq0qSdqP7iT2WcNzQVy/0PiXT2aaEH9lE2W1SSD6PnT8y+aqJTGjRMK1cl7VSJHxbq8U9
lIS+6eiV5VrogAa8X52pKF0u91i+/CBZ3e5Mi2/BwMrMN/mXA/ZwL3p+jZpnijpqnqdz8iCn
qR9ExhR+BpN/b56RqEu7llLrcwOS44kjbubALjxe0+XutidWjt/6/tLYuM7rJ6Hk1EweFGVd
kRejKogD3GzZ3gOAIF/D28VBJcTRcyF7OI/k/3jPD0gHUGN1uxk2Krz8SE9GEPvP/JehCBl/
FrQOCsEUmszi7Se0Vxr2k1P7icxT7L/AcWt/djIgp/vsQNurbi0+5+q7YS2b2bc1HchjsmaI
cXy8ha5IGk4+F1qrHZsGqTm5M7TzZN6k0X2llMaozrtPzxNMC6uvf1uRvHYHf1x0Q0pdxTzZ
PuuFw1PUlu6o5xPHbf3ZgC7ZNSDry13ZEXmlG2Re0u9WwEJJ1nYqlcDvNzGCAq4wggKqAgEB
MGUwWzELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2Ug
RWRlbFBLSTEgMB4GA1UEAxMXRWRlbFBLSSBFZGVsV2ViIFBlcnNHRU4CBgqvijKA3jAJBgUr
DgMCGgUAoIIBnzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w
ODA4MjcxMzQyMTVaMCMGCSqGSIb3DQEJBDEWBBRegUWXUPS01Mop+YibbEP0yyZENjBSBgkq
hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB0BgkrBgEEAYI3EAQxZzBlMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wdgYLKoZIhvcNAQkQAgsxZ6Bl
MFsxCzAJBgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVk
ZWxQS0kxIDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wDQYJKoZI
hvcNAQEBBQAEgYCCO0oXkaT6mmapVcTzUEgvx99C7YErNZgPELHoErKLsaaZvHKMc2y3Hwwt
IlBPd/5kClY4CED298tLKQ9aElRgn8+8v89y+166eXDlot7ZVavBpLkyjN9+qI2v+Fj58qTD
HMxL28aokwMY9WVO3jz4tiGaM2B1R5fxt2M1ZS+gwwAAAAAAAA==
--------------ms090602010000050104060305--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7NDppRj049118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Aug 2008 06:51:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7NDppt6049117; Sat, 23 Aug 2008 06:51:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7NDpnjN049107 for <[e-mail]>; Sat, 23 Aug 2008 06:51:50 -0700 (MST) (envelope-from [e-mail])
Received: by ik-out-1112.google.com with SMTP id c21so758930ika.2 for <[e-mail]>; Sat, 23 Aug 2008 06:51:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=qp5+3sHYfW9lEna68IODEtMFzruuPUooudZXzMpC9n8=; b=YqhHcK6yaw5mxSRH1Hv5WuV6or82E1FqUgQoVZbVmQG0uuB6x6No8XR6TJlPpKcdaz bUv5Om+irS9oU14ovE2/WVAcQpiMmYbRqAVizNRq/FklskFYXCyi3sAKmlfIOgq/BjIv NF5j/bHXYNyMGOJZgMXKP6MnJ+JNu38a50WeM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=DMXPT6TzlAS0mmXF9Rs4Iy1pkrdbNrZT4j7jVcY4M1zFnbIxJbMhhwBNImJBhAjcYe cZg+35RgXxpuHZQ/6Bw39I/kXf4wOArjA3irpJF7ANJ7gUukFJn3RdCJ7K5te4HoRvOW BVeYcn0bmROCGPJtMxnz7PrUVmK2fwY6120jU=
Received: by 10.210.20.17 with SMTP id 17mr2078772ebt.170.1219499508407; Sat, 23 Aug 2008 06:51:48 -0700 (PDT)
Received: by 10.210.65.12 with HTTP; Sat, 23 Aug 2008 06:51:48 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sat, 23 Aug 2008 15:51:48 +0200
From: "=?ISO-8859-2?Q?Pawe=B3_Skar=BFy=F1ski?=" <[e-mail]>
To: [e-mail]
Subject: Re: LTAP - XML Schema considerations
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7NCTrto043103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Aug 2008 05:29:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7NCTrr1043102; Sat, 23 Aug 2008 05:29:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ey-out-1920.google.com (ey-out-1920.google.com [74.125.78.144]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7NCTp57043096 for <[e-mail]>; Sat, 23 Aug 2008 05:29:52 -0700 (MST) (envelope-from [e-mail])
Received: by ey-out-1920.google.com with SMTP id 21so109746eyc.28 for <[e-mail]>; Sat, 23 Aug 2008 05:29:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=4E3HLO8NgBSrauQMTxvGtIuxAs8jdFGgRBlvtiCget0=; b=sCKwdGZeyVXvoLHVg2UrjYbJGLchE8YnEdSf7qQ0T+//cSYyoU78i2Mr05ZntyKSdG P9OvNnDIe/D4LIoeUJWhO/n9kKr5/Ybd7ftemugP6CHOkyCRSepix9okkIEiXM3sXi4Q WOzdmuvFEUFopTREG9o54Emko/n543fs3kzew=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=nw6pvntKS8nigCQ5vQSNf789b01JIkszwcUh1FatRuClka+5WA4sb2fjwq4lkfAAQj WGkz3a2zZLcL7xwBIXuLkonSTtKIP4tmPQ0bQbnYmLNZTJvg/F312efnwJ6M8HGVkJct aHXFlwkZRpJvo0UKcCHKGWI1nrSGWFXXnLfLc=
Received: by 10.210.71.12 with SMTP id t12mr3184852eba.146.1219494589864; Sat, 23 Aug 2008 05:29:49 -0700 (PDT)
Received: by 10.210.65.12 with HTTP; Sat, 23 Aug 2008 05:29:49 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sat, 23 Aug 2008 14:29:49 +0200
From: "=?ISO-8859-2?Q?Pawe=B3_Skar=BFy=F1ski?=" <[e-mail]>
To: [e-mail]
Subject: Typos in LTAP draft 6
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Hello!

While I was reading the doc, I found some typos. So here they are, I
hope that it will be helpful:

1. Page 12, second paragraph after L4:
currently: "(not necssarily"
should be: "(not necessarily"

2. Page 23, the last paragraph (section 4.3.)
currently: "The 'type' identfies "
should be: "The 'type' identifies"

currently: "similar way as withe MIBs"
should be: "similar way as with MIBs"
OR
should be: "similar way as with the MIBs"

3. Page 31, Section 4.13.
currently: "The response is an second" (repeated twice, line by line)
should be: "The response is a second"

4, Page 38, third 'bullet' from top in section 6.1.
currently: "If this a retry of a previous operation,"
should be: "If this is a retry of a previous operation,"

5. Page 41, paragraph 1, first sentence:
currently: "This memo defines are two basic ways"
should be: "This memo defines two basic ways"

6. Page 41, paragraph 1, last sentence:
currently: "for XML encoded requesta nd responses."
should be: "for XML encoded request and responses."

7. Page 41, paragraph 4:
currently: "LTAPRequest or LTAPResponse are used, an not an XER version"
should be: "LTAPRequest or LTAPResponse are used, and not an XER version"

8. Page 44, second paragraph of section 7.4.
currently: "When an end user client creates a request, there are only
one signerInfo"
should be: "When an end user client creates a request, there is only
one signerInfo"

9. Page 46, last sentence of second paragraph:
currently: "Aa LTA MAY profide for a service to validate"
should be: "An LTA MAY profide for a service to validate"

I am also pretty sure that there was at least one typo before the
first mentioned by me, but I didn't started making notices from the
begining of the memo and now I couldn't find it.

Pawel Skarzynski



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7K1ldYR027308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Aug 2008 18:47:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7K1ldFF027307; Tue, 19 Aug 2008 18:47:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7K1lbIS027299 for <[e-mail]>; Tue, 19 Aug 2008 18:47:39 -0700 (MST) (envelope-from [e-mail])
Received: by nf-out-0910.google.com with SMTP id 30so108071nfu.24 for <[e-mail]>; Tue, 19 Aug 2008 18:47:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=qHvj6m0Et0Taf2x++Vxl8Y1aIOk5cHgCBZMXPaCMGJw=; b=Ie43w8O7cAcVUAb9Ih1twlACBcYxwSq0xC6VKlf3cpiyqFic8J9cP64MJZjGEtDMZV gEXdHw3Datvh54fyfhSB69xHWVPuSlWsH3+YXMODYGzexj4nyMqrc6ia6GazdD53ujeG oh0bJFEe9kOEoYlx2rlSXIDV+OdhaPtYY9b5E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=lcpC5aEAzxPhl1TvkDBrVqtwAUR3UhSeD661GUW1dM35roDHcxk1ql9FHQ0VhZE9Up uSg0LQt6I3uE1mUL0rcRks2SrJCVURK3Hjl7tvKSW3XWts6uUE4qIg0fsNuX84rUXGfV 4zSUxYiDvptS1U3NxB4zCjvTOf6uNDu5NM5m0=
Received: by 10.210.122.5 with SMTP id u5mr7758718ebc.118.1219196857424; Tue, 19 Aug 2008 18:47:37 -0700 (PDT)
Received: by 10.210.65.12 with HTTP; Tue, 19 Aug 2008 18:47:37 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 20 Aug 2008 03:47:37 +0200
From: "=?ISO-8859-2?Q?Pawe=B3_Skar=BFy=F1ski?=" <[e-mail]>
To: [e-mail]
Subject: LTAP - XML Schema considerations
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DGbMVH058170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 09:37:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7DGbM9L058169; Wed, 13 Aug 2008 09:37:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DGbLe8058163 for <[e-mail]>; Wed, 13 Aug 2008 09:37:22 -0700 (MST) (envelope-from [e-mail])
Received: by bosco.isi.edu (Postfix, from userid 70) id 71F7414DCBD; Wed, 13 Aug 2008 09:37:21 -0700 (PDT)
To: [e-mail], [e-mail]
Subject: RFC 5276 on Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records
From: [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
Date: Wed, 13 Aug 2008 09:37:21 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

A new Request for Comments is now available in online RFC libraries.

        
        RFC 5276

        Title:      Using the Server-Based Certificate Validation 
                    Protocol (SCVP) to Convey Long-Term Evidence 
                    Records 
        Author:     C. Wallace
        Status:     Standards Track
        Date:       August 2008
        Mailbox:    [e-mail]
        Pages:      13
        Characters: 27422
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ltans-ers-scvp-07.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5276.txt

The Server-based Certificate Validation Protocol (SCVP) defines an
extensible means of delegating the development and validation of
certification paths to a server.  It can be used to support the
development and validation of certification paths well after the
expiration of the certificates in the path by specifying a time of
interest in the past.  The Evidence Record Syntax (ERS) defines
structures, called evidence records, to support the non-repudiation
of the existence of data.  Evidence records can be used to preserve
materials that comprise a certification path such that trust in the
certificates can be established after the expiration of the
certificates in the path and after the cryptographic algorithms used
to sign the certificates in the path are no longer secure.  This
document describes usage of the SCVP WantBack feature to convey
evidence records, enabling SCVP responders to provide preservation
evidence for certificates and certificate revocation lists (CRLs).  
[STANDARDS TRACK]

This document is a product of the Long-Term Archive and Notary Services Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
USC/Information Sciences Institute




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CGesnp048595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 09:40:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CGes7S048594; Tue, 12 Aug 2008 09:40:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m7CGeqxh048588 for <[e-mail]>; Tue, 12 Aug 2008 09:40:53 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 25362 invoked from network); 12 Aug 2008 16:29:00 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;12 Aug 2008 16:29:00 -0000
X-EntrustECS-Action: Trigger(Corporate IP)
X-EntrustECS-Id: (scygmxsecs1.cygnacom.com)1218558540134243089
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 12 Aug 2008 16:29:00 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: FW: Failing of IPR Filing Page when makling updates in re LTANS and other filings.
Date: Tue, 12 Aug 2008 12:40:46 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Failing of IPR Filing Page when makling updates in re LTANS and other filings.
Thread-Index: Acj8l4ipc066C/ABSDWZX6IFAUFz9wAApkzQ
From: "Carl Wallace" <[e-mail]>
To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

FYI=20

-----Original Message-----
From: TS Glassey [mailto:[e-mail]]=20
Sent: Tuesday, August 12, 2008 12:02 PM
To: [e-mail]; [e-mail]; IETF Discussion
Cc: Contreras, Jorge; Carl Wallace
Subject: Failing of IPR Filing Page when makling updates in re LTANS and
other filings.

Folks - I found several working flaws with the IPR disclosure page when
I went back to the IPR201 filing this AM to add several additional
Internet Draft's for notice of Patent Controls; As to the IPR Page - it
does not allow for updates of already filed IPR Statement's to include
new IETF documents which violate the patent rights after the posting of
the IPR Notice.

So then how does one add more IETF infringing document's to an existing
IPR declaration.

That said we wanted to add several more document's which infringe on the
patent protected IP's which we have refused to grant any rights to the
IETF for. Those new additional documents include the latest LTANS DSSC
(draft-ietf-ltans-dssc-03) document and to some extent Donald Eastlakes
XML Signature RFC from 2002 (rfc3275)

Luckily our patent filing predates ANY work on the XML signing document
here in the IETF and for that matter in the W3C as well meaning lots of
good things regarding that patent and its infringers.

---
Personal Disclaimers Apply

TS Glassey



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CBcNe4023669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 04:38:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CBcN4g023668; Tue, 12 Aug 2008 04:38:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m7CBcMYv023658 for <[e-mail]>; Tue, 12 Aug 2008 04:38:22 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 22806 invoked from network); 12 Aug 2008 11:26:23 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;12 Aug 2008 11:26:23 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 12 Aug 2008 11:26:23 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: Working group last call for DSSC
Date: Tue, 12 Aug 2008 07:38:09 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Working group last call for DSSC
Thread-Index: Acj8b+TvJyPro3bZT7agQwtTOMCmCw==
From: "Carl Wallace" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

A new version of DSSC was submitted in May to address issues raised
during the Philadelphia meeting.  Working group last call for this draft
will begin today and last for four weeks (due to vacations, etc.),
ending on September 9th.  Please review the draft located at
http://tools.ietf.org/html/draft-ietf-ltans-dssc-03 and provide comments
to the list.  Thanks.