OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [ebxml-cppa] Re: [ebxml-msg] Comments on ebMS_v1.04c




David Fischer wrote:

<snip/>
> 
> On the Signature Transforms, we know there is a problem and we need to change so
> that we do Includes rather than Excludes.  I'm just not sure how to do that yet.
> Ideas?


Actually, I think that an exclusive approach is still superior. One
approach we could consider would be to exclude any element that had
a SOAP actor attribute with a value of either the SOAP 'next' or
the ebXML 'nextMSH'. This would exclude all content that was subject
to "change" (where the nature of the change might be that it is
removed by an intermediate SOAP or ebXML MSH node).

An inclusive approach would be too tedious IMO and over-complicate
things. It should also be possible to exclude any Signature element
from consideration (this would be slightly redundant with the
enveloped-signature Transform when but a single Signature is
applied, but that's okay).


> 
> On two sets of retries, yes, this became a problem when we removed CPAId from
> Via.  I asked Dale about this in the CPPA Con Call.  I don't yet know how to fix
> this.  Perhaps we can leave this as an implementation detail (global
> retries/retryinterval to the first IM).


You do not need two sets of retries. Nor should we be pursuing a solution
that required this.


> 
> On MessageOrder, we discussed this and we decided that only duplicateElimination
> was required for messageOrderSemantics to be Guaranteed.  You are saying Acks
> are required too?


I think that the point w/r/t the relationship (if any) between messageOrderSemantics
and RM is that in order to ensure that the order is preserved, you also need
to ensure that all of the messages will be received. I don't think that
we need to say anything about this other than to suggest that messageOrderSemantics
without some manner of reliable delivery could prove to be a problem. We
should NOT be suggesting any relationship between AckRequested and MessageOrderSemantics
as the AckRequested/Acknowledgment module is but one possible means of
ensuring that messages are delivered reliably.


> 
> Thanks again,
> 
> David Fischer
> Drummond Group.
> 
> -----Original Message-----
> From: Arvola Chan [mailto:arvola@tibco.com]
> Sent: Sunday, October 14, 2001 5:54 PM
> To: ebxml-msg@lists.oasis-open.org
> Cc: ebxml-cppa@lists.oasis-open.org
> Subject: [ebxml-msg] Comments on ebMS_v1.04c
> 
> 
> David:
> 
> Please see the attached Word document (View Comments) for the contexts for
> these comments.
> 
> Regards,
> -Arvola
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> 
> Page: 2
> Fulfills
> 
> Page: 2
> Pete Wenzel (RosettaNet/SeeBeyond) is missing from this list. Actually,
> quite a few names found on http://www.oasis-open.org/committees/ebxml-msg/
> are missing from this list.
> 
> Page: 2
> E2Open
> 
> Page: 7
> This section needs to be updated to reflect more closely the current round
> of modularization changes. Also, the use of punctuation after each bulleted
> item seems inconsistent.
> 
> Page: 7
> Invalid reference
> 
> Page: 7
> Invalid reference
> 
> Page: 7
> Invalid reference
> 
> Page: 7
> There is a section 11 with the title Multi-Hop Module. Appendix C is
> currently titled Supported Security Services.
> 
> Page: 17
> Chris Ferris has suggested that the namespace value should match the
> schemaLocation value. The examples need to be updated accordingly if we
> agree to adopt that convention.
> 
> Page: 23
> Shouldn't the TimeToLive element be present if Reliable Messaging is in use?
> 
> Page: 23
> How can the equivalent of BestEffort be specified? In that case, the
> semantics is not at-least-once.
> 
> Page: 25
> I find the reorganization of the Security section rather awkward. Shouldn't
> the section on Security and Management precede the sections on Signature
> element and on Signature Generation. It does not make sense talk about
> Signature Generation even before Persistent Digital Signature is introduced
> as a countermeasure technology.
> 
> Page: 27
> This is insufficient. If intermediaries can change the AckRequested and Via
> elements, then these elements have to be excluded from the signature.
> 
> Page: 28
> This section needs to be updated to reflect changes in the 1.1 CPP/A spec.
> Currently, the CollaborationRole element contains a CertificateRef element
> that is also used for security definition.
> 
> Page: 30
> Should www.ebxml.org be replaced with www.oasis-open.org?
> 
> Page: 31
> This should probably be replaced with an appropriate XPointer.
> 
> Page: 33
> What happens when the incoming message specifies syncReply=true? Shouldn't
> errors be returned synchronously in this case?
> 
> Page: 33
> I suggest moving this section to the end of Part II Optional Features.
> Alternatively, the introductory paragraph in this section should be updated
> to indicate that optional elements from Part II can also be present.
> 
> Page: 35
> Incorrect statement.
> 
> Page: 35
> Should this be replaced with oasis-open.org?
> 
> Page: 36
> I don't see why this is necessary. A DeliveryReceipt is generated by the To
> Party MSH and should be returned at the latter's earliest convenience. It
> should always be possible to piggyback the DeliveryReceipt element with the
> first application level message that is in response to the message in
> question and therefore be able to share the same RefToMessageId in
> MessageData. If the DeliveryReceipt is sent on its own, again the
> RefToMessageId in MessageData should suffice.
> 
> Page: 36
> This contradicts lines 1397 and 1398.
> 
> Page: 36
> Duplicate elimination may be a more meaningful phrase in this context.
> 
> Page: 37
> Messages that are sent in response to messages arriving on a reliable but
> synchronous delivery channel also need to be kept in persistent storage!
> 
> Page: 37
> Is the presence of a Via element mandatory when there are two instances of
> the AckRequested element?
> 
> Page: 37
> This suggests that the From Party MSH can request the To Party MSH to return
> an end-to-end acknowledgment, thereby rendering the DeliveryReceipt element
> redundant. I would recommend getting rid of the DeliveryReceipt element.
> 
> Page: 38
> Should this be replaced with oasis-open.org?
> 
> Page: 38
> An.
> 
> Page: 38
> Included in the same message with.
> 
> Page: 38
> What is this attribute?
> 
> Page: 38
> Shouldn't this be the From Party?
> 
> Page: 38
> Should this be "used by one Message Service Handler to indicate to another
> Message Service Handler that it ..." instead?
> 
> Page: 39
> Again, I question whether this is necessary. See my earlier comments
> regarding the use of a RefToMessageId attribute within the DeliveryReceipt
> element.
> 
> Page: 39
> Is the presence of a Via element mandatory when there are two instances of
> the Acknowledgment element?
> 
> Page: 39
> Incorrectly cut and pasted.
> 
> Page: 39
> Corresponding to the ...
> 
> Page: 39
> Isn't it true that an Acknowledgment element an an AckRequested element
> cannot be present in the same ebXML message if the latter is not generated
> by the application layer?
> 
> Page: 40
> Please note that Retries, RetryInterval, PersistDuration are only in the
> CPA, not in the message header.
> 
> Page: 40
> Spelling.
> 
> Page: 40
> Spelling.
> 
> Page: 40
> Spelling.
> 
> Page: 40
> Spelling.
> 
> Page: 40
> Is there such an element? There is a duplicateElimination attribute in the
> QualityOfServiceInfo element.
> 
> Page: 40
> See comment above.
> 
> Page: 40
> Has received?
> 
> Page: 40
> There are two kinds of retries: retry due to non receipt of Acknowledgement
> from the nextMSH, and retry due to non receipt of Acknowledgment from the
> ToPartyMSH. The CPA only deals with the latter type of retry.
> 
> Page: 40
> See above comment on Retries.
> 
> Page: 41
> This statement is imprecise. TimeToLive is of type dateTime whereas the
> product of Retries and RetryInterval is of type duration.
> 
> Page: 41
> This should be of type duration.
> 
> Page: 41
> The timestamp for a reliably sent message (found in the message header),
> plus its PersistDuration (found in the CPA), must be greater than its
> TimeToLive (found in the message header).
> 
> Page: 41
> All of the figures in this section illustrate the single-hop case. It should
> be made clear whether the discussions apply both to the single-hop and
> multi-hop cases.
> 
> Page: 42
> This statement is very confusing. Why should it be either or? It seems that
> if the sender is aware of the use of an intermediary, then it should specify
> two AckRequested elements. The phrase "as determined by the AckRequested
> parameter" is rather meaningless.
> 
> Page: 42
> Are we waiting for the Ack from the nextMSH or the ToPartyMSH?
> 
> Page: 42
> Again, are we talking about an Ack from the nextMSH or an Ack from the
> ToPartyMSH?
> 
> Page: 42
> Isn't it the case that only the ToPartyMSH is supposed to perform duplicate
> elimination?
> 
> Page: 42
> Intermediate MSH's should not have to do this.
> 
> Page: 42
> If the CPA indicates that an application response is included, then it must
> be the case that the processing of the earlier message is not yet complete.
> In this case, the MSH must wait for the response to the earlier message and
> then return it synchronously.
> 
> Page: 43
> I still think that either all intermediaries, or none of them, should
> exhibit store and forward (with retry) behavior.
> 
> Page: 43
> Earlier discussions in this draft indicate that an Acknowledgment message
> must contain an Acknowledgment element. See line 1443.
> 
> Page: 43
> I think we should allow for the possibility of having the Acknowledgment
> message returned synchronously without being piggybacked on the business
> response.
> 
> Page: 43
> Should this be oasis-open.org?
> 
> Page: 43
> This works only for the ToPartyMSH. Need to explain how an intermediary
> should populate the From andTo elements when it needs to generate an
> intermediate Acknowledgment because sync reply is not in use.
> 
> Page: 44
> Need to account for the fact that there are two kinds of retries and two
> sets of retry parameters.
> 
> Page: 44
> Strike out this phrase.
> 
> Page: 44
> I suggest renaming this as "first response message"
> 
> Page: 45
> First response message.
> 
> Page: 45
> The From Party MSH many have no knowledge of an intermediate MSH. Why should
> it trust a Delivery Failure Notification from an untrusted intermediate MSH?
> 
> Page: 46
> Should this be oasis-open.org?
> 
> Page: 49
> Should this be oasis-open.org?
> 
> Page: 49
> Should this be oasis-open.org?
> 
> Page: 49
> Use.
> 
> Page: 49
> This is quite different from the 1.0 spec which states that the
> SequenceNumber element must not be present unless deliverySemantics is
> OnceAndOnlyOnce and messageOrderSemantics is Guaranteed. Message ordering
> cannot be guaranteed unless messages with sequence numbers are guaranteed
> not to be lost!
> 
> Page: 50
> I don't think messageOrderSemantics is currently specified in the CPA. We
> may have to provide feedback to the CPP/A TC.
> 
> Page: 51
> Does this rule apply only to the ToPartyMSH or does it apply to the nextMSH
> as well?
> 
> Page: 51
> Should the AckRequested element that is addressed to the nextMSH be placed
> under the Via element?
> 
> Page: 52
> Should this be www.oasis-open.org?
> 
> Page: 52
> Don't need to capitalize?
> 
> Page: 52
> Forwarding the message to ...
> 
> Page: 52
> The sending MSH may not be aware of the use intermediate MSH's and therefore
> not include a Via element. When the first MSH forwards the message to the
> second MSH, it will have to construct a Via element that contains a
> TraceHeaderList with Two TraceHeaders!
> 
> Page: 55
> The sending MSH may not be aware if any intermediary is used in the message
> path. Therefore, the decision to exclude the Via element from the signature
> must not rely on knowledge of the presence or absence of intermediaries.
> 
> Page: 56
> The locations of these schemas have to be updated.
> 
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC