OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [ebxml-dev] ebMS MSH and routing

Close enough, we have a winner - Keith Babo.... The precise answer is, the
I05 refers to the element name used by X12 to identify the
Interchange ID Qualifier (reference page 1635 of ASC X12 Standard 4030).

Dick Brooks
Systrends, Inc
7855 South River Parkway, Suite 111
Tempe, Arizona 85284
Web: www.systrends.com <http://www.systrends.com>

-----Original Message-----
From: Keith Babo [mailto:keith.babo@sun.com]
Sent: Wednesday, January 09, 2002 3:19 PM
To: dick@tech-comm.com
Cc: William J. Kammerer; Anarkat, Dipan; ebXML Development
Subject: Re: [ebxml-dev] ebMS MSH and routing

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.


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>
>-----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
>    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
>'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 /
>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
>EDIRA (ISO6523), EDIFACT ISO 9735 or ANSI ASC X12 I05 registries. Can
>someone explain how this facilitates ebMS messaging ? A few examples
>actual codes for the above would be helpful .
><eb:PartyId eb:type="GLN">0614141000012</eb:PartyId>
><eb:PartyId eb:type="DUNS">0060189737810</eb:PartyId>
>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
>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
>       #email :    <eb:PartyId >mailto:somebody@mycompany.com
>Dipan Anarkat
>EC Systems Analyst
>Uniform Code Council, Inc.
>Tel: (609)-620-4509
>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>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC