[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-iic] Re: [ebxml-iic-conform] Comments on ebXML MS ConformanceTestRequirements
Michael, Your vote has been recorded. I had asked that the IIC team review the documents and vote in the ebxml-iic-conform mailing list. In addition, I will take a voice vote at the upcoming IIC phone conference on Monday, the 12th to close the issue. Thanks for your suggestions! Mike At 02:37 PM 8/8/2002 -0700, Michael Wang wrote: >mike, > >thanks for such quick turn around >how do i cast the vote? simply to you? vote is Yes. >i am also assuming we're only voting this doc? (& not the >interoperability one?) >thanks. >-mw > >Michael Kass wrote: > > > > At 04:13 PM 8/7/2002 -0700, Michael Wang wrote: > > > > > I have the following comments on this doc. Sorry for being so late. > > > > > > I think test cases urn:semreq:id:93 and urn:semreq:id:94 need to > > > have their assertions flipped. Case 93 is for not supported and > > > so the severity should be Warning (as opposed to Error) and the > > > other way around for 94. > > > > [MIKE] - You are correct. Swapped the severity for these two requirements. > > > > > Test case urn:semreq:id:159: it may be clearer to put in the assertion > > > exactly what the namespace is rather than the term "XML Signature". > > > > [MIKE] - I agree that this is more explicit and clear as a a requirement. > > Made the change. > > > > > Test case urn:semreq:id:160: it may be clearer to add in the assertion > > > the specific version/URL of the XML Sig Spec. > > > > [MIKE] - Added the URL to the assertion. > > > > > Test case urn:semreq:id:179: I actually disagree with this. Going > > > back to the spec (line 187) it said nothing about MUST, SHALL. Why > is now > > > a Required item for conformance? > > > If I remember correctly the Messaging Committee had trouble agreeing > > > on this specific issue: sign first vs encrypt first. The supporter > > > for sign first then encrypt happens to be the editor and so he decided > > > to put in as a NOTE. > > > We must note that the encryption here is related to Payload encryption. > > > As such the application layer would have encrypted it before passing > > > it to the MSH layer for signing and shipping. Therefore, it does not > > > make sense to do Signing then encryption. > > > I believe this item should be made Optional and ask the Messaging > > > Committee for clarification. > > > > > > > [MIKE] - I changed this requirement to optional, pending input from the > > MS TC > > > > > Test case urn:semreq:id:190: I think the assertion is incorrect. > > > It should say Timestamp element IS present as opposed to not present. > > > > [MIKE] - Actually, when I look at the "Name" for this requirement, it is > > called : SetTimestampNotAuthorized > > I believe the intent was to assert that the TimeStamp element is not > present for > > a StatusRequest that is not authorized. So I believe that the problem > with this > > requirement was that it stated the condition that the message being > reported was > > NotRecognized.. instead of the request being UnAuthorized. I changed > the condition > > to reflect the name of the requirement. > > > > > Test case urn:semreq:id:191: I think the precondition should have > > > an additional condition that the request is not supported/authorized. > > > By itself the way it is the assertion does not make sense. > > > > [MIKE] - I agree that as written, the assertion does not make sense. > Changing it to: > > > > For each received message, if the message contains a StatusRequest > element AND the request is > > UnAuthorized: > > The messageStatus attribute in the StatusResponse element has a value > of 'UnAuthorized'. > > > > > Test case urn:semreq:id:193: I think it needs the additional precondition > > > of "RefToMessageId element value is recognized and not yet processed". > > > > [MIKE] - Agreed, added this condition > > > > > Test case urn:semreq:id:194: I think it needs the additional precondition > > > of "RefToMessageId element value is recognized and is processed". > > > > [MIKE] - Agreed, added this condition. > > > > > Test case urn:semreq:id:197: I think the assertion should be reworded. > > > Signature element may not exist. It is only there is the channel > > > requires signing of documents. > > > > > > > [MIKE] - Agreed. Changed the wording to: > > > > The message consists of no payload and the MessageHeader and Signature > elements ( if present ) > > are configured as specified in the Message Service Specification > > > > > Test case urn:semreq:id:198: Same comment as in 197. > > > > > > > [MIKE] - Modified the same way as 197 > > > > > I may have missed some discussion on this but how do I tell from > > > this document what's level 1 conformance and what level 2? > > > > > > > [MIKE] - We no longer group requirements by level, only functional > modules. Level and profile > > grouping will be done at a higher level XML document, > > that will select from this "Master List" to create whatever > level/profile combination is desired > > for testing. > > However, that being said, for testing purposes, we are revisiting what > should constitutute levels > > of functionality for testing purposes. In November of last year, > > it was agreed that 2 levels of functionality must exit in applications > to do conformance and > > interoperability testing. We will discuss if that decision is still > > valid in our next phone conference. > > > > [MIKE] - I hope that these changes will let you make a decision on > whether or not to vote for this > > document to be submitted to the MS TC for review. > > I have attached the new HTML version reflecting your > corrections/modifications. > > > > > -mw > > > > > > > > > ---------------------------------------------------------------- > > > To subscribe or unsubscribe from this elist use the subscription > > > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > Name: ebxml-iic-msg-reqs.html > > ebxml-iic-msg-reqs.html Type: Hypertext Markup Language (text/html) > > Encoding: BASE64
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC