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

Jan Pechanec <jan.pechanec@oracle.com> Thu, 21 February 2013 05:34 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 68D1C21E809D for <uri-review@ietfa.amsl.com>; Wed, 20 Feb 2013 21:34:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.598
X-Spam-Level:
X-Spam-Status: No, score=-7.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 rxBxCnyyWAaR for <uri-review@ietfa.amsl.com>; Wed, 20 Feb 2013 21:34:11 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 54D0D21E809B for <uri-review@ietf.org>; Wed, 20 Feb 2013 21:34:08 -0800 (PST)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1L5Y40D026312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Feb 2013 05:34:05 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1L5Y4mg012411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2013 05:34:04 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1L5Y3E2018415; Wed, 20 Feb 2013 23:34:03 -0600
Received: from rejewski.us.oracle.com (/10.132.148.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 20 Feb 2013 21:34:03 -0800
Date: Wed, 20 Feb 2013 21:35:17 -0800 (PST)
From: Jan Pechanec <jan.pechanec@oracle.com>
X-X-Sender: jpechane@rejewski
To: Larry Masinter <masinter@adobe.com>
In-Reply-To: <C68CB012D9182D408CED7B884F441D4D1E87D75AA6@nambxv01a.corp.adobe.com>
Message-ID: <alpine.GSO.2.00.1302202021070.122859@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> <C68CB012D9182D408CED7B884F441D4D1E87D75AA6@nambxv01a.corp.adobe.com>
User-Agent: Alpine 2.00 (GSO 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Darren.Moffat@oracle.com" <Darren.Moffat@oracle.com>, Ted Hardie <ted.ietf@gmail.com>, "uri-review@ietf.org" <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: Thu, 21 Feb 2013 05:34:12 -0000

On Mon, 18 Feb 2013, Larry Masinter wrote:

>in this case, it seems like there's some expectation that you WILL 
>compare the URIs, so it would be useful to say.
>
>And the design should make it easy.

	hello Larry, after I tried to put together the rules I agree it 
will be useful. I suggest to add the following section to the draft:


3.4.  PKCS#11 URI Comparison

   Comparison of two URIs is a way of determining whether the URIs are
   equivalent without comparing the actual resource the URIs point to.
   The comparison of URIs aims to minimize false negatives while
   strictly avoiding false positives.

   Two PKCS#11 URIs are said to be equal if URIs as character strings
   are identical as specified in Section 6.2.1 of [RFC3986], or if both
   following rules are fulfilled:

   o  set of attributes present in the URI is equal.  Note that the
      ordering of attributes in the URI string is not significant for
      the mechanism of comparison.

   o  values of respective attributes are equal based on rules specified
      below

   The rules for comparing values of respective attributes are:

   o  values of attributes "token", "manufacturer", "serial", "model",
      "library-manufacturer", "library-description", "object", and
      "object-type" must be compared using simple string comparison
      (Section 6.2.1 of [RFC3986]) after the case and the percent-
      encoding normalization are both applied as specified in Section
      6.2.2 of [RFC3986]

   o  value of attribute "id" must be compared using simple string
      comparison after all bytes are percent-encoded using uppercase
      letters for digits A-F

   o  value for attribute "pin-source", if deemed containing the
      filename with the PIN value, must be compared using the simple
      string comparison after the full syntax based normalization as
      specified in Section 6.2.2 of [RFC3986] is applied.  If value of
      the "pin-source" attribute is believed to be overloaded it is
      recommended to perform case and percent-encoding normalization
      before the values are compared but the exact mechanism of
      comparison is left to the application.

   o  value of attribute "library-version" must be processed as a
      specific scheme-based normalization permitted by Section 6.2.3 of
      [RFC3986].  Each value must be split into a major and minor
      version with character "." (dot) serving as a delimiter.  Library
      version "M" must be treated as "M" for the major version and "0"
      for the minor version.  Library version ".N" must be treated as
      "0" for the major version and "N" for the minor version.
      Resulting minor and major version numbers must be then separately
      compared numerically.


	regards, Jan

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