[ebxml-iic] Re: [ebxml-iic-conform] Comments on ebXML MS ConformanceTestRequirements

[Michael Kass <michael.kass@nist.gov>]

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