Subject: updated protocol and dsig drafts
From: "Donald E. Eastlake 3rd" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Sun, 31 Oct 1999 18:42:59 -0500

Although they can't be posted to Internet drafts due to the refractor
period before the IETF meeting, new versions of the IOTP V1.0 protocol
and dsig drafts are available.  They are at

<ftp://ftp.pothole.com/pub/ietf-trade/draft-ietf-trade-iotp-v1.0-dsig-05.txt>
and
<ftp://ftp.pothole.com/pub/ietf-trade/v1.0-protocol-07/iotp-v1.0-protocol-07.txt>

Other than new dates, versions numbers, etc., the only substantive
change in IOTP DSIG is a one line change to fix a syntax problem in
the DTD.  The protocol document also has that change and some other
minor changes.  I expect a change summary for the protocol document to
also be posted soon.

These updated drafts will probably be posted as Internet-Drafts as
soon as theat can be done.  The changes are minor but I thought people
might want to see them.

Thanks,
Donald
=====================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668     [email-masked]
 65 Shindegan Hill Road, RR#1  +1 914-784-7913(work)  [email-masked]
 Carmel, NY 10512 USA
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: [email-masked]
To: [email-masked]
Date: Thu, 28 Oct 1999 15:51:14 -0400
Subject: ECML & Micropayments BoFs, EDIINT, at IETF
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Those on this mailing list might be interested to know that a BoF on ECML
<http://www.ecml.org> has been scheduled for Wednesday afternoon and a BoF
on Micropayments has been scheduled for Monday afternoon at the upcoming
IETF meeting.  There is also a meeting of the EDI-Internet Integration
working group Tuesday afternoon.

Thanks,
Donald

Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
[email-masked]   tel: 1-914-276-2668

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: Wong Ka Cheong <[email-masked]>
cc: [email-masked]
Subject: Re: Where to find Payment Method supplement 
Date: Mon, 25 Oct 1999 16:31:47 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

There is a SET supplement available at
<ftp:/ftp.pothole.com/pub/ietf-trade/setiotp_ver099.zip>.

Donald

From:  Wong Ka Cheong <[email-masked]>
Date:  Tue, 26 Oct 1999 01:32:21 +0800 (HKT)
To:  [email-masked]
Message-ID:  <[email-masked]>

>Hi all,
>
>	Is there any Payment Method Supplement for IOTP? If so, where to
>find it.
>
>Thanks
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

Full-Name: Wong Ka Cheong
Date: Tue, 26 Oct 1999 01:32:21 +0800 (HKT)
From: Wong Ka Cheong <[email-masked]>
To: [email-masked]
Subject: Where to find Payment Method supplement 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Hi all,

	Is there any Payment Method Supplement for IOTP? If so, where to
find it.

Thanks

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: [email-masked]
To: [email-masked]
Date: Mon, 25 Oct 1999 14:35:17 +0200
Subject:  Micro Payments BOF in the next IETF (Nov 99, Wash DC)
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

FYI - I think there may be interest among IOTP folks in the following...

The Micro Payments BOF at the next IETF (in Wahington DC) will occur on
Monday, Nov. 8th, at 1530-1730. Enclosed are the current agenda (subject to
change - proposals welcome) and description. Notice that at least we (IBM) plan
to describe in details our payment messages, to facilitate interoperable
implementations and to serve as potential basis for a standard.

Please excuse cross posting - and forward to relevant persons and groups.
Thanks!

Agenda:

   Reports on  the W3C Micropayments Markup spec and implementations of it
     Thierry Michell from W3C who is in charge of this activity will describe it
     Amir Herzberg from IBM will present release 1.3 of IBM Micro Payments
     implementation of the W3C Micropayments Markup spec
     Other implementations may be described as well as comments about the spec
   Reports on open designs which are proposed as basis for potential IETF
   standardization
     Amir Herzberg will present the IBM Micro Payments design
     Other designs may be presented
   Discussion of the goals of (micro)payment standardization activity in the
   IETF
     Mark Manasse (Compaq): what we're (MilliCent) hoping for in a standard
     Use the IBM Micro Payments design as basis to a standard
     Or, open discussion to alternative approaches and select one (or some
     combination) first
     Limit to micropayments or cover also larger payments?
     Attempt to agree on rough charter and goals

Description - Micro Payments BOF (micropay):

The Internet is quickly becoming the prefered method of delivery for information
and on-line services. The growth of
this industry is resticted by the limited availability of secure online payment
mechanisms, especially for small amounts. Micropayments are designed to allow
charging of small amounts, where the minimal fees of credit-card payments are
unacceptable. There have been, and still are, many attempts at providing a
micropayments solution, however so far none of them was successful, and in
particular none of the deployed systems seems to be able to reach critical mass
of buyers and sellers. Furthermore, even if one or more of these systems gain
popularity, the lack of standardization may slow down their availability. In
this BOF we'll review some recent micropayment markup standardization spec from
the W3C, and discuss whether the IETF should attempt to contribute standards in
this area  - i.e. should we create a micropayments WG (and if so what would its
charter and goals be).

Best Regards,
Amir Herzberg
Manager, E-Business and Security Technologies
IBM Research Lab in Haifa (Tel Aviv Office)
http://www.hrl.il.ibm.com
New e-mail: [email-masked]
New Lotus notes mail: amir herzberg/haifa/ibm@IBMIL

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-iotp-v1.0-dsig-04.txt
Date: Wed, 20 Oct 1999 06:57:49 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.

	Title		: Digital Signatures for the v1.0  Internet Open Trading
                          Protocol (IOTP)
	Author(s)	: K. Davidson, Y. Kawatsura 
	Filename	: draft-ietf-trade-iotp-v1.0-dsig-04.txt
	Pages		: 31
	Date		: 19-Oct-99
	
A syntax and procedures are described for the computation and
verification of digital signatures for use within Version 1.0 of the
Internet Open Trading Protocol (IOTP).
[Changes from previous draft: correction of one line in DTD, addition
of reference to RFC 2253 in section 4.4.2.]

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-dsig-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-trade-iotp-v1.0-dsig-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-dsig-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-dsig-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-trade-iotp-v1.0-dsig-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Subject: TRADE WG November Meeting at IETF Scheduled
Date: Tue, 19 Oct 1999 21:54:11 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

The TRADE WG is meeting at the November IETF meeting in Washington DC
from 3:30pm to 5:30pm Wednesday November 10th.

Thanks,
Donald

=====================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668     [email-masked]
 65 Shindegan Hill Road, RR#1  +1 914-784-7913(work)  [email-masked]
 Carmel, NY 10512 USA
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: 'Masaaki Hiroya' <[email-masked]>
Cc: "IETF Trade (E-mail)" <[email-masked]>
Subject: RE: IotpMsgIdPrefix for InquiryResp messages
Date: Tue, 19 Oct 1999 11:13:10 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BF1A5D.D207953A
Content-Type: text/plain;
	charset="iso-8859-1"

Masaaki

The key point about IotpMsgIds is that they are unique. Section 3.4.1 is
designed to provide guidance on how to generate the IotpMsgId to ensure they
are unique. The actual values are not particularly important although the
various trading roles need to know what domain of Ids they can use that will
ensure uniqueness, hence the prefix.

I think the simplest solution is to use the prefix "I" for both Inquiry and
Ping Requests. I'm reluctant to use the same prefix for responses since it
invalidates the guideline for IotpMsgSuffixes which says:
	" o the first IOTP Message sent by a trading role is given the
suffix "1"
	  o the second and subsequent IOTP Messages sent by the same trading
role are incremented by one for each message".

So I've changed the first two paragraphs that define the IotpMsgIdPrefix to
read ...
>>
Apart from messages which contain: an Inquiry Request Trading Block, an
Inquiry Response Trading Block, a Ping Request Trading Block or a Ping
Response Trading Block; then the same prefix is used for all messages sent
by the Merchant or Consumer role as follows:
o "M" - Merchant
o "C" - Consumer

For messages which contain an Inquiry Request Trading Block or a Ping
Request Trading Block, the prefix is set to "I" for Inquiry.

For messages which contain an Inquiry Response Trading Block or a Ping
Response Trading Block, the prefix is set to "Q".
<<

Note that the choice of "Q" is completely aribitrary.

Regards

David

-----Original Message-----
From: Masaaki Hiroya [mailto:[email-masked]]
Sent: Monday, October 18, 1999 6:59 AM
To: David Burdett
Cc: [email-masked]
Subject: IotpMsgIdPrefix for InquiryResp messages

David

I want to confirm which IotpMsgIdPrefixes should be used for 
InquiryResp messages.  

IOTP Spec defines IotpMsgPrefix on page 39 as follows:

> Apart from messages which contain an Inquiry Request Trading 
> Block (see section 8.12), the same prefix is used for all messages
> sent by the Merchant or Consumer role as follows:
> o "M" - Merchant
> o "C" - Consumer

> For messages which contain an Inquiry Request Trading Block, 
> the prefix is set to "I" for Inquiry.

Should "M", "P", or "D" be used for InquiryResp messages?

If so and the Inquiry Transaction is made during the Purchase 
Transaction, how does the server assign the number to the 
IotpMsgId for each message? Just a different number which was
previously used on the transactions with the same IotpTransId?
##This was my original thinking##

Why does the InquiryReq message uses "I" as an IotpMsgPrefix 
but the Inquiry Resp message doesn't?
##Because it is possible that a non-consumer role might inquire on the
status of a transaction therefore a neutral prefix helps.##

I thought the client uses odd numbers such as "I1", "I3",
and the server uses even numbers generated by incrementing
the received InquiryReq Message's MsgId such as "I2", "I4".
##This is an equally possible alternative##

What do you think?

I have one more thing to confirm the rules of IotpMsgPrefixes.
For Ping Transactions, "C", "M", "P" or "D" is used
as an IotpMsgPrefix, isn't it?

I think there will be no problems in this case since
Ping Transactions have the different IotpTransId from
any other transactions including the Purchase Transactions.

Regards
Masaaki

-----
Masaaki Hiroya
Systems Development Laboratory
Hitachi, Ltd.
email: [email-masked]
tel: +81-44-549-1531
fax: +81-44-549-1640

------_=_NextPart_000_01BF1A5D.D207953A
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

------_=_NextPart_000_01BF1A5D.D207953A--
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Subject: Re: digital signature comments 
Date: Mon, 18 Oct 1999 09:52:26 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Greg,

I think that the DOMHASH document makes it pretty clear that its
output is a message digest.  This is certainly less flexible than
specifying canonicalization and digesting separately but, given
the plan to convert to the XMLDSIG standard when it is set for
future versions of IOTP, I don't see this as much of a problem.

On dinstinguished names, I also tend to think the view of them
as opaque identifiers within IOTP is the simplest.  On the other
hand, does anyone see any problem with recommending or speicfying
use of the RFC 2253 syntax?

Thanks,
Donald

From:  Yoshiaki KAWATSURA <[email-masked]>
Message-Id:  <[email-masked]>
To:  [email-masked]
Cc:  [email-masked]
Date:  Fri, 24 Sep 1999 12:56:13 +0900 (JST)

>Hello Greg,
>Thank you for your feedback.
>My comments below.
>
>>>>>> Tue, 21 Sep 1999 13:56:07 -0700,
>	Greg Whitehead <[email-masked]> said:
>
>>4.3.1 Signature
>>---------------
>>
>>>From the text:
>>
>>>  The process for generating the signed value is a multi-step process,
>>>  involving a canonicalization algorithm, a digest algorithm, and a
>>>  signature algorithm.
>>>
>>>  First, the Manifest is canonicalized with an algorithm specified
>>>  within the Algorithm element of the Manifest. The canonicalized form
>>>  removes any inconsistencies in white space introduced by XML parsing
>>>  engines.
>>>
>>>  This canonicalized form is then converted into a digest form which
>>>  uniquely identifies the canonicalized document. Any slight
>>>  modification in the original document will result in a very different
>>>  digest value.
>>
>>This suggests that a canonicalization algorithm must be specified in the
>>Manifiest (section 4.3.2), yet the Algorithm type (section 4.3.3) provides
>>no way to do that. 
>>
>>It appears that canonicalization has been folded into the digest algorithm,
>>which makes sense since the two are sometimes inseparable (DOMHASH), but
>>this should be clarified.
>>
>>If DOMHASH is, in fact, meant to include canonicalization, it would be good
>>if its spec [2] provided specific details (along with test cases and their
>>respective digest values).
>
>I understand.
>If we want to use the canonicalization algorithm, which can not be hashed
> by itself, we need to use Parameter element as follows:
>
><Algorithm name='urn:fips:sha1' type='digest' ID='P.3'>
></Algorithm>
><Algorithm name='urn:w3c:C14N' type='digest' ID='P.4'>
> <Parameter type="AlgorithmRef">P.3</Parameter>
></Algorithm>
>
>Of course, I know C14N is not digest algorithm, but if we revise that
>'canonicalization' is added as the type parameter, we have to revise
>the IOTP Specification also(though this is minor change...).
>As results, I do not change until other people appeals to want to do it.
>
>>4.4.2 IssuerAndSerialNumber
>>---------------------------
>>
>>As used in CMS, IssuerAndSerialNumber is a binary structure lifted directly
>>from the certificate.  In IOTP-DSIG, the issuer name (X.500 DN) and serial
>>number (ASN.1 Integer) are each represented as strings.  Unfortunately,
>>converting DNs to strings is non-trivial (internally, DNs are binary
>>structures that use ASN.1 OIDs to identify attributes and determine the
>>encoding of their values).
>>
>>If IssuerNameAndSerialNumber is simply meant to serve as an opaque
>>identifier, to name Certificate elements included in IOTPSignatures, then
>>there is no problem: any scheme that produces unique identifiers will work
>>(why not just use an IDREF in that case?)
>
>>If, however, it is meant to serve as a key for locating certificates in an
>>external repository, such as an LDAP directory, then the format needs to be
>>more precisely specified.  I would suggest rfc2253 (LDAPv3: UTF-8 String
>>Representation of Distinguished Names) as a starting point:
>>
>>	http://www.ietf.org/rfc/rfc2253.txt
>>
>
>I assume the first case but the second case is very interested for me.
>I suggest this issue should be discussed in the xml-dsig WG.
>
>Thanks,
>----
>Yoshiaki Kawatsura : E-mail [email-masked]
> Business & Information Systems Development Division, Hitachi,Ltd.
>Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: "'Smith, Chris '" <[email-masked]>,  "[email-masked]'" <[email-masked]>
Cc: "IETF Trade (E-mail)" <[email-masked]>,  "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>
Subject: RE: Bug in IOTP's DTD
Date: Fri, 15 Oct 1999 08:22:14 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Chris

The reasons are historical to do with the way the digital signatues for IOPT
were developed.

Firstly the IOTP specification with its own digital signature specification
as part of the spec. Later, it was realised that the digital signature part
should be removed and made a separate standard. At the same time as this was
going on the idea of a "Packaged Content" element was being developed in the
main IOTP specification with a default of "NONE"

Then around a year ago it was agreed to base the IOTP digital signature
specification on the work being done by Richard Brown of Globeset as part of
the W3C/IETF digital signature work.

As IOTP couldn't wait for the IETF/W3C group to finish it work we took an
early version of Richard Brown's specification, and built the IOTP dsig from
that. However, this specification had defined "value" differently from the
way it was done in IOTP with a default of "base64".

Hence the difference.

David

-----Original Message-----
From: Smith, Chris [mailto:[email-masked]]
Sent: Friday, October 15, 1999 7:32 AM
To: David Burdett; [email-masked]'
Cc: IETF Trade (E-mail); [email-masked]';
[email-masked]'
Subject: RE: Bug in IOTP's DTD

Interesting. The following is a rather subtle point, easily missed
when viewing the DTD (and NOT actually an error), but...

IOTP PackagedContent has

 <!ELEMENT PackagedContent (#PCDATA) >
 <!ATTLIST PackagedContent
  Name        CDATA            #IMPLIED
  Content     NMTOKEN          "PCDATA"
  Transform   (NONE|BASE64)    "NONE" >

while IOTP,DSIG has (corrected with removing the #IMPLIED)

 <!ELEMENT Value (#PCDATA) >
 <!ATTLIST Value
  ID          ID               #IMPLIED
  encoding    (base64|none)    'base64' >

Is there a specific reason that the attributes 
"encoding" and "Transform" don't agree on parameter
content and the default value of the parameter,
even though they are almost exactly the same
thing? Also, I can live with 'encoding' but this
is risking confusion with 'encoding' as it refers
to character sets like ISO-8859-1 (and as used on
the <?xml ...> XML declaration).

I realize that IOTP and DSIG are being worked on
independently, but could we have them be a little
less independent?

------------------------------------------------------------
 Chris Smith                                +1.416.348.6090
 Royal Bank                       [email-masked]

> -----Original Message-----
> From: David Burdett [mailto:[email-masked]]
> Sent: October 14, 1999 08:55 PM
> To: [email-masked]'
> Cc: IETF Trade (E-mail); [email-masked]';
> [email-masked]'
> Subject: RE: Bug in IOTP's DTD
> 
> 
> Masaaki
> 
> I accept that there is a mistake in the IOTP DTD, however 
> this part of the IOTP DTD was copied **directly** from the 
> the IOTP dsig spec at
> 
> 	
> http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0
> -dsig-03.txt
> 
> which contains the same error. The only changes made when 
> copying were the removal of some blank lines and page headers 
> and footers.
> 
> The reason for copying in the IOTP dsig DTD is to avoid 
> having to use namespaces in IOTP.
> 
> So really what I think we should do is:
> 1. Fix the DTD in the IOTP dsig spec (Yoshiaki ?) and then
> 2. Fix the DTD in the IOTP spec.
> 
> Regards
> 
> David
> 
> -----Original Message-----
> From: Masaaki Hiroya [mailto:[email-masked]]
> Sent: Thursday, October 14, 1999 3:33 AM
> To: David Burdett
> Cc: [email-masked]
> Subject: Bug in IOTP's DTD
> 
> 
> 
> David
> 
> There is a bug in ietf.org/draft-ietf-trade-iotp-v1.0-protocol-06.
> 
> >  <!ELEMENT Value ( #PCDATA ) >
> >  <!ATTLIST Value
> >          ID               ID           #IMPLIED
> >          encoding    (base64|none)    #IMPLIED      'base64'
> 
> 
> I think #IMPLIED in the "encoding" attribute should be removed.
> 
> Draft-ietf-trade-iotp-v1.0-dsig-03.txt defines the Value 
> element as follows:
> 
> >    <!ELEMENT Value ( #PCDATA ) >
> >    <!ATTLIST Value
> >            ID                 ID            #IMPLIED
> >            encoding      (base64|none)     'base64'
> 
> Please correct the DTD in iotp-v1.0-protocol-06.
> 
> Masaaki
> 
> -----
> Masaaki Hiroya
> Systems Development Laboratory
> Hitachi, Ltd.
> tel: +81-44-549-1531
> fax: +81-44-549-1640
> email: [email-masked]
> 
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: "Smith, Chris " <[email-masked]>
To: 'David Burdett' <[email-masked]>,  "[email-masked]'" <[email-masked]>
cc: "IETF Trade (E-mail)" <[email-masked]>,  "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>
Subject: RE: Bug in IOTP's DTD
Date: Fri, 15 Oct 1999 10:32:05 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF171A.071BC634
Content-Type: text/plain; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Interesting. The following is a rather subtle point, easily missed
when viewing the DTD (and NOT actually an error), but...

IOTP PackagedContent has

 <!ELEMENT PackagedContent (#PCDATA) >
 <!ATTLIST PackagedContent
  Name        CDATA            #IMPLIED
  Content     NMTOKEN          "PCDATA"
  Transform   (NONE|BASE64)    "NONE" >

while IOTP,DSIG has (corrected with removing the #IMPLIED)

 <!ELEMENT Value (#PCDATA) >
 <!ATTLIST Value
  ID          ID               #IMPLIED
  encoding    (base64|none)    'base64' >

Is there a specific reason that the attributes 
"encoding" and "Transform" don't agree on parameter
content and the default value of the parameter,
even though they are almost exactly the same
thing? Also, I can live with 'encoding' but this
is risking confusion with 'encoding' as it refers
to character sets like ISO-8859-1 (and as used on
the <?xml ...> XML declaration).

I realize that IOTP and DSIG are being worked on
independently, but could we have them be a little
less independent?

------------------------------------------------------------
 Chris Smith                                +1.416.348.6090
 Royal Bank                       [email-masked]

> -----Original Message-----
> From: David Burdett [mailto:[email-masked]]
> Sent: October 14, 1999 08:55 PM
> To: [email-masked]'
> Cc: IETF Trade (E-mail); [email-masked]';
> [email-masked]'
> Subject: RE: Bug in IOTP's DTD
> 
> 
> Masaaki
> 
> I accept that there is a mistake in the IOTP DTD, however 
> this part of the IOTP DTD was copied **directly** from the 
> the IOTP dsig spec at
> 
> 	
> http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0
> -dsig-03.txt
> 
> which contains the same error. The only changes made when 
> copying were the removal of some blank lines and page headers 
> and footers.
> 
> The reason for copying in the IOTP dsig DTD is to avoid 
> having to use namespaces in IOTP.
> 
> So really what I think we should do is:
> 1. Fix the DTD in the IOTP dsig spec (Yoshiaki ?) and then
> 2. Fix the DTD in the IOTP spec.
> 
> Regards
> 
> David
> 
> -----Original Message-----
> From: Masaaki Hiroya [mailto:[email-masked]]
> Sent: Thursday, October 14, 1999 3:33 AM
> To: David Burdett
> Cc: [email-masked]
> Subject: Bug in IOTP's DTD
> 
> 
> 
> David
> 
> There is a bug in ietf.org/draft-ietf-trade-iotp-v1.0-protocol-06.
> 
> >  <!ELEMENT Value ( #PCDATA ) >
> >  <!ATTLIST Value
> >          ID               ID           #IMPLIED
> >          encoding    (base64|none)    #IMPLIED      'base64'
> 
> 
> I think #IMPLIED in the "encoding" attribute should be removed.
> 
> Draft-ietf-trade-iotp-v1.0-dsig-03.txt defines the Value 
> element as follows:
> 
> >    <!ELEMENT Value ( #PCDATA ) >
> >    <!ATTLIST Value
> >            ID                 ID            #IMPLIED
> >            encoding      (base64|none)     'base64'
> 
> Please correct the DTD in iotp-v1.0-protocol-06.
> 
> Masaaki
> 
> -----
> Masaaki Hiroya
> Systems Development Laboratory
> Hitachi, Ltd.
> tel: +81-44-549-1531
> fax: +81-44-549-1640
> email: [email-masked]
> 

------_=_NextPart_001_01BF171A.071BC634
Content-Type: text/html; 
 charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: Bug in IOTP's DTD</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Interesting. The following is a rather subtle point, =
easily missed</FONT>
<BR><FONT SIZE=3D2>when viewing the DTD (and NOT actually an error), =
but...</FONT>
</P>

<P><FONT SIZE=3D2>IOTP PackagedContent has</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&lt;!ELEMENT PackagedContent (#PCDATA) =
&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&lt;!ATTLIST PackagedContent</FONT>
<BR><FONT SIZE=3D2>&nbsp; =
Name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CDATA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
#IMPLIED</FONT>
<BR><FONT SIZE=3D2>&nbsp; Content&nbsp;&nbsp;&nbsp;&nbsp; =
NMTOKEN&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;PCDATA&quot;</FONT>
<BR><FONT SIZE=3D2>&nbsp; Transform&nbsp;&nbsp; =
(NONE|BASE64)&nbsp;&nbsp;&nbsp; &quot;NONE&quot; &gt;</FONT>
</P>

<P><FONT SIZE=3D2>while IOTP,DSIG has (corrected with removing the =
#IMPLIED)</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&lt;!ELEMENT Value (#PCDATA) &gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&lt;!ATTLIST Value</FONT>
<BR><FONT SIZE=3D2>&nbsp; =
ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; #IMPLIED</FONT>
<BR><FONT SIZE=3D2>&nbsp; encoding&nbsp;&nbsp;&nbsp; =
(base64|none)&nbsp;&nbsp;&nbsp; 'base64' &gt;</FONT>
</P>

<P><FONT SIZE=3D2>Is there a specific reason that the attributes =
</FONT>
<BR><FONT SIZE=3D2>&quot;encoding&quot; and &quot;Transform&quot; don't =
agree on parameter</FONT>
<BR><FONT SIZE=3D2>content and the default value of the =
parameter,</FONT>
<BR><FONT SIZE=3D2>even though they are almost exactly the same</FONT>
<BR><FONT SIZE=3D2>thing? Also, I can live with 'encoding' but =
this</FONT>
<BR><FONT SIZE=3D2>is risking confusion with 'encoding' as it =
refers</FONT>
<BR><FONT SIZE=3D2>to character sets like ISO-8859-1 (and as used =
on</FONT>
<BR><FONT SIZE=3D2>the &lt;?xml ...&gt; XML declaration).</FONT>
</P>

<P><FONT SIZE=3D2>I realize that IOTP and DSIG are being worked =
on</FONT>
<BR><FONT SIZE=3D2>independently, but could we have them be a =
little</FONT>
<BR><FONT SIZE=3D2>less independent?</FONT>
</P>

<P><FONT =
SIZE=3D2>------------------------------------------------------------</F=
ONT>
<BR><FONT SIZE=3D2>&nbsp;Chris =
Smith&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +1.416.348.6090</FONT>
<BR><FONT SIZE=3D2>&nbsp;Royal =
Bank&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: David Burdett [<A =
HREF=3D"mailto:[email-masked]">mailto:david.burdett@comme=
rceone.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: October 14, 1999 08:55 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [email-masked]'</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: IETF Trade (E-mail); =
[email-masked]';</FONT>
<BR><FONT SIZE=3D2>&gt; [email-masked]'</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: Bug in IOTP's DTD</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Masaaki</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I accept that there is a mistake in the IOTP =
DTD, however </FONT>
<BR><FONT SIZE=3D2>&gt; this part of the IOTP DTD was copied =
**directly** from the </FONT>
<BR><FONT SIZE=3D2>&gt; the IOTP dsig spec at</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-trade-i=
otp-v1.0</A></FONT>
<BR><FONT SIZE=3D2>&gt; -dsig-03.txt</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; which contains the same error. The only changes =
made when </FONT>
<BR><FONT SIZE=3D2>&gt; copying were the removal of some blank lines =
and page headers </FONT>
<BR><FONT SIZE=3D2>&gt; and footers.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The reason for copying in the IOTP dsig DTD is =
to avoid </FONT>
<BR><FONT SIZE=3D2>&gt; having to use namespaces in IOTP.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; So really what I think we should do is:</FONT>
<BR><FONT SIZE=3D2>&gt; 1. Fix the DTD in the IOTP dsig spec (Yoshiaki =
?) and then</FONT>
<BR><FONT SIZE=3D2>&gt; 2. Fix the DTD in the IOTP spec.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; David</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Masaaki Hiroya [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, October 14, 1999 3:33 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: David Burdett</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Bug in IOTP's DTD</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; David</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; There is a bug in =
ietf.org/draft-ietf-trade-iotp-v1.0-protocol-06.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &lt;!ELEMENT Value ( #PCDATA ) =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &lt;!ATTLIST Value</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; =
ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
#IMPLIED</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
encoding&nbsp;&nbsp;&nbsp; (base64|none)&nbsp;&nbsp;&nbsp; =
#IMPLIED&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 'base64'</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I think #IMPLIED in the &quot;encoding&quot; =
attribute should be removed.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Draft-ietf-trade-iotp-v1.0-dsig-03.txt defines =
the Value </FONT>
<BR><FONT SIZE=3D2>&gt; element as follows:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; &lt;!ELEMENT Value ( =
#PCDATA ) &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; &lt;!ATTLIST =
Value</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; =
ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
#IMPLIED</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
encoding&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
(base64|none)&nbsp;&nbsp;&nbsp;&nbsp; 'base64'</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Please correct the DTD in =
iotp-v1.0-protocol-06.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Masaaki</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----</FONT>
<BR><FONT SIZE=3D2>&gt; Masaaki Hiroya</FONT>
<BR><FONT SIZE=3D2>&gt; Systems Development Laboratory</FONT>
<BR><FONT SIZE=3D2>&gt; Hitachi, Ltd.</FONT>
<BR><FONT SIZE=3D2>&gt; tel: +81-44-549-1531</FONT>
<BR><FONT SIZE=3D2>&gt; fax: +81-44-549-1640</FONT>
<BR><FONT SIZE=3D2>&gt; email: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF171A.071BC634--

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Cc: [email-masked], [email-masked],  [email-masked]
Cc: [email-masked]
Subject: RE: Bug in IOTP's DTD
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Fri, 15 Oct 1999 13:08:02 +0900 (JST)
Lines: 71
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David and Masaaki,
I am very sorry.
I will change ASAP.
Thanks,

>>>>> Thu, 14 Oct 1999 17:54:53 -0700,
	David Burdett <[email-masked]> said:

> Masaaki
> 
> I accept that there is a mistake in the IOTP DTD, however this part of the
> IOTP DTD was copied **directly** from the the IOTP dsig spec at
> 
> 	
> http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-dsig-03.txt
> 
> which contains the same error. The only changes made when copying were the
> removal of some blank lines and page headers and footers.
> 
> The reason for copying in the IOTP dsig DTD is to avoid having to use
> namespaces in IOTP.
> 
> So really what I think we should do is:
> 1. Fix the DTD in the IOTP dsig spec (Yoshiaki ?) and then
> 2. Fix the DTD in the IOTP spec.
> 
> Regards
> 
> David
> 
> -----Original Message-----
> From: Masaaki Hiroya [mailto:[email-masked]]
> Sent: Thursday, October 14, 1999 3:33 AM
> To: David Burdett
> Cc: [email-masked]
> Subject: Bug in IOTP's DTD
> 
> 
> 
> David
> 
> There is a bug in ietf.org/draft-ietf-trade-iotp-v1.0-protocol-06.
> 
> >  <!ELEMENT Value ( #PCDATA ) >
> >  <!ATTLIST Value
> >          ID               ID           #IMPLIED
> >          encoding    (base64|none)    #IMPLIED      'base64'
> 
> 
> I think #IMPLIED in the "encoding" attribute should be removed.
> 
> Draft-ietf-trade-iotp-v1.0-dsig-03.txt defines the Value element as follows:
> 
> >    <!ELEMENT Value ( #PCDATA ) >
> >    <!ATTLIST Value
> >            ID                 ID            #IMPLIED
> >            encoding      (base64|none)     'base64'
> 
> Please correct the DTD in iotp-v1.0-protocol-06.
> 
> Masaaki
> 
> -----
> Masaaki Hiroya
> Systems Development Laboratory
> Hitachi, Ltd.
> tel: +81-44-549-1531
> fax: +81-44-549-1640
> email: [email-masked]

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "IETF Trade (E-mail)" <[email-masked]>,  "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>
Subject: RE: Bug in IOTP's DTD
Date: Thu, 14 Oct 1999 17:54:53 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BF16A8.14D0F5BE
Content-Type: text/plain;
	charset="iso-8859-1"

Masaaki

I accept that there is a mistake in the IOTP DTD, however this part of the
IOTP DTD was copied **directly** from the the IOTP dsig spec at

http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-dsig-03.txt

which contains the same error. The only changes made when copying were the
removal of some blank lines and page headers and footers.

The reason for copying in the IOTP dsig DTD is to avoid having to use
namespaces in IOTP.

So really what I think we should do is:
1. Fix the DTD in the IOTP dsig spec (Yoshiaki ?) and then
2. Fix the DTD in the IOTP spec.

Regards

David

-----Original Message-----
From: Masaaki Hiroya [mailto:[email-masked]]
Sent: Thursday, October 14, 1999 3:33 AM
To: David Burdett
Cc: [email-masked]
Subject: Bug in IOTP's DTD

David

There is a bug in ietf.org/draft-ietf-trade-iotp-v1.0-protocol-06.

>  <!ELEMENT Value ( #PCDATA ) >
>  <!ATTLIST Value
>          ID               ID           #IMPLIED
>          encoding    (base64|none)    #IMPLIED      'base64'

I think #IMPLIED in the "encoding" attribute should be removed.

Draft-ietf-trade-iotp-v1.0-dsig-03.txt defines the Value element as follows:

>    <!ELEMENT Value ( #PCDATA ) >
>    <!ATTLIST Value
>            ID                 ID            #IMPLIED
>            encoding      (base64|none)     'base64'

Please correct the DTD in iotp-v1.0-protocol-06.

Masaaki

-----
Masaaki Hiroya
Systems Development Laboratory
Hitachi, Ltd.
tel: +81-44-549-1531
fax: +81-44-549-1640
email: [email-masked]

------_=_NextPart_000_01BF16A8.14D0F5BE
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

------_=_NextPart_000_01BF16A8.14D0F5BE--
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

Date: Wed, 13 Oct 1999 21:07:08 +0900
From: Ko Fujimura <[email-masked]>
To: [email-masked], [email-masked]
Subject: Digital-Right Definition Language Requirements
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

As I talked at the Oslo meeting, I believe that a digital-rights
management facility will satisfy wide-range of the business requirements
on the IOTP transactions. In the purchase transaction, for example, many
merchants want to issue loyalty points and/or redeem digital coupon 
for sales promotion. It also enables to provide flexible payment scheme,
e.g., pay per unit of time or pay in advance.

The below text is my first proposal for the Digital-Right Definition
Language Requirements. This is very early stage draft and any comments
are welcome. 

HTML Version see:
  http://info.isl.ntt.co.jp/flexticket/DRDL-requirements.html

Best regards,

Ko
-----------------------
Digital-Right Definition Language (DRDL) Requirements

Working Draft 1999-October-13

1. Introduction

This document presents the design principles, scope, and requirements of the 
Digital-Right Definition Language (DRDL), in which diverse types of rights can 
be described. Along with the Digital-Right Trading Protocol (DRTP), it enables 
companies or individuals to freely issue, transfer, and redeem various types of 
digital rights via the Internet using the specification-compliant Digital-Right 
Trading System (DRTS). This document includes the language-related requirements. 
Protocol-related requirements will be presented in a separate document. 
  
2. Definition of Digital-Right

A digital-right is a digital representation of the right to claim the services 
or goods described in itself. A formal definition of digital-right is as 
follows: 
  
            Let I be a digital-right issuer, O be a digital-right owner, P be 
            the issuer's promise to the digital-right owner, and V be the 
            validity that confirms whether it is valid. The digital-right is 
            defined as the 4-tuple of (I, P, O, V).

            Note: A digital-right is generally required to provide integrity and 
            non-repudiability and these requirements can be achieved by 
            implementing it as a digital certificate, i.e., Signed_I(I, P, O, V), 
            where the phrase "Signed_I" means that the entire block is 
            signed by the issuer's digital signature. A digital-right, however, 
            can be transferred or punched, and then O or V are changed, i.e., 
            the signature is broken. We, therefore, assume that the DRTS 
            provides a facility to manage owner and/or validity states for each 
            digital-right using an online validation checking system or tamper 
            resistant devices (for offline capability).
    
Examples of P are as follows: 
  - Two loyalty points are added to the card. If you collect 50 points, you'll 
    get one free. (Loyalty points) 
  - Take 10% off your total purchase by presenting this card. (Membership card) 
  - Take 50% off your total purchase with this coupon. (Coupon) 
  - The bearer can access "http://..." for one month free. (Free ticket for 
    sales promotion) 
  - The bearer can download 20 image files in the server "ftp://...". (Coupon 
    ticket) 
  - Seat number A-24 has been reserved for "a-concert" on April 2. (Event 
    ticket) 
    
A digital-right is delivered by the following three principal transactions: 
issue, transfer, and redemption: 

Issue 
    An issue transaction is the action in which the issuer (or deliverer) 
    assigns the ownership of a digital-right to the consumer. 

Transfer 
    A transfer transaction is the action in which the consumer (or deliverer) 
    transfers the ownership of the digital-right to another consumer. 

Redemption 
    A redemption transaction is an action in which the consumer redeems all or 
    part of the digital-right to a service provider (or merchant when the 
    digital-right is used as a payment method); depending on the redemption 
    transaction and the digital-right, the digital-right may be invalidated or 
    the number of times it remains valid for may be reduced. Other more complex 
    schemes may be supported. 

The issue, transfer, and redemption transaction can be done as a part of the 
IOTP purchase transaction. [Detail mapping to IOTP model will be studied and 
described.] 
  
3. Scope of the specification

This specification must describe the following items: 

  1. Objective of the specification. 

  2. How a digital-right is defined: 
     a. Structure of the definition. 
     b. Contents of the digital-right, in other word, what the digital-right 
        promises. 
        - Basic properties, which must be defined regardless of the 
          application, e.g., issue date or valid period. 
        - Application properties, e.g., seat number or flight number. They 
          differ with the type of the right, and are beyond the scope of this 
          specification. However, "how" such application-specific properties 
          are defined, is within the scope of the specification. 
     c. Control information which is necessary to control the issue, transfer, 
        and redeem transactions, e.g., whether transfer is allowed or who can 
        redeem the digital-right. 

  3. The basic concept and model. 
     a. A digital-right delivery model, necessary to understand the 
        specification, should be described, although the detail delivery 
        protocols are beyond scope of the specification. 
     b. Trust model. It describes how digital-right can be trusted. 
     c. Relation to other specifications, e.g., IOTP or xmldsig. 

  4. Formal Grammar (BNF and DTD). 

  5. Examples of the definition. 

4. Requirements

This section describes requirements on DRDL. Mandatory items are designated as 
"must," optional items are designated by "may." Items that are optional but 
recommended are designated as "should." 

4.1 Semantics

  1. Validity control: Depending on the type of the digital-right, the 
     invalidation (punching) method which executed when the digital-right is 
     redeemed is different. For example, a loyalty point will be invalidated if 
     the point is redeemed but a membership card can be used repeatedly 
     regardless of the number of times presented. The language must be able to 
     define how and when validity is modified. 

  2. Transferability control: Some types of digital-rights require 
     transferability. The language should be able to specify if a digital-right 
     can be transferred. 

  3. Anonymity control: Different types of digital-right will require different 
     levels of anonymity. The language should be able to control the required 
     level of anonymity. 

  4. Circulation control: Depending on the type of the digital-right, various 
     circulation requirements or restrictions must be satisfied while in 
     circulation, for example, only qualified shops can issue particular 
     digital-rights or only a certain service provider can punch (invalidate) 
     particular digital-rights. The language should be able to specify such 
     circulation requirements. 

  5. State manageability: Some types of digital-rights have properties the values 
     of which may be changed dynamically while in circulation, e.g., payment 
     status, reservation status, or approval status. The language may support the 
     definition of such properties. 
  6. Machine-understandability: The terms and description of a digital-right 
     should be objectively understood by the participants, because, this will 
     contribute to reducing the number of disputes on the interpretation of the 
     rights promised. 

  7. Composability: Some types of digital-rights consist of several sub-rights, 
     which may be issued separately from the original rights typically because 
     the digital-rights are issued by different organizations or issued at 
     different times. The language may support compound digital rights comprised 
     of multiple sub-rights. 

4.2 Syntax

  1. To achieve consistency with other related standards shown below, the syntax 
     of the language must be based on XML. 

  2. The language syntax must enable to define any application-specific 
     properties, e.g., seat number, flight number, etc. A schema definition 
     language that can be translated into application-specific DTDs may be 
     needed. 

4.3 Security

  1. The language should provide the parameters necessary to establish security. 
     This is true not only for digital signatures, but also for preventing 
     duplicate redemption; both of which are required for the digital rights 
     trading system. 
  2. If diverse types of digital-rights are put into circulation, it would be 
     difficult for users to judge whether a digital-right can be trusted or not. 
     The language may provide the parameters necessary to support such judgement. 
    
4.4 Efficiency

  1. The digital-rights may be stored in a smart card or PDA with a restricted 
     amount of memory. Large definitions may incur long transfer and processing 
     time, which may not be acceptable. The language must enable the efficient 
     definition of digital-rights. 

4.5 Coordination

  1. The language specification should be consistent with the following 
     specifications: 
     a. Internet Open Trading Protocol v1.0 [IOTP] 
     b. XML-Signature [xmldsig] 
     c. Extensible Markup Language (XML) Recommendation 
     d. ... [TBD] 

5. References

[TBD] 
o---------------------------------------------------------o
o      Ko Fujimura         Email: [email-masked]  o
o---------------------------------------------------------o
o NTT Information Sharing Platform Labs, Security Project o
o 1-1 Hikarinooka, Yokosuka-shi, Kanagawa 239-0847, JAPAN o
o Tel: +81-(0)468-59-3814         Fax: +81-(0)468-59-8329 o
o---------------------------------------------------------o

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: 'Masaaki Hiroya' <[email-masked]>
Cc: "IETF Trade (E-mail)" <[email-masked]>
Subject: RE: IOTP Inquiry Transaction
Date: Fri, 8 Oct 1999 09:17:10 -0700 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BF11A8.B8F67240
Content-Type: text/plain;
	charset="iso-8859-1"

Masaaki

You make some very good points !!

I agree with you that in the TransId Component:
a) the IotpTransType should contain "BaselineInquiry", and
b) the definition of what should be contained in the TransTimeStamp is
unclear.

I actually think that the TransTimeStamp should be the same s the time on
the original transaction. This means that to make an inquiry you would need
to know both the IotpTransID and the TransTimeStamp. This should make it a
lot harder for someone to "spoof" the inquiry especially if the original
transaction was carried out over a secure channel.

This means that section 9.2.1 of the specification is changed as follows ...

The paragraph that starts  with ...

"A Trading Role making an inquiry must use the identical Transaction Id
Component..."

... is replaced with ...

"A Trading Role making an inquiry must use a Transaction Id Component (see
section 3.3.1) where both the IotpTransId and TransTimeStamp attributes are
the same as in the Transaction Id Component of the original transaction that
is being inquired upon. The IotpTransId attribute in this component serves
as the key in querying the transaction logs maintained at the Trading Role's
site. The value of the ID attribute of the Message Id Component should be
different from those of any in the original transaction (see section
3.4.1)."

David
-----Original Message-----
From: Masaaki Hiroya [mailto:[email-masked]]
Sent: Monday, October 04, 1999 10:28 PM
To: David Burdett
Subject: IOTP Inquiry Transaction

David

In 9.2.1 of IOTP v1.0-06 (page 203) says as follows:

> TRANSACTION REFERENCE BLOCK
>
> A Trading Role making an inquiry must use the identical Transaction Id
> Component (see section 3.3.1) that was in the original transaction.
>

If the Transaction Id Component is identical to the one that was in the 
original transaction, the IOTP server cannot distinguish the transaction 
type.

I think the TransType should be different from the original one, and
it should be TransType="BaselineInquiry" because "BaselineInquiry" is
defined as a value of TransType in the TransId Component in the
IOTP specification.

I have another question regarding to the TransId Component for 
Baseline Inquiry Transaction.

Which time should be set to TransTimeStamp, the timestamp which the 
original transaction started at or the timestamp which the inquiry 
transaction started at?

The former one seems to be correct according to the definition, but
there is ambiguity in the word "IOTP Transaction" which is used in
the definition of "Timestamp" in the TransId Component (page 35).

What do you think?

Masaaki

-----
Masaaki Hiroya
Systems Development Laboratory
Hitachi, Ltd.
email: [email-masked]
tel: +81-44-549-1531
fax: +81-44-549-1640

------_=_NextPart_000_01BF11A8.B8F67240
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

------_=_NextPart_000_01BF11A8.B8F67240--
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  [email-masked]
Subject: RE: Server role processing sequence
Date: Fri, 8 Oct 1999 08:51:01 -0700 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Jordan

Apologies for the delay in responding but I have been very busy =
recently.
Anyway here goes ...

In the specification where it says, for example, "the Payment Request =
Block
refers to an IOTP Transaction", the phrase "refers to" is a bit too =
simple
what "refers to" should actually say "is contained in an IOTP Message =
where
the Trans Ref Block contains an IotpTransId that refers to". So that we =
get
...

"the Payment Request Block is contained in an IOTP Message where the =
Trans
Ref Block contains an IotpTransId that refers to an IOTP Transaction".=20

On your second point ...
	If an IOTP Transaction involves more than one payments the second
payment never will be processed at the Payment Handler ...

... you are correct. That bullet point should read ...

   - [*]if there was a previous payment that failed with a =
non-recoverable
     Completion Code then it is a Hard Error, otherwise

I'll update the specification on both these points.

David
-----Original Message-----
From: Jord=E1n L=E1szl=F3 [mailto:[email-masked]]
Sent: Thursday, September 30, 1999 2:44 AM
To: [email-masked]
Subject: Server role processing sequence

Here are some lines from the latest IETF draft:

4.5.2.4 Check for Errors in Block Sequence

 Errors in the sequence that blocks arrive depends on the block. Blocks
 where checking for sequence is required are:
...
 o Payment Request Block (Payment Handler only). Check as follows:
   - if the Payment Request Block refers to an IOTP Transaction that is
     not recognised then its OK, otherwise
   - if the Payment Request Block refers to IOTP Transaction that was =
not
     for a Payment then it is a Hard Error, otherwise
   - [*]if the previous payment CompletedOk OR failed with a =
non-recoverable
     Completion Code then it is a Hard Error, otherwise
   - if the previous payment is still in progress then it is a Hard =
Error
...

JL> I cannot understand, how can refer a Payment Request Block to an =
IOTP
Transaction. If this means that a Payment Request IOTP message has the =
same
IotpTransId as a previous message, then I have the following problem =
with
the third paragraph[*]: If an IOTP Transaction involves more than one
payments the second payment never will be processed at the Payment =
Handler.

Regards: Laszlo

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in =
the
body to: [email-masked]
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]