Re: [Uri-review] PKCS#11 URI registration request review

Jan Pechanec <jan.pechanec@oracle.com> Sun, 17 February 2013 21:01 UTC

Return-Path: <jan.pechanec@oracle.com>
X-Original-To: uri-review@ietfa.amsl.com
Delivered-To: uri-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8B121F8B3F for <uri-review@ietfa.amsl.com>; Sun, 17 Feb 2013 13:01:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVJzLTzg1nzS for <uri-review@ietfa.amsl.com>; Sun, 17 Feb 2013 13:01:43 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB5C21E8039 for <uri-review@ietf.org>; Sun, 17 Feb 2013 13:01:43 -0800 (PST)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1HL1dN7001393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 17 Feb 2013 21:01:39 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1HL1cpJ027040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Feb 2013 21:01:39 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1HL1cFt000936; Sun, 17 Feb 2013 15:01:38 -0600
Received: from rejewski.us.oracle.com (/10.132.148.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 17 Feb 2013 13:01:38 -0800
Date: Sun, 17 Feb 2013 13:02:49 -0800 (PST)
From: Jan Pechanec <jan.pechanec@oracle.com>
X-X-Sender: jpechane@rejewski
To: Ted Hardie <ted.ietf@gmail.com>
In-Reply-To: <alpine.GSO.2.00.1302132246380.16175@rejewski>
Message-ID: <alpine.GSO.2.00.1302171247410.115756@rejewski>
References: <alpine.GSO.2.00.1301261430001.28908@rejewski> <alpine.GSO.2.00.1302081722560.7401@rejewski> <CA+9kkMB2W9zZBuWvZmPE0aNf6NX_fbG6Fzx0R71QDQB9YNPamA@mail.gmail.com> <alpine.GSO.2.00.1302122349180.14210@rejewski> <CA+9kkMADpWzDk5gnRLoq6+_pHwJSjyOUsOgpJa9D6t73_45eyw@mail.gmail.com> <alpine.GSO.2.00.1302132246380.16175@rejewski>
User-Agent: Alpine 2.00 (GSO 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Darren.Moffat@oracle.com, uri-review@ietf.org
Subject: Re: [Uri-review] PKCS#11 URI registration request review
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uri-review>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Feb 2013 21:01:44 -0000

On Wed, 13 Feb 2013, Jan Pechanec wrote:

>>>         it sounds very reasonable and I'd like to add a new paragraph at
>>> the end of Section 3:
>>>
>>>    As ordering of attributes in the PKCS#11 URI is not significant,
>>>    comparison of URIs should be performed on a per-attribute basis after
>>>    the URI itself is normalized as explained in Section 6 of [RFC3986].
>>>    Caution should excercised when comparing the "id" attributes as their
>>>    values may not be fully percent-encoded.  Library version ".N" should
>>>    be interpreted as "0" for the major and "N" for the minor version of
>>>    the library.  Library version "M" should be interpreted as "M" for
>>>    the major and "0" for the minor version of the library.
>>>
>>So, I think you are mixing the comparison of the values encoded in the
>>URI with the comparison of the URI itself.  If the typical mode of
>>employment is to deconstruct the URI into a set of attribute/value
>>pairs, it's fine for the using application to treat the result as
>>unordered.  But this may mean that there is no reasonable comparison
>>to be done here at the URI level.  You can be sure that two URIs match
>>if they are bit-for-bit identical, but there are lots of other
>>conditions in which they *may* be equivalent.
>>
>>Do you expect people to actually compare at the URI level at all?
>
>	no, I don't expect that. I have checked some recent RFCs
>defining URIs and it seems to me that those that do not expect to be
>compared do not deal with comparison at all (for example, "mailto" and
>"tn3270" RFCs).

	hi Ted, after putting some more thought to it, given that we do 
not expect PKCS#11 URIs to be compared, I just extended the last 
paragraph of the section "3.3.  PKCS#11 URI Scheme Syntax" on the 
information how to interpret values for the library-version attribute:

<t>It is recommended to percent-encode the whole value of the "id"
attribute which is supposed to be handled as arbitrary binary data.
Value "M" of the "library-version" attribute should be interpreted as
"M" for the major and "0" for the minor version of the library.
Library version ".N" should be interpreted as "0" for the major and
"N" for the minor version of the library.</t>

	please let me know if that is not enough. If comparison is still 
needed, additional information on comparison ladder from RFC 3986 should 
be enough since no other attribute values are special and the section in 
RFC 3986 covers it.

	regards, Jan

>	my intention above was that if I specify how to compare URIs
>then it also specifies how to compare values, too. I understand that's
>probably not the best way to do it. On the other hand, we don't know how
>PKCS#11 URI might be used so it may be worth to specify that.
>
>	I'm not sure what would be the best here. I could just take the
>explanation of how library-version value should be read and move it out
>of the Example section, or I could put together a small section on URI
>comparison, explicitly stating how to do that (as in RFC 5870 on geo
>URI, for example).
>
>	would you suggest me to write a section on comparision of URIs
>when we don't expect people to do it?
>
>	regards, Jan.
>
>

--
Jan Pechanec <jan.pechanec@oracle.com>;