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

[Jan Pechanec <[e-mail]>]

	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]>