- From: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>
- Date: Mon, 26 Feb 2007 10:27:39 +0100
- To: Youenn Fablet <youenn.fablet@crf.canon.fr>
- Cc: Jonathan Marsh <jonathan@wso2.com>, "'www-ws-desc'" <www-ws-desc@w3.org>
Probably if we added httpQueryParameterSeparator in the first place, we should not remove too many characters from the allowed list. Two remarks: 1. I think we should add (in the spec) a reference to RFC2234; currently ALPHA and DIGIT (in the spec) are ill-defined (currently defined according to common sense only). 2. Would it make sense to replace the reference to "ISO/IEC 14977" (EBNF) by that, ligtherweight, of RFC2234 (ABNF)? JJ. Youenn Fablet wrote: > Jonathan Marsh wrote: >> The list of characters allowed [1] in a query (where the {http query >> parameter separator} is utilized) is: >> >> query = *( pchar / "/" / "?" ) >> pchar = unreserved / pct-encoded / sub-delims / ":" / "@" >> unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" >> pct-encoded = "%" HEXDIG HEXDIG >> sub-delims = "!" / "$" / "&" / "'" / "(" / ")" >> > sub-delims also contains: "*" / "+" / "," / ";" / "=" > "=" seems not right to me as it is already used to separate the > parameter name from the parameter value. > I am not quite sure about the implications with "+". > >> Compiling that down and factoring out % (which can't appear as a single >> character without causing damage) we get: >> >> ALPHA / DIGIT / "-" / "." / "_" / "~" / "!" / "$" / "&" / "'" / >> "(" / ")" / ":" / "@" / "/" / "?" >> > Adding at least "," and "*" might be a good idea. > I am wondering whether "+" is a practical choice but it may be safer > to include it. > Otherwise, this list sounds good to me in the wsdl schema. > >> I assume these are the query parameter separators that can be used >> effectively. If we were to restrict the value space of the >> queryParameterSeparater attribute that's the list I would start with. >> >> ALPHA and DIGIT would be the first things I'd dump from the list, but >> I'm >> not sure I want to start going down the path of deciding which of the >> allowed characters are really useful. >> > +1 > A half-way solution would be, in addition to the schema tightening, to > state that '&' and ';' are the most natural/used/interoperable options. > > > >> BTW, I recorded this as issue CR156 [1]. >> >> [1] http://www.ietf.org/rfc/rfc3986.txt >> [2] http://www.w3.org/2002/ws/desc/5/cr-issues/#CR156 >> >> Jonathan Marsh - http://www.wso2.com - >> http://auburnmarshes.spaces.live.com >> >> >> >>> -----Original Message----- >>> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On >>> Behalf Of Jean-Jacques Moreau >>> Sent: Wednesday, February 21, 2007 7:41 AM >>> To: Youenn Fablet >>> Cc: www-ws-desc >>> Subject: Re: Query parameter separator value >>> >>> >>> Option 2 would be to add an assertion that the instance data MUST NOT >>> contain the queryParameterSeparator. >>> >>> JJ. >>> >>> Youenn Fablet wrote: >>> >>>> Reading the specification, it seems that the only constraint on the >>>> separator value is to be a xml string of length 1. >>>> It would therefore be possible to have a separator value that needs to >>>> be %-encoded in the URL (e.g. queryParameterSeparator="é"). >>>> I do not know whether that was intended but in this case, the query >>>> string may become ambiguous: if the separator value appears in a >>>> parameter value, it will be %-encoded exactly like the separator >>>> value. It might be safer to restrict the separator value range. >>>> >>>> In any case, the most sensible values are '&' and ';'. Is there any >>>> other obvious possibility? >>>> While '&' is the default value, ';' does not appear AFAIKT neither in >>>> the spec nor in the primer. >>>> It might therefore be good to add a statement that tells a word about >>>> these values, maybe as a SHOULD. >>>> Regards, >>>> Youenn >>>> >>>> >>>> >>>> >> >> >> >> >
Received on Monday, 26 February 2007 09:28:12 UTC