Re: Query parameter separator value

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