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

[Jan Pechanec <[e-mail]>]

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 <[e-mail]>