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

Ted Hardie <ted.ietf@gmail.com> Tue, 19 February 2013 19:32 UTC

Return-Path: <ted.ietf@gmail.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 49F9521E80AF for <uri-review@ietfa.amsl.com>; Tue, 19 Feb 2013 11:32:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.567
X-Spam-Level:
X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, NO_RELAYS=-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 pk4+3py3MguM for <uri-review@ietfa.amsl.com>; Tue, 19 Feb 2013 11:32:50 -0800 (PST)
Received: from mail-ia0-x22b.google.com (mail-ia0-x22b.google.com [IPv6:2607:f8b0:4001:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5281921E8064 for <uri-review@ietf.org>; Tue, 19 Feb 2013 11:32:50 -0800 (PST)
Received: by mail-ia0-f171.google.com with SMTP id z13so6444726iaz.2 for <uri-review@ietf.org>; Tue, 19 Feb 2013 11:32:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=iZCHUuiTTpu1dSQ0uKe+or9gA6ZT4oUJLz7PTvyj234=; b=JMCIOedmN7TvfmVPrqUAaH/8u+4YUErTg2/ra/zK7sfkG5VsV8nHOtJBkGs7FLOK5o u+ZoMGAIABMimc/7H6NFjxJGelCj40q1bJFKLlJqx0tJ7YHIL8zNRyBXTwoWY6tlAjM9 XaHoXiIgHsgFRAH1X7wK/HiQuCf+vfkp7h2v6Whcp97z9n9RXZ0K1CjuUeoEvtHSERU5 mF0NT1A1EvjZ2dZGy0jB7hm9IFENp5JcdScFJU5mKhhpSj7AwuhcFUGgDMQrhhby+ASm Fqo9rDc55bfSOEARyAQVIKkdwNYlEA/wlTPETkRYWnDZThxBpMtQCTBFrOrs5wqBmf77 QnVQ==
MIME-Version: 1.0
X-Received: by 10.42.48.147 with SMTP id s19mr7987150icf.18.1361302369940; Tue, 19 Feb 2013 11:32:49 -0800 (PST)
Received: by 10.43.135.202 with HTTP; Tue, 19 Feb 2013 11:32:49 -0800 (PST)
In-Reply-To: <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> <alpine.GSO.2.00.1302132246380.16175@rejewski>
Date: Tue, 19 Feb 2013 11:32:49 -0800
Message-ID: <CA+9kkMC1YqRHjHVw8C23T_FjvykQbFEPXnXgBczEe9J18Uw9Bg@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Jan Pechanec <jan.pechanec@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1
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: Tue, 19 Feb 2013 19:32:51 -0000

On Wed, Feb 13, 2013 at 11:26 PM, Jan Pechanec <jan.pechanec@oracle.com>; wrote:
>         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 think the safest thing to do is to specify a conservative comparison at the
URI registration level (like bit-for-bit equality) but note that
applications consuming
them will likely use different comparison algorithms once the values have
been pulled from the URI for use.

Just a personal opinion, though; I'm not sure that there is a single
right answer here.

regards,

Ted

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