[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [Fwd: RE: on the issue of PartyId]
David,
I disagree.
If we can indicate by type not being there to mean partyid is a URI, URI
advocates
should be happy. But why not let the application decide both values if the
attribute is there? Why impose that restriction?
Scott Hinkelman
Senior Software Engineer, IBM Austin
Emerging Technologies, SWG
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074
"Burdett, David" <david.burdett@commerceone.com> on 09/21/2000 07:35:14 PM
To: "'Henry Lowe'" <hlowe@omg.org>, ebxml transport
<ebxml-transport@lists.ebxml.org>
cc:
Subject: RE: [Fwd: RE: on the issue of PartyId]
I agree with Henry's interpretation below but disagree with David R's and
Chris's DTDs. What I would propose is the following ...
<!ELEMENT PartyId (#PCDATA)>
<!ATTLIST PartyId
type (UriReference|UserDefined) "UriReference">
... which means that:
1. If there is no "type" attribute or type is set to "UriReference" then
the
PartyId must contain a valid URI, otherwise it is an error, or
2. If type is set to "UserDefined" then no validation checks are imposed on
the content of PartyId by the ebXML spec and it is up to the recipient to
check and interpret what it contains, or
3. If type contains some other value, then it is in error (in fact its not
a
valid XML document!)
I think this is simple and supports flexibility, I don't think we need to
impose some type of registry.
David
PS Chris and I need something to argue about so I've used upper camel case
instead of lower for the values of type ... ;)
-----Original Message-----
From: Henry Lowe [mailto:hlowe@omg.org]
Sent: Thursday, September 21, 2000 2:40 PM
To: ebxml transport
Subject: Re: [Fwd: RE: on the issue of PartyId]
Scott,
Below:
At 03:53 PM 09/21/2000 -0500, Scott Hinkelman/Austin/IBM wrote:
>Chris,
>First, I'm ok with your DTD snip. (and yes Henry "type" could basically
>mean "context", but I'm ok with either one)
>
Whether it's "type" or "context" is no big deal. I believe the
current spec says "context". Just checking to see we're talking
about the same thing.
>Second, I agree that the value of "type", or the absence of it,
>needs to be agreed upon between Partys.
Isn't it the other way around? the absence of "type" means the
default which is URI, whereas, if "type" is present it means the
users have negotiated its use which means they and the transport
in use will understand it.
Best regards,
Henry
>
>I would prefer to keep the "where it must/may reside" (tpa, header,
>or on the moon) into a seperate issue.......
>
>Scott Hinkelman
>Senior Software Engineer, IBM Austin
>Emerging Technologies, SWG
>512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
>srh@us.ibm.com, Fax: 512-838-1074
>
>
>
>Chris Ferris <chris.ferris@east.sun.com>@bast.Corp.Sun.COM on 09/21/2000
>03:34:40 PM
>
>Sent by: cferris@bast.Corp.Sun.COM
>
>
>To: ebxml transport <ebxml-transport@lists.ebxml.org>
>cc:
>Subject: Re: [Fwd: RE: on the issue of PartyId]
>
>
>
>If we could agree that it must be agreed and specified
>in the TPA then I guess I'm cool. How 'bout:
>
><!ELEMENT PartyId (#PCDATA)>
><!ATTLIST PartyId type CDATA #FIXED 'uriReference'>
>
>Cheers,
>
>Chris
>
>Scott Hinkelman/Austin/IBM wrote:
>
>> I'm ok with David's "other hand" proposal. As long as we don't dictate
>what
>> it *must* be.
>>
>> Scott Hinkelman
>> Senior Software Engineer, IBM Austin
>> Emerging Technologies, SWG
>> 512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
>> srh@us.ibm.com, Fax: 512-838-1074
>>
>> "Burdett, David" <david.burdett@commerceone.com> on 09/21/2000 02:11:12
>PM
>>
>> To: "'Chris Ferris'" <chris.ferris@east.sun.com>, ebxml transport
>> <ebxml-transport@lists.ebxml.org>
>> cc:
>> Subject: RE: [Fwd: RE: on the issue of PartyId]
>>
>> Again
>>
>> I agree with Chris, using a URI, removes the problem from TRP of
defining
>> what can validly be present in a context, and allows us to use IANA
>> instead.
>>
>> So I still think we should go with URI as the prime mechanism.
>>
>> On the other hand if we really wanted to be flexible though we could
have
>> an
>> additional alternative of ...
>>
>> <PartyId type='userdefined'>123dwqf09u23rnsadp9</PartyId>
>>
>> where in the latter case, the recipient is expected to recognize the
>> PartyId
>> through a previously mutually agreed mechanism. In addition if type is
>not
>> present, then it defaults to 'URI'. This means you either have:
>> 1. a URI, or
>> 2. a coding scheme mutually agreed between the parties
>>
>> Thoughts?
>>
>> David
>>
>> -----Original Message-----
>> From: Chris Ferris [mailto:chris.ferris@east.sun.com]
>> Sent: Thursday, September 21, 2000 11:49 AM
>> To: ebxml transport
>> Subject: Re: [Fwd: RE: on the issue of PartyId]
>>
>> A URI provides its own context. This is what I am recommending, not that
>> any particular context shall be used or excluded (although I pointed out
>> that telephone # doesn't qualify as an URN which would seem to me
>> to be the form of URI which would be recommended).
>>
>> By that I mean that:
>>
>> <PartyId context="duns">1234567890123</PartyId>
>>
>> is the same as:
>>
>> <PartyId>urn:duns:1234567890123</PartyId>
>>
>> and that I would recommend that the latter form be used.
>> That was the jist of my proposal.
>>
>> Cheers,
>>
>> Chris
>>
>> Scott Hinkelman/Austin/IBM wrote:
>>
>> > I agree with Henry. I don't think we should dictate what it is, only
>> > dictate a way
>> > to dictate what it is.
>> >
>> > Scott Hinkelman
>> > Senior Software Engineer, IBM Austin
>> > Emerging Technologies, SWG
>> > 512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
>> > srh@us.ibm.com, Fax: 512-838-1074
>> >
>> > Henry Lowe <hlowe@omg.org> on 09/21/2000 01:37:49 PM
>> >
>> > To: "Brunner, Eric" <EBrunner@Engage.com>
>> > cc: "'Christopher Ferris'" <chris.ferris@east.sun.com>, ebxml
>transport
>> > <ebxml-transport@lists.ebxml.org>
>> > Subject: RE: [Fwd: RE: on the issue of PartyId]
>> >
>> > While being able to say that PartyID is a URI might nice,
>> > why is this necessary? Especially if we are trying to
>> > ensure that we can use all the different sorts of identifiers
>> > which have been mentioned in Chris' list (below, several
>> > messages down) plus telephone numbers?
>> >
>> > While it's not defined yet in the MS spec., the "context"
>> > will happily allow us to use any of these schemes as long as
>> > we define "context" appropriately.
>> >
>> > Best regards,
>> > Henry
>> > --------------------------------------------
>> > At 01:01 PM 09/21/2000 -0400, Brunner, Eric wrote:
>> > >I concure, and (wearing another hat) am part of the group(s) working
>on
>> > >making the e.164 numbering plan map to the dns, hence making
>"telephone
>> > >numbers" map to URIs.
>> > >
>> > >-----Original Message-----
>> > >From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
>> > >Sent: Thursday, September 21, 2000 10:36 AM
>> > >To: ebxml transport
>> > >Subject: [Fwd: RE: on the issue of PartyId]
>> > >
>> > >
>> > >nor this one...
>> > >
>> > >-------- Original Message --------
>> > >Subject: RE: on the issue of PartyId
>> > >Date: Wed, 20 Sep 2000 22:41:53 -0700
>> > >From: "Burdett, David" <david.burdett@commerceone.com>
>> > >To: Christopher Ferris <chris.ferris@east.sun.com>
>> > >
>> > >The bottom line (almost) of Chris' email said ...
>> > >
>> > >>>>Thus, I would propose that we adopt use of a URI as the value of
>the
>> > >PartyId element.<<<
>> > >
>> > >I agree for the reasons Chris gave. The only caveat I would have is
>> that,
>> > in
>> > >the EDI world, Telephone numbers *are* used to uniquely identify a
>> > business.
>> > >I therefore think we also need to support this format.
>> > >
>> > >Chris is right that telephone numbers can be re-allocated to new
>> > >individuals/businesses and therefore do not strictly meet the
>> requirement
>> > >for a URN on their own. However a telephone number **at a point in
>> time**
>> > is
>> > >unique. Open to alternative suggestions but what might work is to
>define
>> > >PartyId with a default type of URI, but allow an alternative of a
>> > telephone
>> > >number with a recommendation that the value be considered in
>conjunction
>> > >with the date/time that the message was created in order to assure
>> > >consistent results. In practice though, the probability of a clash is
>> low.
>> > >
>> > >David
>> > >
>> > >
>> > >
>> > >-----Original Message-----
>> > >From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
>> > >Sent: Thursday, September 14, 2000 7:57 PM
>> > >To: ebxml transport
>> > >Subject: on the issue of PartyId
>> > >
>> > >
>> > >I scrounged the archives and came up with the following postings on
>the
>> > >topic:
>> > >
>> > >http://lists.ebxml.org/archives/ebxml-transport/200008/msg00073.html
>> > >http://lists.ebxml.org/archives/ebxml-transport/200008/msg00079.html
>> > >http://lists.ebxml.org/archives/ebxml-transport/200008/msg00084.html
>> > >http://lists.ebxml.org/archives/ebxml-transport/200008/msg00093.html
>> > >http://lists.ebxml.org/archives/ebxml-transport/200008/msg00095.html
>> > >http://lists.ebxml.org/archives/ebxml-transport/200008/msg00082.html
>> > >http://lists.ebxml.org/archives/ebxml-transport/200008/msg00098.html
>> > >http://lists.ebxml.org/archives/ebxml-transport/200008/msg00107.html
>> > >http://lists.ebxml.org/archives/ebxml-transport/200008/msg00097.html
>> > >http://lists.ebxml.org/archives/ebxml-transport/200008/msg00111.html
>> > >
>> > >I feel that these postings capture fairly well the discussion on
>> > >PartyId. I have omitted the zillion related postings on whether
>> > >to regrep or not to regrep on a message send/receipt as irrelevant
>> > >to the discussion.
>> > >
>> > >Dick's posting made a noble attempt to articulate the various
>> > >points:
>> > http://lists.ebxml.org/archives/ebxml-transport/200008/msg00098.html
>> > >
>> > >Dick wrote:
>> > >
>>
-------------------------------------------------------------------------
>> > >One requirement:
>> > >
>> > >Any two trading partners should be permitted to use non-standard
>values
>> > for
>> > >context and authority. The specs must provide an extension mechanism
>to
>> > >allow
>> > >this type of customization. For example MIME permits header
>extensions
>> > >through
>> > >the X-hhhhhhh option, X12 has the "ZZ" qualifier, etc. Consider a
>> possible
>> > >example, using Amazon:
>> > >
>> > ><PartyId context="X-Amazon" authority="userid">RJB9876</PartyId>
>> > >
>> > >This, I believe, would address David B's concern over having parties
>> > >pre-register with recognized "Name space management organizations".
>> > >
>>
-------------------------------------------------------------------------
>> > >
>> > >David Burdett's proposal:
>> > >http://lists.ebxml.org/archives/ebxml-transport/200008/msg00082.html
>> > >rings true with what I had been advocating (use of URI syntax and NO
>> > context
>> > >attribute
>> > >since the URI provides its own context. I could conceive of use of an
>> > >attribute
>> > >which allowed typing ala BizTalk (which uses xsd:type to declare the
>> type
>> > of
>> > >the
>> > >value, but not necessarily the namespace) as this might be seen as
>> useful
>> > in
>> > >parsing the value and would permit non-URI syntax to be used as the
>> > PartyId
>> > >value.
>> > >
>> > >I think that it is important that we understand (and agree upon) how
>> this
>> > >header element will be used within the MessagingService (let us leave
>> the
>> > >Application(Support) layer aside for the moment).
>> > >
>> > > - routing: an MS might simply be serving as a "mailbox" server
>> (as
>> > >many of the
>> > > existing implementations handle the initial receipt of a
>message)
>> > in
>> > >which
>> > > case the "From" might be the "mailbox" identifier
>> > >(mailto:companyX.com)
>> > > into which the MS should place the message received. It isn't
>> > >important
>> > > that the MS "know" *who* companyX.com *is* (e.g. no reg/rep
>> lookup
>> > >need be
>> > > involved). The MS might resolve the "From" id to an address
>> > >(mailbox, queue
>> > > whatever) but all that is needed here is a mapping between the
>> key
>> > >(PartyId)
>> > > and some value (mailbox address).
>> > >
>> > > - logging: an MS might be required to log all messages
>processed,
>> > in
>> > >which
>> > > case having the "To" and "From" logged (without having to look
>> > >anything else
>> > > up in say a reg/rep or in a TPA store) along with other
>> interesting
>> > >bits
>> > > which might be found in the headers would be useful. Again, it
>is
>> > >probably
>> > > not important that the log contain the formal company name
>> > (resolved
>> > >from
>> > > the logical id) in the log file. This could be processed after
>> the
>> > >fact
>> > > if it was important that this information be known to someone
>> > >"reading" the
>> > > log much the same as most web sites merely log the IP address
>and
>> > >not the
>> > > DNS resolved hostname.domainname (which is expensive and makes
>> the
>> > >site
>> > > less performant) because this can be resolved later when (and
>IF)
>> > >the
>> > > log entry needs to be analyzed.
>> > >
>> > > - delivery: if we accept David's scenario (and no, I am not;-)
>of
>> a
>> > > TPA-less exchange, then the "To" might be used to map to some
>> > >physical
>> > > address using some manner of I2L (URI to URL) resolution
>(THTTP?
>> > >DNS?). In fact,
>> > > if the "logical" address were a URL (which is a URI) then no
>> lookup
>> > >would
>> > > be required at all. Again, from the MS perspective, it is NOT
>> > >important
>> > > that it "know" *who* the entity/party is. The implementation
>> would
>> > >merely
>> > > have a responsibility to know how to perform the I2L
>resolution.
>> If
>> > >the
>> > > "key" (I) were unique (as is the case of any URI) then there
is
>> no
>> > >need
>> > > to agree to which code set is used, just that it be unique so
>as
>> to
>> > > enable the resolution service to map the URI to a URL. A
simple
>> > >hashtable
>> > > of key/value pairs could easily accomodate the mapping.
>> > >
>> > > in the case where a TPA *is* present, then the "To" might be
>used
>> > to
>> > >
>> > > resolve the communication protocol specifics within the TPA
>> itself
>> > >(map the
>> > > PartyId of the Header to the PartyId of the TPA or to some
>other
>> > >Party
>> > > identifier (possibly, the TPA should have something akin to
>what
>> > >UDDI
>> > > has to associate a number of different identifiers with a
>> > >BusinessEntity)
>> > > ...) Heck, the PartyId in the Header could be the *same* value
>as
>> > >the
>> > > PartyId in the TPA;-) e.g. tpa:partyid:12345.
>> > >
>> > > - security: again, in the absense of a TPA, one might conceive
>of
>> > > use of the "From" PartyId used by the MS as a key to a
>> credentials
>> > >registry which
>> > > could contain the certificate (or passwd) which the receiving
>> party
>> > >uses
>> > > to validate the signature (or passwd) with which the message
>was
>> > >signed.
>> > > Of course, this information would be in the TPA (one would
>> expect)
>> > >in which
>> > > case the "From" might be used within the context of the TPA to
>> find
>> > > the certificate/credentials.
>> > >
>> > >There may be other uses, but I for one cannot think of them (it's
>late;
>> -)
>> > >
>> > >The bottom line is that the identifier must be unique within *some*
>> > >namespace
>> > >so that the MS can resolve it (somehow) to something useful in the MS
>> > >processing
>> > >context. It is not necessary (based upon the use cases above) that
the
>> > *who*
>> > >be resolved from the registry which allocated the id (ISO whatever)
>> > >
>> > >Thus, I would propose that we adopt use of a URI as the value of the
>> > >PartyId element.
>> > >
>> > ><element ref="PartyId" type="uriReference"/>
>> > >
>> > >with examples such as those (except the urn:tel: example which is to
>my
>> > >understanding an invalid URN because it is not persistent) identified
>> > >in David's email.
>> > >
>> > >I do NOT believe that we need to specify a set of
>> > >code sets other than possibly as examples (NON-NORMATIVE) as to how
>> > >PartyId may be (should be?) used. That (I believe) should be left
>> > >to the parties to agree to (can you say TPA? I knew you could;-).
>> > >
>> > >Comments?
>> > >
>> > >Chris
>> > >
>> > >
>> > >
>> > >--
>> > > _/_/_/_/ _/ _/ _/ _/ Christopher Ferris - Enterprise
>Architect
>> > > _/ _/ _/ _/_/ _/ Phone: 781-442-3063 or x23063
>> > > _/_/_/_/ _/ _/ _/ _/ _/ Email: chris.ferris@East.Sun.COM
>> > > _/ _/ _/ _/ _/_/ Sun Microsystems, Mailstop:
UBUR03-313
>> > >_/_/_/_/ _/_/_/ _/ _/ 1 Network Drive Burlington, MA
>01803-0903
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC