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: 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