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

[Jan Pechanec <[e-mail]>]

On Sat, 24 Aug 2013, Larry Masinter wrote:

	hi Larry,

	thank you for your answer.  Comments inline.

>If you would like your URIs to be parsable by generic URI parsing,
>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?

>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

	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.

>or even
>
>pkcs11:/my-key?object-type=private;pin-source=/etc/pin
>(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


>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Jan Pechanec
>> Sent: Wednesday, August 21, 2013 11:27 PM
>> To: [e-mail]
>> 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 <[e-mail]>
>> _______________________________________________
>> Uri-review mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/uri-review
>

-- 
Jan Pechanec <[e-mail]>