Re: [ebxml-dev] ebMS MSH and routing

[Keith Babo <keith.babo@sun.com>]

I'm going to go out on a limb and assume that you are referring to the 
the fifth element of the ANSI X12 interchange envelope (ISA). A 
qualifier of '01' indicates that it is a DUNS number.

cheers,
keith

Dick Brooks wrote:

>William makes an excellent point. I discovered this "hole" when I was
>writing the ebXML mapping for the Open Travel Alliance E-Commerce spec. I
>ended up "creating" a URN to use within the type attribute of PartyId.
>Here's an example of an OTA compliant PartyId element, anyone want to guess
>what the urn contained in the type attribute indicates?
>
><eb:PartyId eb:type="urn:x12.org:I05:01">987654321</eb:PartyId>
>
>
>Dick Brooks
>Systrends, Inc
>7855 South River Parkway, Suite 111
>Tempe, Arizona 85284
>Web: www.systrends.com <http://www.systrends.com>
>Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714
>
>
>-----Original Message-----
>From: William J. Kammerer [mailto:wkammerer@novannet.com]
>Sent: Wednesday, January 09, 2002 1:52 PM
>To: Anarkat, Dipan
>Cc: ebXML Development
>Subject: Re: [ebxml-dev] ebMS MSH and routing
>
>
>Dale Moberg agreed with Duane Nickull on the
>ebxml-cppa@lists.oasis-open.org mailing list that it would be good if we
>had an enumerated list [of PartyId types], with option to extend it. It
>would be good if these list values were at least standardized to URIs,
>probably URNs. But last time [Dale] checked, there was little agreement
>even on how to get an official URN for DUNS or whether it might need to
>get some official (read legal) approval to use it.
>
>Dale asked if there are "some candidate values that could help
>standardization in this area? ....what [could we] use as enumerated
>values?" He wants a list of all commonly used identifier schemes. Dale
>further suggested "we might then use an oasis urn prefix to rig up
>enumerated values."
>
>All URN prefixes or domains are defined at
>http://www.iana.org/assignments/urn-namespaces.  Dun & Bradstreet still
>hasn't requested one since we first discussed this a year ago, and I
>wouldn't hold my breath waiting for this to happen at all.
>
>In the meantime, I would be quite satisfied using the OID (Object
>Identifier) scheme to indicate PartyId types.  "urn:oid:1.3.60" uniquely
>says Dun & Bradstreet D-U-N-S.  Use "urn:oid:1.3.60" to qualify the code
>081466849, and you instantly know I'm talking about the Microsoft
>Corporation.  As another example using the OID URN, an EAN Location Code
>would be qualified it with a PartyId type of
>"urn:oid:1.3.88".   The OID structure itself is cataloged at
>http://www.alvestrand.no/objectid.  I addressed this use of OIDs (for
>the PartyId type) in detail within a thread of messages to the ebXML
>Transport mailing list back in December 2000 and subsequent months.
>
>Our good friends, Ralph Berwanger, David Dobbing, Klaus-Dieter Naujok
>and Francois Vuilleumier are members of ISO/TC 154-UN/CEFACT JSWG, at
>http://www.gefeg.com/jswg/.  They might be able to lubricate the way for
>ISO 9735 to define an OID structure whereby all of EDIFACT's D.E. 0007
>Identification code qualifier code values could be hijacked for use.
>All ISO standards that have a number have an automatic assignment of an
>OID under the arc 1.0.
>
>So ISO 9735 (EDIFACT Syntax) already owns urn:oid:1.0.9735.  It would be
>up to the JSWG, I guess, to decide how they would parcel out their
>little domain.  For example, if they said the OID 1.0.9735.1.n referred
>to the code values for service element n, then a PartyId type of
>urn:oid:1.0.9735.1.7.8 could mean "UCC Communications ID (Uniform Code
>Council Communications Identifier)." - in that D.E. 0007 is the service
>element and code value 8 means UCC CommID.  The latest list of EDIFACT
>Identification code qualifiers is at
>http://www.gefeg.com/jswg/cl/v4/40006/cl3.htm.  This would give you full
>access to all the EDIFACT qualifiers, relying on diligent and
>conscientious maintenance to be provided free of charge by the JSWG.
>
>Likewise, using the OID arc 1.3 allows you to refer to all the ISO 6523
>ICDs; see file ICD_list.htm in folder
>6523-Identification-of-Organizations at
>http://xw2k.sdct.itl.nist.gov/l8/document-library/draft-standards/ for a
>list as of 5 April 2000.  So, as in the examples I gave before, a
>PartyId type of "urn:oid:1.3.88" refers to ISO 6523 ICD 0088 (EAN
>Location Code).
>
>The only thing left to do would be to get an arc assigned to X12's
>Interchange ID Qualifier so you have full access to their comprehensive
>list of qualifier types.
>
>William J. Kammerer
>Novannet, LLC.
>+1 (614) 487-0320
>
>----- Original Message -----
>From: "Anarkat, Dipan" <DAnarkat@uc-council.org>
>To: "Ebxml-Dev (E-mail)" <ebxml-dev@lists.ebxml.org>
>Sent: Wednesday, 09 January, 2002 02:21 PM
>Subject: [ebxml-dev] ebMS MSH and routing
>
>
>Hi,
>    I am trying to uderstand how the
>
>#1.     eb:MessageHeader/eb:PartyId
>#2.     eb:MessageHeader/eb:PartyId/@eb:type
>
>entities are used in the routing process for an ebMS message .
>
>The specification says that the value of #2 has to be agreed upon b/w
>the
>'ToParty' and the 'FromParty'.
>How does this ensure message delivery in a multi-hop scenario with
>intermediaries ?
>
>Drawing an analogy with the IP addressing and routing scheme :
># should'nt there be a standard for the value contained in #2 so
>that the message can be interpreted and routed to the appropriate MSH /
>SOAP
>node ?
># can an ebMS MSH node be mapped to multiple 'PartyId' 's , similiar
>to an multi-homed IP node with multiple IP addresses ?
># shouldnt there be a naming / registry system like DNS for mapping
>'PartyId' 's  to MSH nodes ?
># how does an MSH node know the physical location ( IP address ) of
>the next MSH ?
>
>The spec recommends  that the the value of #2 be standard codes taken
>from
>EDIRA (ISO6523), EDIFACT ISO 9735 or ANSI ASC X12 I05 registries. Can
>someone explain how this facilitates ebMS messaging ? A few examples
>with
>actual codes for the above would be helpful .
>
>
>
><eb:MessageHeader>
><eb:To>
><eb:PartyId eb:type="GLN">0614141000012</eb:PartyId>
></eb:To>
><eb:From>
><eb:PartyId eb:type="DUNS">0060189737810</eb:PartyId>
></eb:From>
></eb:MessageHeader>
>
>Considering the example above in an multi-hop scenario,
># how are the values contained in #1 and #2 used by the 'ToParty'
>and intermediary MSH nodes actually used for routing ?
># how does an intermediary MSH node select the next MSH node and
>consequently its physical (IP) location based on #1 and #2 ?
># Couldnt there be a situation that an intermediary MSH may not
>understand the value contained in #2 as #2 is not constrained by the
>specification ?How does the routing work then ?
>
>The specification also specifies that if #2 is not used , then the
>content
>of #1 should ne a URI. In that case how does routing take place if the
>content of #1 is say :
>       #URL :    <eb:PartyId >http://www.mycompany.com/service/Order
></eb:PartyId>
>       #email :    <eb:PartyId >mailto:somebody@mycompany.com
></eb:PartyId>
>
>Thanks
>
>Dipan Anarkat
>EC Systems Analyst
>Uniform Code Council, Inc.
>Tel: (609)-620-4509
>http://www.uc-council.org/
>
>
>
>----------------------------------------------------------------
>The ebxml-dev list is sponsored by OASIS.
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.ebxml.org/ob/adm.pl>
>
>
>----------------------------------------------------------------
>The ebxml-dev list is sponsored by OASIS.
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.ebxml.org/ob/adm.pl>
>