Subject: RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt Part 2

From: David Burdett <[email-masked]>
Date: Fri, 3 Sep 1999 09:25:01 -0700

Rudolf

Thanks for your comments I've responded below marked with ##. Some of your
comments could benefit from more discussion.

I really appreciate you reporting these errors. They are helping to polish
the spec.

David

-----Original Message-----
From: Rudolf Hornig [mailto:[email-masked]]
Sent: Thursday, September 02, 1999 8:11 AM
To: IOTP Trade List (E-mail)
Subject: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt Part 2

Again some additional comments on IOTP draft,

====================================================================
7.4 Trading Role Information Request Component

 <!ELEMENT TradingRoleInfoReq EMPTY>
 <!ATTLIST TradingRoleInfoReq
  ID                 ID      #REQUIRED
  TradingRoleList    NMTOKENS #REQUIRED >
                     ^^^^^^^^       
RH> Please correct the separate DTD file according to this
RH> definition.
##Fixed in DTD##
====================================================================
7.6.1.1 Organisation IDs
RH> ComsumerOrgId is case sensitive however NonConsumerOrgId is
RH> case insensitive. This may cause confusion... and in this 
RH> case the third example should be:
RH> "Consumer:1000247ABH/newjerseybooks.com"
RH> starting with a capital letter...
##Propose making ConsumerOrgId case insensitive. Do you agree?##
====================================================================
7.6.2 Trading Role Element
RH> CancelNetLocn and ErrorNetLocn are IMPLIED according
RH> to the separate DTD file.
## Fixed in spec##
...
RH> ErrorLogNetLocn is mandatory for non consumer roles.
RH> Because there are no mechanisms defined for authenication
RH> on this channel and it is not secured, this type
RH> of logging may introduce security holes. (maybe the
RH> error component, the Consumer is sending, contains also
RH> some previous XML message, which contains sensitive information)
## There shouldn't be a security hole of this type since the content of
earlier messages is never included when reporting an error. At most you
might include just the element or attribute value that was in error.##
RH> Because all the error components should be sent back to the
RH> counterparty, I would suggest to let the server roles implement
RH> their own logging facility. Or I would make the ErrorLogNetLocn
RH> optional... Hints on this ???
##Disagree. When we discussed this we thought it would be simpler to always
include it and leave it to each implementation to decide what they do with
error messages when they receive them. They could just ignore them.##
====================================================================
RH> About DTD in general:
RH> PackagedContent, ContactInfo, PersonName, PostalAddress,
RH> ProtocolBrand, DeliveryData, ErrorLocation, Manifest,
RH> Digest, Attribute, OriginatorInfo, RecipientInfo,
RH> Parameter, IssuerAndSerialNumber and Locator Elements
RH> doesn't have ID attribute. As even for IOTP extensions
RH> it is a requirement to have ID attribute, it would be nice
RH> to have also on all element in IOTP DTD.
## I don't have a really stron view on this. Putting in ID's could make
error reporting simpler since you can specifically identify the instance of
an element that was on error. On the other hand this is a fairly major
change at this stage and I'm not sure it would be worth it. What do others
thing?##
...
RH> The digital signature part is not consistent regarding
RH> capitalisation in attribuite naming.
## This is because its following the conventions in the IOTP dsig spec. One
thought going through my mind is whether or not to include (by copying) the
dsig DTD into the IOTP DTD. You could just leave it separate and use
namespaces to identify which each belonged to. But then do we want to
introduce the requirement that namespaces are used at this late stage when
you don't really need them. Thoughts everyone?##
====================================================================
7.9 Payment Component
RH> As it contains element references, I would suggest to change
RH> from StartAfter to StartAfterRefs just to be consistent
RH> in naming...
##Changed##
====================================================================
7.13.1 Delivery Data Element
...
 <!ATTLIST DeliveryData
  xml:lang           NMTOKEN #IMPLIED
  OkFrom             CDATA   #REQUIRED
  OkTo               CDATA   #REQUIRED
  DelivMethod        NMTOKEN #REQUIRED
  DelivToRef         NMTOKEN #REQUIRED
  DelivReqNetLocn    CDATA   #REQUIRED
  SecDelivReqNetLocn CDATA   #REQUIRED
  ContentSoftwareId  CDATA   #IMPLIED >
RH> DelivReqNetLocn and SecDelivReqNetLocn should be IMPLIED as
RH> only one of them is mandatory
##Absolutely correct! Change made.##

Thanks again for your comments !
Rudi
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rudolf Hornig ([email-masked]), Project Manager 
MeTechnology Ltd. Hungary - a Brokat Company
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

-----------------------------------------------------------------------
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]

---

From: Rudolf Hornig <[email-masked]>
Date: Mon, 6 Sep 1999 10:50:59 +0200

Hello David,

RH> That's the best solution...  I agree 100%.

RH> Ok I agree, but even the TransID component could contain sensitive
RH> information. For example to authorise and inquiry transaction.
RH> (IotpTransId and TransTimeStamp)

> error messages when they receive them. They could just ignore them.##
This solution is OK.

RH> The idea behind my suggestion was to have some common way to
RH> identify an element/component/block etc. which could be used
RH> the same way during error reporting, signing the elements and
RH> would make, for example an IOTP Message Parser/Generator's 
RH> implementation much more clear. In this case we could have
RH> a common way to identify all elements in an IotpMessage.
RH> On the other hand I 100% agree with you not to diturb the
RH> draft if it doesn't worth...

> you don't really need them. Thoughts everyone?##
RH> I think copying the DTD is ok. I wouldn't introduce namespaces
RH> if it could be avoided...

Rudi

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Tue, 07 Sep 1999 07:53:43 -0400

From:  Rudolf Hornig <[email-masked]>
To:  "'David Burdett'" <[email-masked]>,
            "'IOTP Trade List (E-mail)'" <[email-masked]>
Date:  Mon, 6 Sep 1999 10:50:59 +0200
Message-ID:  <000001bef844$f1ba1000$0a00000a@rudolf>
In-Reply-To:  <123B7EB05559D311B0D900A0C9EA3D7604F206@NEPTUNE>

>RH> (IotpTransId and TransTimeStamp)

Suggest including a comment about this where ErrorNetLogLocn is
defined or in the Security Considerations section.  The
ErrorNetLogLocn can be an "https:" URL for more security.

>RH> draft if it doesn't worth...

I tend to favor allowing optional IDs...

>RH> if it could be avoided...

Agree.

Donald