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

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 <lindberg_tommy@hotmail.com>/* 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
>

Received on Thursday, 2 September 2004 10:48:04 UTC