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

["Donald E. Eastlake 3rd" <[e-mail]>]

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

>Hello David,
>
>> ====================================================================
>> 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?##
>RH> That's the best solution...  I agree 100%.
>
>> ====================================================================
>> 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> Ok I agree, but even the TransID component could contain sensitive
>RH> information. For example to authorise and inquiry transaction.
>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> 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.##
>This solution is OK.
>
>> ====================================================================
>> 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 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...

I tend to favor allowing optional IDs...

>> ...
>> 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?##
>RH> I think copying the DTD is ok. I wouldn't introduce namespaces
>RH> if it could be avoided...

Agree.

Donald

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