RE: Comments on ebXML Requirements document, 2000-1-4

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

Henry

See comments in line below marked with ##. Having completed them I realize
that to discuss some of these points on a tele-conference call would be a
good idea as I'm not sure I completely understand all of your points.

David

-----Original Message-----
From: Henry Lowe [mailto:hlowe@omg.org]
Sent: Thursday, January 06, 2000 8:31 AM
To: ebXML-Transport@lists.oasis-open.org
Cc: henry@emerald.omg.org
Subject: Comments on ebXML Requirements document, 2000-1-4


Hi,

The folowing are a few comments on the Requirements document 
that David circulated yesterday.  Sorry I can't put these 
comments in-line (for context), but I only have the PDF reader.  

Clause 1.1:
Requiring the transport to carry anything, either "XML or other 
electronic formats" seems to be leaving it up to the communicating 
applications to perform all conversions to deal with different, 
"endians", character sets, etc.  This would seem to be a lot of 
extra code required for applications.  I would suggest we deal 
only with XML which means that the transport value-add and deal 
with some of these common problems.  Do we want more than an 
ASN.1 ANY or octet string?
## A couple of points:
1. There is a real need to transport non-XML data, for example you might
want to include a Word document that provided additional information about
an order you had placed. You can do this by wrapping base64 encoded
documents inside a an XML element defined as PCDATA.
2. I'm not sure that we want to support ASN.1 at all directly. This is just
a method of defining the structure of data which XML already defines.
3. ANY is OK but limits you to XML syntax##


Clause 2.1:
Am I correct is reading this as a list of options the transport 
shall provide and does not require they always be in use?
## They can, but need not, be provided by the transport##

Clause 2.1.b:
Who is the original sender?  If there are indirections at the 
application level, it would be too difficult for the transport 
to do this IMHO.
## Agreed - deleted "original"##

Clause 2.1.c:
Doesn't 1.3 above subsume this?  If not, I'm not sure I understand
this bullet.
##Agreed - deleted##

Clause 2.1.d:
This would seem to be an implementation/operational requirement, not 
a transport specification requirement.
##Agreed this is an implementation/operational requirement. However support
for this feature might be provided by the transport specification##

Clause 2.2.a:
This would seem to be very much dependent on 1.1.  If the transport 
is nothing but a conveyor of ANY(s), it knows nothing of the bits 
it's carrying and this requirement would seem unreasonable.  On the 
other hand, if the transport is providing a value-add for XML, there 
would be certain well-formedness checks that could reaonably be 
expected.  Might I suggest that this requirement is rather dependent 
on 1.1?
##I agree there is a dependency and providing errors in documents that are
not wrapped would be difficult. I still think that it is a valid
requirement.##

Clause 2.2.b:
Isn't this just non-delivery reporting?  If a reason code can be returned,
that would be an added bonus.
## See below.##

Clause 2.2.c:
Please see comment on 2.2.b.
## See below.##
Clause 2.2.d:
Unless I misunderstand this bullet, please see comment on 2.2.b.
## I agree this is not very clear so I've rephrased section 2.2 so that it
now reads ...
"2) Technical errors or problems with documents must be capable of being
reported. This to include:
    a) reporting on message structural errors e.g. the message or one of the
documents it contains is incorrect 
    b) reporting if a message is sent that the other party cannot be
processed e.g. it cannot handle the message type.
    c) the application cannot process the message e.g. the message, although
structurally OK does not contain all the information that is required.
    d) the actual data content is not processable e.g. an alphabetical
product number when the application accepts only numeric values."##

Clause 2.3:
I believe this is an application concern, not a transport standard 
concern (an app which understands the business aspects would raise 
an error or exception?).
## I agree, but I think that it is useful for there to be standard approach
to reporting that a business process has failed as the transport protocol
might be otherwise expecting a response that will not arrive.##

Clause 2.4:
This isn't always possible and you also want to differentiate between 
transport failures and application failures.
## I agree that you want to differentiate between transport and application
failures. I also agree that you can't always do it since some processes may
not support inquiries. However, if you do want to do an inquiry, then there
is benefit in having a standard approach towards doing this.##

Clause 4:
In light of the footnote on 4.1.b, might I suggest we look at having 
separate requirements for Transport and Packaging?  It seems the items 
in Clause 4 are more (though not exclusively, e.g., 4.2.b would be 
transport) Packaging than Transport.
##I agree but we are a "Transport, packaging and routing" group therefore I
think they are in scope. This doesn't mean that one
technology/standard/initiative should provide all the requirements##

Clause 5.1 and 5.2:
Is this transport of Packaging?
##I would say it's more packaging than transport - but definitely within
scope##

Clause 5.3:
This goes way beyond what anything other than a very specialized 
transport could provide -- in a sense this is workflow (which CORBA 
does have -- work done cooperatively with WfMC).
## It depends on what you mean by workflow. I understand workflow as being
the sequence in which business documents get exchanged in order to support a
particular business process. The trace process is useful since it enables
you to find out where your document has got to. It's the electronic
equivalent of contacting FedEx to find out what's happend to the package you
gave them. Given the disparate nature of the various systems through which
messages might be sent, having an ability to trace a document is very
useful.##

Clause 5.4:
Would this be Packaging?
##It's more packaging than anything else but being able to sign data for the
purposes of non-repudiation and tamper reistance is an important
requirement.##

Clause 6.1:
Aren't these definitions, not requirements?
## Items a and b within this section are defintions. It's just that I
thought it would be useful to include a description of what is meant by
"Session based and/or long term transactions". Do you think these should go
in the definitions document?##

Clause 6.2:
These items would seem to be involve a combination of application, 
server, and transport -- they are not JUST transport requirements, IMHO.
##The ability to negotiate how two servers interact is I think an important
requirement. I agree though that items c and d are requirements and they
have been deleted.##

Clause 6.4:
This would seem to be more application than transport, though the 
transport would certainly need to be able to provide the comm 
mechanism to convey the status query and response.
##It is application oriented but as you say there is benefit in there being
a transport mechanism to convey the query and response.##

Clause 6.5:
I believe what this means to say is covered in 2.1 -- two phase commit 
transactional semantics (the sort of thing offered by CICS and OTS).
## Agreed. I left it in since it was from the original presentation we did -
I've deleted it.##

Clause 7.1:
This is very general (perhaps too general to be included here?).
## Why is this too general to be included?

Surely you should be able to send a document (e.g. an XML document wrapped
in MIME over HTTP) to someone else without *having* to know anything about
the internal architecture of the "box" that will receive it (see my last
email for more on this). If you accept this premise then it means as it is
says ... "Servers/systems that support the transport of documents can be
treated as black boxes"?##

Clause 7.2:
Great!!

Clause 7.3:
I would interpret this as saying that the right level of API must be 
available (and I would support this).  Also, the API should be language 
independent.  Is this the correct understanding?
##Perhaps we are talking about the same thing, but I'm not sure. It's just
that I tend to think that APIs are used in procedure calls by programs. Is
that what you mean? I agree though that any API specification should be
language independent so that it can be mapped to different
languages/environments.##

Clause 7.4:
Isn't this covered by 7.2.a?
##I agree there is some overlap this is really suggesting that the solution
needs to be scalable.##

Clause 8.1:
Isn't this more a workflow type thing?  and not strictly transport?
##It depends. It could be done in a business workflow. It could also be done
at the transport level independent of the business workfloww. For example if
the transport knows that a server is not available for some reason, then it
can queue message that need to be sent without the application needing to
know anything about the temporary problem.##

Clause 8.2.a.footnote 5:
Couldn't we include CORBA in this list in case folk want an object 
oriented transport?  :-)
##Sure - changed.##

Clause 8.2.b:
This involves two phase commit transactional semantics which you 
probably don't want to require of all transports all the time, see 
comment on 2.1.  SMTP and HTTP do not provide this; however, CORBA 
does.
## Agree that SMTP and HTTP do not provide the answer and that something
extra is needed.##

Hope these comments are useful is getting ready for Orlando.

Best regards,
Henry