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

[David Burdett <[e-mail]>]

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:[e-mail]]
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 ([e-mail]), Project Manager 
MeTechnology Ltd. Hungary - a Brokat Company
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

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