RE: [ebxml-dev] ebMS MSH and routing

["Anarkat, Dipan" <DAnarkat@uc-council.org>]

William,

	The OID scheme for party-id is really very neat and clean and makes
absolute sense while we have so many  commonly used  identifier schemes. 
	Until the time such a system is adopted into ebMS, what will be the
working system and how will it facilitate efficient routing? Any idea
towards what party-id schemes the MSH software vendors would be building
their products to ?

Dipan Anarkat
EC Systems Analyst
Uniform Code Council, Inc.
Tel: (609)-620-4509
http://www.uc-council.org/


-----Original Message-----
From: William J. Kammerer [mailto:wkammerer@novannet.com]
Sent: Wednesday, January 09, 2002 2: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/