Re: Comments and Suggestions - 0.9a

[Scott Hinkelman <srh@us.ibm.com>]

->Concerning the value of an Identifier, I am on the side of *specing a URI
as the default* but
allowing other values as seen fit. Chris and others may view this as too
loosy-goosy but
my view is that identification within some context or governing authority
is going on already
and we should allow using those values/context. There just is not a need
all of time to
provide guidance as to how uniqueness is achieved -it is already being done
within
context of specific businesses areas that are well established.

I agree with David Burdett's Summary as indicated:

http://lists.ebxml.org/archives/ebxml-transport/200012/msg00206.html


->On the point of Registry CPA / bootstrap; I seems likely to me that an
ebXML Registry would
be view UDDI as a fine place to advertise its CPP. From this perspective, I
pretty much view
an ebXML Registry as any other service.

Thanks,
Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



Christopher Ferris <chris.ferris@east.sun.com> on 01/10/2001 08:25:30 PM

To:   Michael Joya <mike.joya@xmlglobal.com>
cc:   ebxml-transport@lists.ebxml.org, Farrukh Najmi
      <Farrukh.Najmi@east.sun.com>
Subject:  Re: Comments and Suggestions - 0.9a



Michael,

Thanks for taking the time to review the spec!
Please see my comments/responses below. Your comments will be
formally addressed and tracked separately. My comments are
my own personal views, not necessarily those of the team;-)

Cheers,

Chris

Michael Joya wrote:
>
> lines 496-499:
>     CPAId element: What values go in this element during an anonymous
> query? Before you obtain CPA or CPPs from a registry, you have to be
> able to query the registry. To query the registry, you need a CPAId.
> This circular dependency infers predetermined knowledge before online
> contact. Anonymous messages are the starting point of an important
> bootstrap/discovery process and should be addressed.

I'm not convinced that there is a circular dependency. Nowhere, is it
stated that the only way that a CPP may be accessed is via ebXML MS.
To bootstrap, a registry could advertise it's CPP via any number
of perfectly valid means, such as:
     UDDI registry
     HTTP URL
     sent around in a "start-up" CDROM
     whatever...

As to the value of the CPAId, we've been discussing this during our
face2face meetings, but have yet to come to a consensus opinion. It is
our objective to do so before we conclude our meetings and reflect this
in the resultant draft of the spec.

It isn't clear to me that there needs to be a definitive scheme for
the value of CPAId. I have always felt that one scheme would be the
UUID (or preferebly, an URI) of the CPA as registered in the ebXML RegRep.
I've been a strong advocate for an URI serving as the value to be used,
such that there is uniqueness of the CPAId. Others have advocated that
the CPAId be merely a unique string with the context of the two
parties... While it is clear that this could be the case, it leaves
things too loosy-goosy for my tastes and provides no guidance or
constraints as to how the uniqueness property is achieved.

Another approach that I've put forth is the notion that the
initiating party determines the value of the CPAId created, scoped
to their domainname (where they can define their own namespace).

Needless to say, I don't believe that it is TR&P's place to constrain or
define the scheme, we can only participate in suggesting appropriate
schemes that might be adopted. RegRep would be the likely candidate
to define a RegRep UUID (or URI) scheme.

>    Suggestion: Predefine an 'anonymous' CPAId to allow for discovery.

This isn't possible, IMHO. A CPA declares the technical details of
EACH party and it defines a specific business process binding to
said technical details. This includes endpoint URIs for the supported
transport protocol, security details such as certificates used for
digitally signing and authentication, etc. that cannot be "annonymized".
A CPA template might be employed, but IMHO, that's what a CPP is.
I think it likely that the Registry will need to provide an alternate
means of obtaining its CPP than via ebXML MS. HTTP URL would seem
the most likely candidate.

> I recommend a text node value of "anonymousQuery" within a CPAId to
> represent a blank-slate CPA for guest users and bootstrap capability.

I'm not sure that I follow. How would you intend this to work?

> You may have reason to use a URI instead. Ideally there should be a
> pre-defined CPP document(s) outlining the required capabilities of a
> client using guest access, but in the absence of a hard CPA schema, a
> placeholder CPAId would do.

Yes, this is closer to where I think that we're headed...

>
> lines 514-519:
>      Service element: Again, what are the valid range of values. Is this
> range of values ebxml-defined, implementor-defined or
> application-defined? If I wish to use a type attribute instead, what is
> the valid range of arguments to this attribute value?

In an ebXML context, the Service would identify a
BusinessTransactionActivity
(I think that's the current term from BPM) and the Action would identify
the Request or Response (I'm not sure that I have the names of these
correct).
The value of the Service and Action should be guided by the CPA that
governs the
message.

My own preference for the value of Service and Action would be an Xpointer
(possibly abstract with an implied context of the CPA identified by the
CPAId)
that "points to" a specific BusinessTransactionActivity in a given BP,
either included within a CPA or referenced through an URI of the BPM.

>     Suggestion: Dictate that all application and/or implementor defined
> services use URIs to ensure global uniqueness. Services that are
> ebxml-defined should have reserved type attribute values, ie:
> type="registry".

If the Service is an URI, the "type" need not be declared as the
default "type" is "uriReference". I fully concur that the value of
Service should be an URI. I strongly recommend that this be adopted
by ebXML for precisely the reasons you cite and many others.

>     Suggestion: Provide a small inline example for a combination
> Service/Action element combo.

That we'll most certainly do!

>
> lines 661-675:
>     Multihop Transmission 1 example: If I understand this correctly, (A)
> wants to send a message to (C) through (B). (A) does not specify (C)'s
> receiverURI at any point in transmission1. How does (B) obtain (C)'s
> receiverURI? Is it a requirement of the MSH Layer in (B) to map the <To>
> field from the header into a <ReceiverUri> for transmission2? (B) seems
> to obtain this data out of thin air.

ebXML Message Service specification doesn't define how an intermediary
obtains this information. That is strictly implementation dependent.
It would seem to me that an intermediary node in a multi-hop would have
some mapping between the PartyId in the To element and a receiverURI.
Again, how it gets this, and how it achieves this mapping is outside the
scope of the ebXML Message Service specification. Our scope is limited
to enabling intermediary node capability as per the requirements
we identified at the outset of ebXML.

>     I still do not see the overrall value of multihop messaging other
> than for proxy purposes. Is this the only purpose?

It is one, but not the sole purpose. Value-add intermediaries are
another, providing any manner of value-add from reliability/robustness
to businesss value-add.

>     Suggestion: Either dictate where party B should obtain the
> ReceiverURI from (note: this is Not an implementation detail; A and B
> are seperate parties!), or allow A to communicate it to B in
> transmission1.

We haven't and do not plan on addressing directed multiple hops
(where the initiating party prescribes the route to be taken). Nor
will we dictate or constrain an implementation as to how it effects
this manner of mapping (from To to ReceiverURI).

>
> line 765:
>     default value given for codeContext attribute: There is nothing
> wrong with this line! Hurray for default values!
>     Suggestion: more lines like this!
>
>     The underlying theme here is that each data element given in the
> specification that does not lend itself to an arbitrary range of values
> SHOULD have at least one of:
>   a) a default value
>   b) an acceptable range, pattern, or 'source' of values to choose from
>   c) a reference to a specification outlining valid values
>
>      Also helpful would be mention of which role, (ebxml, msh-server,
> msh-client, application-service, application-client) is to validate and
> which is to provide. This is not always clear except for in examples.
>
> - mikej