Re: [Uri-review] percent encoding of '/' in one-segment non-hierarchical path component

[Jan Pechanec <[e-mail]>]

On Tue, 13 Aug 2013, Jan Pechanec wrote:

	hi all, I'd very much appreciate any opinion on the problem I 
outlined below.  As I mentioned in the second part of my email, I'm 
inclined to allow PKCS#11 URIs to use unencoded '/' in attribute values:

	pkcs11:object=my-key;object-type=private;pin-source=/etc/pin

	despite the fact that it would fool generic URI parsers that 
would be splitting the one-segment path into three separate segments.  
I still have doubts about it though.

	thank you, Jan.


>	hi experts,
>
>	I've recently asked here for your opinion on the PKCS#11 URI 
>draft.  With your review help which I very much appreciated, the scheme 
>was recently approved as a provisional scheme and I'm getting ready to 
>put it on RFC tracker.
>
>	however, there is one thing I'm not sure about and I'd like to 
>ask for your opinion.  The following is an example of a pkcs11 URI:
>
>	pkcs11:object=my-key;object-type=private;pin-source=%2Fetc%2Fpin
>
>	now, I have the following paragraph in my draft:
>
>   ...
>   More specifically, '/' delimiter of generic URI components was
>   removed from available characters that do not have to be percent-
>   encoded so that the initial part of a PKCS#11 URI is never confused
>   with "path-rootless" part of the "hier-part" generic URI component as
>   defined in Section 3 of [RFC3986].
>   ...
>
>	which is not entirely precise (I should also include 
>"path-noscheme", too) and should be rephrased.  Basically what I want to 
>say is that the scheme requires encoding of '/' so that generic URI 
>parsers do not split the path into segments and parse the URI above as:
>
>	scheme name:	pkcs11
>	path-segment-1:	object=my-key;object-type=private;pin-source=
>	path-segment-2:	etc
>	path-segment-3:	pin
>
>	I could easily fix the draft but I'm still wondering whether:
>
>	(1) '/' is really needed to be removed from a charset that does 
>NOT have to be percent-encoded
>
>	(2) to allow non-encoded '/' and mention that if '/' are not 
>percent encoded the generic URI parser may split the intended 
>non-hierarchical one-segment path (ie. set of attributes) into multiple 
>segments
>
>	(3) to allow non-encoded '/' and does not discuss the generic 
>parser issues
>
>	it's easy to guess that people will use unencoded slashes in the 
>pin-source attribute no matter what I do and that PKCS#11 URI parsers 
>will have to accept it.  Choosing (1) then seems a bit useless to me.  
>I'm leaning to (2) but I'm not sure it's permissible to do that.
>
>	I'm reading rfc3986 again.  "2.2. Reserved Characters" suggests 
>that since '/' is not a delimiter in the PKCS#11 URI, it does not have 
>to be percent encoded.  Also, the next paragraph also under 2.2 makes me 
>think that (2) might be really a good solution since '/' can be part of 
>the pin-source attribute data:
>
>   ...
>   URI producing applications should percent-encode data octets that
>   correspond to characters in the reserved set unless these characters
>   are specifically allowed by the URI scheme to represent data in that
>   component. 
>   ...
>
>	however, I'm really not sure and still thinking about generic 
>parsers splitting the path into multiple segments.  I'm hoping you could 
>help me with some insight.
>
>	best regards, Jan.
>
>

-- 
Jan Pechanec <[e-mail]>