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

From: Jan Pechanec <[email-masked]>
Date: Tue, 13 Aug 2013 17:50:43 -0700 (PDT)

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 <[email-masked]>

---

From: Jan Pechanec <[email-masked]>
Date: Wed, 21 Aug 2013 14:27:14 -0700 (PDT)

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.

---

From: Larry Masinter <[email-masked]>
Date: Sat, 24 Aug 2013 19:11:13 -0700

If you would like your URIs to be parsable by generic URI parsing,
then they need to follow the generic URI syntax.   

Since  the URI consists of attribute value pairs why not just make the
whole thing a query string, by starting off with ?

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

or even

pkcs11:/my-key?object-type=private;pin-source=/etc/pin
(make one value, e.g., 'object',  be the path)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jan Pechanec
> Sent: Wednesday, August 21, 2013 11:27 PM
> To: [email-masked]
> Subject: Re: [Uri-review] percent encoding of '/' in one-segment non-
> hierarchical path component
> 
> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review

---

From: Jan Pechanec <[email-masked]>
Date: Mon, 26 Aug 2013 23:05:11 -0700 (PDT)

On Sat, 24 Aug 2013, Larry Masinter wrote:

	hi Larry,

	thank you for your answer.  Comments inline.

>then they need to follow the generic URI syntax.   

	yes, I'd like that.  I assume all URI schemes should be 
correctly parsable by generic URI parsers, shouldn't they?

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

	I understand why you suggest it but I think it would make it 
harder for people to use it.  They would just not understand.  Also, the 
PKCS#11 token provides flat space which can be seen as one level 
hierarchy so that's why I used the path.

>(make one value, e.g., 'object',  be the path)

	there are more attributes that could be used as path, "id" which 
is supposed to be unique.  However, I can see the point.

	all attributes can be used to identify the object in the one 
level hierarchy aside from the "pin-source" attribute.  That one may be 
needed to access the object but it does not define its location.  That 
one would fit into the query component and that's the one I had issues 
with about the slashes.

	the following might be an option:

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

	I have to think about it more.  Thanks!

	Jan

---

From: Larry Masinter <[email-masked]>
Date: Tue, 27 Aug 2013 12:29:15 -0700

> correctly parsable by generic URI parsers, shouldn't they?

I meant "parsable usefully". Trivially, you can turn any string into 
a private "scheme specific part". "data:" and "urn:" aren't usefully
parsed into the generic URI syntax, since they don't use
//, /, ? as delimiters.   so your syntax will "work", you just wouldn't
use the generic parser's ability to tease out an attribute value list
from a syntax delimited with ?a=b&c=d&e=f