[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [security-services] the "unbounded" issue
Allen, There are also DoS issues. Every time I see an XML schema with an unbounded I think of DoS. Maybe I'm paranoid, but I think we're building ourselves some interesting future problems ('course we'll still have jobs to do as a result:-). Stephen. Allen Rogers wrote: > > 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 > > > -----Original Message----- > > From: RL 'Bob' Morgan [mailto:rlmorgan@washington.edu] > > Sent: Wednesday, January 23, 2002 7:25 PM > > To: OASIS Security Services TC > > Subject: [security-services] the "unbounded" issue > > > > > > > > On Tue, 22 Jan 2002, Stephen Farrell wrote: > > > > - 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). > > > > 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. > > > > - RL "Bob" > > > > > > > > ---------------------------------------------------------------- > > To subscribe or unsubscribe from this elist use the subscription > > manager: <http://lists.oasis-open.org/ob/adm.pl> > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC