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


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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

Subject: [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.



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

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.




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

Powered by eList eXpress LLC