Re: [Issues-TRP]

[Himagiri Mukkamala <himagiri@sybase.com>]

I'd agree with  chris that we should'nt go against
the spec and whoever is using Apache SOAP 2.1 for
implementing TRP handle it in their implementation.

This is not an issue for vendors implementing TRP
without using Apache/SOAP and is more of an implementation
issue than specification issue.

-himagiri

christopher ferris wrote:

> Himagiri Mukkamala wrote:
> >
> > THe first three issues are related to earlier email about
> > SOAP/Apache by Sakata Yuji
> >
> > 1) Always have a manifest element - This is cause Apache
> > does the  invoke based on the first child of the SOAP
> > body element and sometimes messages may not have a manifest
> > element. Hence all ebXML messages should have a Manifest element.
>
> This would be counter to the spec. Just because the Apache SOAP2.1 processor
> doesn't handle Header entries correctly seems a poor excuse to
> violate the spec. There are few cases I can think of when there
> isn't something from the TR&P namespace in the Body element.
>
> >
> > 2) Stick to "eb" as the namespace prefix for all ebXML elements.
>
> This should make no difference what-so-ever unless there are
> some using non-namespace aware XML parsers.
>
> >
> > 3) There will be an empty payload mime body part for messages
> > without payload. This is cause apaches' implementation does'nt
> > write messages as multipart/related if there are no multiple body parts.
>
> Seems reasonable. I would suggest a consistent mime type for the
> null payload.
>
> >
> > 4) PartyID: The example around the the element definition in
> > the TRP spec shows as type"urn:duns.com" and the actual value
> > as the TEXT_NODE. But in the example at the end of spec, it's shown
> > as TEXT_NODE with value "urn:duns:111111" with no
> > type attribute. This needs to be clarified.
>
> There is no formal URN scheme for DUNS numbers (as has been hashed
> to death on the TR&P list). I would recommend that you just pick
> something and go with it for purposes of the POC.
>
> >
> > 5) Agree on where the DUNS number comes from. Use some
> > arbitrarily assigned numbers ?
>
> You could make them up, or each vendor could use their
> own (assuming they all have one). You can look it up if you
> don't know it off hand.
>         https://www.dnb.com/product/eupdate/update.htm
>
> >
> > 6) There are some issues with IBMs' implementation of XMLDSIG
> > which ralph pointed out. This needs to resolved by this week or
> > else XMLDSIG may not be used.
>
> Agreed, we need to get this resolved.
>
> >
> > 7) Where Schema and DTD exist, use schema as the standard.
>
> Agreed.
>
> >
> > 8) Use specification as the source of information, if there is a
> > discrepancy between the spec and the sample. But need to
> > convey that to the working group.
>
> Agreed, and the sooner the better;-)
>
> >
> > 9) All the business level conversations will be asynchronous as
> > the demo has user interaction.
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-poc-request@lists.ebxml.org
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-poc-request@lists.ebxml.org