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

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: uri-review-bounces@ietf.org [mailto:uri-review-bounces@ietf.org] On
> Behalf Of Jan Pechanec
> Sent: Wednesday, August 21, 2013 11:27 PM
> To: uri-review@ietf.org
> Subject: Re: [Uri-review] percent encoding of '/' in one-segment non-
> hierarchical path component
> 
> 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 <jan.pechanec@oracle.com>
> _______________________________________________
> Uri-review mailing list
> Uri-review@ietf.org
> https://www.ietf.org/mailman/listinfo/uri-review