← Prev in month ← Prev in thread

[security-services] revised conformance spec

From
Robert Griffin <>
Date
2002-01-31T15:34:13+00:00
ID
Thread
[security-services] revised conformance spec
Title: revised conformance spec

hi -

i've attached a revised conformance spec, containing a new section 2.5 that stipulates that for any element in the schema that specifies an "unbounded" max value (included in table in conform spec), any conforming application or implementation must support a max value of at least 1000 (pretty arbitrary value, i know...).

i didn't modify test cases; i think the stipulation is reasonably covered by the pass/fail criteria in the current test case descriptions, which call out support for all required elements of assertions, requests and responses.

comments/corrections? 

bob

----------------------------------------------------------------------------

Minutes from 29-Jan concall

>

> Key Issues to resolve prior to last call.

>

> A) Stephen Farrell's note:

>

>    < http://lists.oasis-open.org/archives/security-

>      services/200201/msg00168.html >

>

> A.1) use of unbounded

>

>      candidate resolution: schema will retain unbounded, conformance

>      document will outline minimum expectations.

>

>      < http://lists.oasis-open.org/archives/security-

>        services/200201/msg00191.html >

>

- Joe: no detailed text posted on list

- proposes voting on keeping candidate resolution, pending text

- BobG: who would be responsible for text?

    - Joe: BobG for conformance

    - Hal: will set minimum expectation on receiver?

    - Joe: correct

- [Vote] no objections

-----------------------------------------------------------------------------------------------

Notes on issue:

22 Jan 2002 from Stephen Farrell

  - Why allow "unbounded" anywhere? I see no reason why 10000000000

  statements MUST be supported, which is what seems to be implied. Suggest

  including a max value that implementations MUST support, to be the same

  for all cases of "unbounded". Either incorporate this into the schema

  (e.g. "maxOccurs=1000") or into text (considering how versioning is

  currently done).

22-Jan from Bob Morgan

I'm no schema expert, but it seems to me that putting something like

"maxOccurs=1000" into the schema isn't the right thing, since it makes

sending 1001 of something invalid, where what we want to say is just that

it's not guaranteed to be interoperable.

I agree with the sentiment, but the stating of "must handle at least N"

seems to me to be much more appropriate for the conformance document,

though I have to say I can't quite see where it would go in the current

doc.  But it would be necessary, I think, for conformance tests to include

handling multiple instances of all the possibly-multiple items up to the

stated limits.

So, I believe this is an Issue that needs to be resolved one way or

another.

23-Jan: from Allen Rogers

I disagree. Putting arbitrary limits is generally a bad idea. We can't

propose to know all applications that this may be used for. What may seem

unreasonable today may not seem so unreasonable in the future. This has been

proven many times over in the technology field. Plus, any decent application

written to support 1,000 will do so dynamically and will just as easily

support 10,000 or 100,000. There may be performance implications but that's

for the application designer to address.

-Allen

 

draft-sstc-conform-spec-10.doc
← Prev in month ← Prev in thread