Re: CR117 Option 1

Jacek Kopecky <[email protected]>
Newsgroups gmane.comp.web.services.description
Message-ID <1170941878.26473.17.camel@localhost>
Jonathan, is it your intention here that an encoded parameter in the
path can still contain multiple path segments ('/') or even start the
query string ('?')?

Shouldn't / and ? be unencoded in the query, and encoded in the path?
Indeed, RFC3986 allows / and ? to be unencoded in the query. This would
be opposite to what you have.

Jacek

On Wed, 2007-02-07 at 13:57 -0800, Jonathan Marsh wrote:
> Remove the text in 6.7.1.1 that reads:
> 
>  
> 
> No percent-encoding mechanism, as defined in section 2.1 of RFC 3986,
> is performed on the replacement value.
> 
>  
> 
> Add to the bullet list in 6.7.1.1:
> 
>  
> 
> Ā·        A template whose element name is preceded by the character
> ā€œ~ā€ is replaced by the corresponding XML element value without
> additional %-encoding performed.  Otherwise: 
> 
>  
> 
> A template preceded in the {http location} by a ā€œ?ā€ or ā€œ#ā€ character,
> or an uncited parameter, is encoded as follows:  Any character in the
> XML value falling outside the range ALPHA | DIGIT | "-" | "." | "_" |
> "~" | "!" | "$" | "&" | "'" | "(" | ")" | "*" | "+" | "," | ";" | "="
> | ā€œ:ā€ | ā€œ@ā€ MUST be %-encoded.  
> 
>  
> 
> A template not preceded in the {http location} by a ā€œ?ā€ or ā€œ#ā€
> character is encoded as follows:  Any character in the XML value
> falling outside the range ALPHA | DIGIT | "-" | "." | "_" | "~" | "!"
> | "$" | "&" | "'" | "(" | ")" | "*" | "+" | "," | ";" | "=" | ā€œ:ā€ |
> ā€œ@ā€ | ā€œ?ā€ | ā€œ/ā€ MUST be %-encoded.
> 
>  
> 
> %-encoding MUST be performed using the UTF-8 representation of the
> character as prescribed by section 6.4 of [IRIs].
> 
>  
> 
> Add to the bullet list in 6.7.2.2.1:
> 
> Ā·        Parameter values falling outside the range ALPHA | DIGIT |
> "-" | "." | "_" | "~" | "!" | "$" | "&" | "'" | "(" | ")" | "*" | "+"
> | "," | ";" | "=" | ā€œ:ā€ | ā€œ@ā€ MUST be %-encoded.  %-encoding MUST be
> performed using the UTF-8 representation of the character as
> prescribed by section 6.4 of [IRIs].
> 
>  
> 
> Change the BNF (wherever we decided to stick it) to:
> 
>  
> 
> httpLocation ::= CharData? (( openBrace | closeBrace | elementName )
> CharData?)*
> 
>  
> 
> CharData ::= [^{}]*
> 
>  
> 
> openBrace ::= '{{'
> 
>  
> 
> closeBrace ::= '}}'
> 
>  
> 
> elementName ::= rawElementName | encodedElementName
> 
>  
> 
> rawElementName ::= '{~' NCName '}'
> 
>  
> 
> encodedElementName ::= '{' NCName '}'
> 
>  
> 
>  
> 
>  
> 
> Notes on this proposal:
> 
>  
> 
> 1) This will no doubt require editorial license, For instance, see
> Philippe’s proposal for changed text for 6.7.1.1 at
> http://lists.w3.org/Archives/Public/www-ws-desc/2006Sep/0034.
> 
>  
> 
> 2) From rfc3986, within the query part or fragment the following
> characters may appear without %-escaping:
> 
>  
> 
> ALPHA | DIGIT | "-" | "." | "_" | "~" | "!" | "$" | "&" | "'" | "(" |
> ")" | "*" | "+" | "," | ";" | "=" | ā€œ:ā€ | ā€œ@ā€ | ā€œ/ā€ | ā€œ?ā€
> 
>  
> 
> 3) From rfc3986, Within a path part the following characters may
> appear without %-escaping:
> 
>  
> 
> ALPHA | DIGIT | "-" | "." | "_" | "~" | "!" | "$" | "&" | "'" | "(" |
> ")" | "*" | "+" | "," | ";" | "=" | ā€œ:ā€ | ā€œ@ā€
> 
>  
> 
> 4) Over-encoding of parameter values (encoding ā€œ/ā€ and ā€œ?ā€ even though
> it’s not necessary) is a possible simplification.
> 
>  
> 
> 5) I don’t think it makes sense escaping something other than a path
> part, query parameter, or fragment, so I’m not considering specialized
> escaping in those places.
> 
>  
> 
> 6) I believe that the encoding, and determination of whether the
> template appears in the query parameter/fragment or somewhere else,
> can be made independently of resolving the reference against the
> {address}.  Someone might want to double check this belief.
> 
>  
> 
>  
> 
> Jonathan Marsh - http://www.wso2.com -
> http://auburnmarshes.spaces.live.com
> 
>  
> 
>  
> 
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.