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

Jan Pechanec <jan.pechanec@oracle.com> Thu, 14 February 2013 07:24 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 EC2AF21F84EB for <uri-review@ietfa.amsl.com>; Wed, 13 Feb 2013 23:24:56 -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=[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 kNo-s-poVTIm for <uri-review@ietfa.amsl.com>; Wed, 13 Feb 2013 23:24:56 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 56C4F21F84EA for <uri-review@ietf.org>; Wed, 13 Feb 2013 23:24:56 -0800 (PST)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1E7Or75010333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Feb 2013 07:24:54 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 r1E7Or9Y020173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Feb 2013 07:24:53 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1E7OrMe025454; Thu, 14 Feb 2013 01:24:53 -0600
Received: from rejewski.us.oracle.com (/10.132.148.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 13 Feb 2013 23:24:53 -0800
Date: Wed, 13 Feb 2013 23:26:01 -0800 (PST)
From: Jan Pechanec <jan.pechanec@oracle.com>
X-X-Sender: jpechane@rejewski
To: Ted Hardie <ted.ietf@gmail.com>
In-Reply-To: <CA+9kkMADpWzDk5gnRLoq6+_pHwJSjyOUsOgpJa9D6t73_45eyw@mail.gmail.com>
Message-ID: <alpine.GSO.2.00.1302132246380.16175@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>
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: Thu, 14 Feb 2013 07:24:57 -0000

On Wed, 13 Feb 2013, Ted Hardie wrote:

	hello Ted,

>>>I also believe you may wish to make explicit statements about where on
>>>the 3986 ladder of comparison you intend for these attribute-value
>>>pairs to fall.  As it stands, some of the text about Library version
>>>indicates that you expect a semantic comparison, but it is usual in
>>>cryptographic contexts to require something that has much less wiggle
>>>room.  Explicit text on this would help the reader understand what it
>>>is expected
>>
>>         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).

	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>;