Re: unbounded (was: Re: Opaque (Client) Data)

 
 
As this is a interop, security and performance consideration, we will want to warn about this.  We could put it in a conformance clause somewhere (expected to handle a max of 10,000 elements, or whatever reasonable).  Note that this number could be different for each occurance of unbounded and hence an audit of the same is required. 
 
So, I would suggest that we make a list of all occurances of unbounded and come up with reasonable finite values and have a section on the same in the spec.
 
Note: SAML V1.0 and V1.1 did something similar in its Conformance doc - though not like the table that I am proposing, it does have the conformance clauses.
 
Comments?
 
/Shivaram

Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Shivaram,

Like you, I dislike the "unbounded" stuff. However, I'm not that
sure that simply punting to wsdl is entirely right here, for the
following reasons:

- Does wsdl define the error handling for such cases? If not then
we'll have to.
- The way that schemas (incl. ours) tend to work is that you don't
know you're going to hit the limit in advance, that is, there's
no "numberOfChildren" attribute in a parent element, so it'd
probably be v. hard for anything but an xkms "layer" to detect
that there are too many elements (and we've a lot of occurrences
of "unbounded" in the schema).
- People who are coding using xml libraries of various sorts may
inherit either limitations or else the inability to enforce
limits, either way there might be an issue.
- Given that "unbounded" is IMO effectively a DoS vulnerability,
there are (system, not crypto) security reasons for us to
think about this ourselves, e.g. an open responder could be
pelted with huge register requests.
- Lastly, I don't know what the coders we've got have done.

So I'd suggest a bit more thought on this before we figure out
what (if any!) fixes/clarifications etc. starting with the coders
telling us what their code does, specifically:

- Are all occurrences of "unbounded" handled the same?
- Does you code have any configured/hard-coded limits on any of
these, and if so, would you like to tell us more?
- Is it easy or hard for your code (or some other "layer") to
enforce any limit?
- How'd your code react to crazy xkms messages with millions of
elements?
- Your fav. suggestion for handling this?

Stephen.


Shivaram Mysore wrote:
> I have updated the spec on my side to make these changes:
> 
> 1. Issue TBD: Fixed Para 86 - inserted "A collection of d" in the
> OpaqueClientData [Optional] section
> 2. Issue TBD: Fixed Para 94: inserted ", including its children," to
> clarify further
> 
> I felt that the fix to para 94 was not necessary, but, as it is 
> confusing to a few folks, it does not hurt to add the phrase. 
> 
> One other item that I am thinking of adding to the specification is:
> 
> "For elements that have maxOccurs="unbounded", implementations can 
> define WSDLs for that kind of a service which restrict the maxOccurs 
> value to a finite value."
> 
> By doing this, we can keep the schema intact and the implementations can 
> scale.
> 
> 
> 
> /Shivaram
> 
> */tommy lindberg 
/* wrote:
> 
> 
> 
> Hi Stephen -
> 
> >(unless you want to suggest clearer text that'd help the next
> developer not
> >miss this)
> 
> It may be somewhat clearer (and consistent with the rest of the
> spec) if
> 'Section
> 3.1.4 Element ' also mentioned its child element
> stating that
> there is a 1-many relationship between the two.
> 
> Something like:
> 
> [94]The element contains data specified by the client
> that is opaque
> to the service. has the following element
> 
> [1..AnyNumber]
> Data specified by the client that is opaque to the service.
> 
> An XKMS service SHOULD return the element specified in
> a request, including
> its children, unmodified in the corresponding response.
> 
> The following adjustment to '3.1.1 Type MessageAbstractType' may al
> so be
> useful:
> 
> [Optional]
> A collection of data specified by the client that is opaque to the
> service.
> An XKMS service SHOULD return the content of the
> element unmodified
> in a response with status code Success.
> 
> Regards
> Tommy
> 
> >From: Stephen Farrell
> >To: tommy lindberg
> >CC: alvarorg@cs.tcd.ie, www-xkms@w3.org
> >Subject: Re: Opaque (Client) Data
> >Date: Wed, 01 Sep 2004 12:51:54 +0100
> >
> >
> >
> >Hi Tommy,
> >
> >Fine by me.
> >
> >So assuming no objections when those on the wrong^h^h^h^h^hother side
> >of the Atlantic and elsewhere wake up, there's nothing to do and no
> >need to open an issue (unless you want to suggest clearer text that'd
> >help the next developer not miss this).
> >
> >Cheers,
> >Stephen.
> >
> >tommy lindberg wrote:
> >
> >>
> >>I'd favor leaving the schema as is in this respect. I have fixed
> my code
> >>to handle the multiplicity correctly; not yet deployed.
> >>
> >>Regards,
> >>Tommy
> >>
> >>>From: Stephen Farrell
> >>>To: Guillermo Álvaro Rey
> >>>CC: www-xkms@w3.org
> >>>Subject: Re: Opaque (Client) Data
> >>>Date: Wed, 01 Sep 2004 12:06:19 +0100
> >>>
> >>>
> >>>
> >>>I could live with either interpretation, but slightly prefer
> >>>to allow >1 because:
> >>>
> >>>- its the current schema
> >>>- I think it might be easier for a client who's using field
> >>> to be able to easily add/find values (though this is a bit
> >>> tenuous, I admit)
> >>>
> >>>But I'm happy to change the schema if coders prefer to only
> >>>allow one OpaqueData to be present.
> >>>
> >>>I doubt that anyone's got a real use for >1 OpaqueData so far,
> >>>so this ought to be a safe enough change to make if you guys
> >>>want to do it (please yell if this is untrue).
> >>>
> >>>Cheers,
> >>>Stephen.
> >>>
> >>>Guillermo Álvaro Rey wrote:
> >>>
> >>>>Hi all,
> >>>>
> >>>>Following our client-server tests Tommy and myself were
> discussing about
> >>>>the number of OpaqueData elements that the specification
> *intend* to
> >>>>allow in an OpaqueClientData element.
> >>>>
> >>>>It seems that the way the schema currently stands multiple
> OpaqueData
> >>>>children are allowed for a OpaqueClientData element,
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>, but currently only the first one is handled by Tommy's
> implementation
> >>>>and so we would like to get confirmation that that's not the
> expected
> >>>>behaviour.
> >>>>
> >>>>Cheers,
> >>>>
> >>>> - -Guillermo
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >>_________________________________________________________________
> >>Tired of spam? Get advanced junk mail protection with MSN 8.
> >>http://join.msn.com/?page=features/junkmail
> >>
> >
> 
> _________________________________________________________________
> Add photos to your e-mail with MSN 8. Get 2 months FREE*.
> http://join.msn.com/?page=features/featuredemail
> 
> 
> __________________________________________________
> D o You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com