← Prev in month
← Prev in 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