RE: Comments and Suggestions - 0.9a

["Burdett, David" <david.burdett@commerceone.com>]

Michael

We have long had the idea of a "bootstrap" CPA that defined a set of rules
that would have to be supported by all implementations, that is I think the
same as your idea for lines 496-499. Work on this is still to be done.

On Service element, you said ...

>>>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".<<<

Version 0.91 says ...

>>>If the type attribute is present, then it indicates that the parties that
are sending and receiving the message know, by some other means, how to
interpret the content of the Service element. The two parties MAY use the
value of the type attribute to assist in the interpretation.

If the type attribute is not present, the content of the Service element
MUST be a URI [RFC 2396]. If it is not a URI then report an error with an
errorCode of Inconsistent and a Severity of Error (see section 11).<<<

This is really saying that if the type element is present then it is
mutually aggreed between the two parties involved. This means that it does
not need to be URI since it needs to be interpreted in the context of the
two parties ids.

David



-----Original Message-----
From: Michael Joya [mailto:mike.joya@xmlglobal.com]
Sent: Monday, January 08, 2001 2:55 PM
To: ebxml-transport@lists.ebxml.org
Subject: Comments and Suggestions - 0.9a


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.
   Suggestion: Predefine an 'anonymous' CPAId to allow for discovery.
I recommend a text node value of "anonymousQuery" within a CPAId to
represent a blank-slate CPA for guest users and bootstrap capability.
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.

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?
    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".
    Suggestion: Provide a small inline example for a combination
Service/Action element combo.

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.
    I still do not see the overrall value of multihop messaging other
than for proxy purposes. Is this the only purpose?
    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.

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