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

[Rudolf Hornig <[e-mail]>]

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)

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

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

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]