RE: Consolidated comment list

["Kudela, Melanie" <MKudela@uc-council.org>]

Ian,

I did not see our comments in the consolidated lists as per the email - even
though they were sent out last Friday. They are resent below again as you
may have missed the original email.

Melanie



All,

	the attached is the consolidated list of comments on version 0.98 -
only up to noon (east coast) Saturday.

 <<Comments.doc>> 

Ian Jones
E-Commerce Engineer

PP E1B
84-85 Adam Street, Cardiff, CF24 2XF
> *Tel:  +44 (0)29 2072 4063
> * Fax: +44 (0)29 2045 8781
Email: ian.c.jones@bt.com  
 




>  -----Original Message-----
> From: 	Kudela, Melanie  
> Sent:	Friday, March 09, 2001 5:15 PM
> To:	ebXML Transport (E-mail)
> Subject:	TRP v0.98 - Comments
> 
> 
> Our comments, from UCCNet and UCC, are directed at the implementation of
> the standard and at a section-by-section  review of the document:
> 
> - we have a requirement for an additional layer which we call the command
> layer and which you can read more about in the attached document. However,
> there is no way for us to plugin this layer, without breaking the
> standard.
>  << File: Architecture 011701.doc >> 
> - Is two pass parsing required to parse the message and payload; and if
> yes, what are the implications on performance?
> - One difficulty that we are having is that there are tags that are not
> present in the t&r spec, but are necessary for us to transport and route
> our messages correctly. There is no extensibility to allow us to add our
> tags to the ebXML t&r message header, manifest, etc. without breaking the
> standard. 
> -Manifest structure will work but is not perfect 
> -Requires use of UUID algorithm for message id/MIME identifiers 
> -Requires use of MIME structure - both this and the previous point make it
> more difficult to involve a SME with out buying tools to implement it.
> Cannot simply create an XML document and send it, you must jump through
> hoops to create the proper message.
> 
> -  of major importance to us at this time. It seems that ebXML and EDIINT
> are
> alternatives and they don't  fit together. Nowhere in the doc was
> EDIINT even mentioned as a transport or in any a partner spec.
> 
> - Does anyone have prototype ebXML message transport handlers out there?
> (From our experiences with EDIINT vendors, it seems that their products
> are just slightly ahead of being prototypes and adoption of EDIINT is
> rather limited.) It seems that ebXML is the successor to EDIINT and the
> two aren't necessarily compatible.
> 
> ebXML Participants (2)
> Why are there so few "trading companies" represented? (I count Chrysler
> and Kraft) Perhaps they are better represented on other parts of the ebXML
> efforts.
> Curious especially by the lack of representation by the financials and
> software companies that serve the financials. Messaging has been going on
> there for 30 years. For example, I would have expected someone like
> Reuters or Hogan to be participating.
> Introduction (3)
> It looks like a SOAP processor is now needed? (I need to read up on SOAP
> some more to further understand that implication)
> Why no mention of EDIINT anywhere?
> This section should show how the T&R stuff fits into the ebXML
> architecture as a whole. Where does the message transport service end and
> something else begin?
> The protocol should be described using a protocol stack. Need to show how
> the different services communicate with their peers. Need to show
> dependencies between services in stack form. Each service is responsible
> for wrapping / unwrapping / processing some of the message.
> Our specific interest: are we looking at this from the point of view of
> developing it or utilizing it?
> Comments in various places say that this is supposed to be a "low-cost,
> simple" messaging scheme. Nothing about it seems to be low-cost or simple.
> It's not overly baroque, but I wouldn't't say that a low cost hack could
> implement it.
> System Overview (6)
> The "message service overview" and accompanying picture are not
> consistent. Missing from the picture are "heading parsing", "security
> services", "reliable messaging services".
> Missing from the textual description is "authentication, authorization and
> repudiation".
> These services should be presented as a protocol stack. There are
> dependencies and an orderly path that a given message needs to take
> through the message handler.
> Where is the SOAP processor? What is its role?
> Need to show interaction scenarios between the components. (or is that
> done elsewhere?)
> Packaging Specification (7)
> Was the addition of SOAP the significant change made since the last draft?
> (think so)
> Why only a single header?
> Is there a limit to the number of payloads? Is there a practical limit?
> Can a potential recipient set /advertise this limit if their
> implementation has some sort of limit?
> ebXML SOAP Extensions (8)
> Judging from the number of comments that I made, this chapter is too long.
> I can't make heads or tails of section 8.2 (line 310). It seemingly
> contradicts itself in the first sentence. The title is "ebXML SOAP
> Envelope Extensions", but then in the body it first says that it does not
> extend, then says it does extend. ENGLISH PREFERRED! 
> 8.2.2 Regarding signatures, is (can be?) the header separately signed? Or
> does the signature in the header sign the entire contents? Well, just a
> bit confused here because if the signature is part of the header, then the
> signature can't sign the header (recursive, no?) Why isn't the signature
> for the entire message a separate part?
> 8.3 Is all of the message header to be in plaintext? Or can it be
> encrypted? If mandated to be in plain-text, will it be disclosing any
> private trading relationships since it has to, from, service, action, etc.
> in it? For example: to:levi's, from: walmart, service:
> private-label-purchasing, action:create PO
> 8.5.4 What is the intent for a single service/action pair with regards to
> the handling of multiple payload documents? It seems that there is no way
> for packaging of heterogeneous types of payload and sending it all to a
> single service unless that service is extremely generic in nature. Is
> there any to allow a service/action pair in a manifest entry so that a
> piece of payload could be directed to a service different from other
> pieces?
> 8.5.1 To and from elements: what are the allowable types of identifiers?
> How are they resolved to physical entities? (can we chant "registry"?)
> 8.5.1 To what kinds of entities are to/from to refer? The business parties
> involved in the transactions? The message transport instances that are
> sending the messages? How far up/down the chain? How do they correlate to
> the physical endpoints that are transporting messages?
> 8.5.2 CPAId: (later on I found out sort of what a "CPA" is) CPA needs to
> be defined.
> 8.5.3 Conversation ID: it implementers free to choose how they identify
> and store ...... and SHOULD provide a facility for mapping.... THEN won't
> an implementer need to implement a map to every other implementation that
> it converses with? This seems not particularly interoperable.
> 8.5.4 Service: who assigns service names? Who regulates? How are they
> published? Is there some kind of "endpoint capabilities" query?
> 8.5.4.1 Type attribute: I can't understand these paragraphs. Rewrite.
> 8.5.7.1 MessageOrderSemantics: how to detect missing messages? Is there a
> concept of a "sequence number gap"? (I've implemented numerous systems
> like that in the past). What is the receiver to do if a message that makes
> up a conversation is missing? Is there a way to request re-transmission?
> 8.5.7.2 DeliveryReceiptRequested: if it is used to provide a
> business-level acknowledgement, then call it that. Don't call it a
> delivery receipt if it isn't really a delivery receipt.
> 8.5.8 Who signs a signed receipt? The message handler that receives the
> message, or the end party to which it was addressed?
> 8.5.8 Sequence numbers within a conversation: if I have multiple, dynamic
> conversations outstanding, and I have to maintain a sequence number for
> each, my bookkeeping will get somewhat complex.
> 8.5.8 Sequence reset: incredibly confusing. Rewrite.
> 8.5.8 Is there a way to request re-transmission of previously received and
> acknowledged messages? This is very important in a disaster-recovery
> scenario. A backup site may not be 100% in sync with the primary site. In
> the past, the first thing that a backup transport would do upon activation
> is request retransmission of message that have been sent since a given
> point in time to being it up to the current set of messages that had been
> sent to it. Of course, when the are multiple senders, this can be very
> difficult. It would probably need to poll all of its partners and make
> sure that it is in sync with them.
> 8.5.8 Also this kind of retrieval is useful in problem investigations.
> Is there any required "heartbeat" message that is to be sent periodically
> so that we know that everyone that we expect to be alive truly is?
> 8.6 Mult-hop: not entirely sure how this all works. Does each hop create a
> new header and re-sign the message? Is an intermediary hop allowed to do
> anything but forward the message? What do conversation and sequence number
> mean in a multi-hop context? Do they identify the end-to-end conversation
> or conversations between the intermediaries? What do to/from mean in a
> multi-hop context?
> 8.7.5 Can things like reliableMessagingMethod change between hops? Or does
> what was specified by the originator constrain what the intermediary hops
> can do?
> 8.7 How does non-repudiation work in multi-hop context?
> 8.7 What are legal responsibilities of intermediaries?
> 8.7 "via" element: how many hops forward does it apply?
> 8.7 Signature: what is scope of text included in signature? Who's
> signature is it? The "from" party? The message transport system that is
> sending the message?
> 8.12.5 messagerStatus attribute: can there be a value of "accepted" or
> "rejected"? Or do we consider "rejected" messages to be received? Where is
> "persistDuration" defined?
> 
> Reliable messaging (10)
> 10.2.3 time to live: what does timeToLive mean in a multi-hop context? The
> time to make one hop? The time to be received and acknowledged by the
> ultimate recipient?
> 10.2.6 persistDuration: who determines this? Does the sender mandate it?
> Or the recipient?
> 10.3 reliabl e messaging protocol: this looks remarkable like what we
> invented one afternoon for UCCnet. I think that there must be more to it,
> no?
> How does recipient request re-transmission of lost messages? (detected via
> sequence number gap)
> 10.3.1.5 duplicate message handling: Re-sends should be marked as
> "possible duplicates".
> Security (12)
> 12.3.1 persistent digital signature: who is the entity signing the
> message? How do we correlate vs. the "from" party?
> 
> 
>