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

Stephen,

My client code is treating unbounded items with lists so I am able to
send a "reasonable" number of requests in a compound, for example, or
handle a "reasonable" number of key bindings in the same result message.

As we were discussing it will be trickier for servers having to handle
"crazy million-elements-requests". Unfortunately I don't have the fav.
suggestion... (yet?;)

Nice weekend,
 - -Guillermo


El jue, 02-09-2004 a las 11:49, Stephen Farrell escribió:
> 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 Friday, 3 September 2004 18:49:50 UTC