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

[Jan Pechanec <[e-mail]>]

On Mon, 11 Feb 2013, Ted Hardie wrote:

>Hi Jan,
>
>Some comments on a quick review:
>
>In the examples you use newlines to make things more readable, and I
>think that's
>reasonable, but your justification says:
>
>   Note that in some of the following examples,
>   newlines and spaces were inserted for better readability which is
>   allowed by [RFC3986].
>
>I think that's a bit confusing.  If I understand you, what you mean to 
>say is that the 3986 allows you to use newlines in example text, not 
>that it allows you to use newlines and spaces "for better readability" 
>in the actual URI.  Some re-wording may be in order.

	hi Ted, I agree it is confusing, thanks for bringing it up. I'd 
like to change it to:

   This section contains some examples of how PKCS#11 token objects,
   PKCS#11 tokens, and PKCS#11 libraries can be identified using the
   PKCS#11 URI scheme.  Note that in some of the following examples,
   newlines and spaces were inserted for better readability.  As
   specified in Appendix C of [RFC3986], whitespace should be ignored
   when extracting the URI.  Also note that all spaces as part of the
   URI are percent-encoded, as specified in Appendix A of [RFC3986].

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


	does it look OK to you?

	thanks a lot for your feedback.

	regards, Jan.

>
>regards,
>
>Ted Hardie
>
>On Fri, Feb 8, 2013 at 5:28 PM, Jan Pechanec <[e-mail]> wrote:
>> On Sat, 26 Jan 2013, Jan Pechanec wrote:
>>
>>         hi, the section 5.2 of RFC 4395 notes "Allow a reasonable time
>> for discussion and comments. Four weeks is reasonable for a permanent
>> registration requests."
>>
>>         I will wait for two more weeks if there is any feedback (which
>> would be greatly appreciated) to make it 4 weeks in total, and if there
>> is none I will continue with the next step, which is the submission to
>> [e-mail].
>>
>>         regards, Jan.
>>
>>>       hello,
>>>
>>>       in accordance with section "5.2. Registration Procedures" of RFC
>>>4395 "Guidelines and Registration Procedures for New URI Schemes", I
>>>respectfully request a review for our planned permanent registration
>>>request of the PKCS#11 URI as specified in the following I-D:
>>>
>>>       http://tools.ietf.org/html/draft-pechanec-pkcs11uri-08
>>>
>>>       the registration template is attached.
>>>
>>>       best regards, Jan Pechanec
>>>
>>>
>>
>> --
>> Jan Pechanec
>> http://blogs.oracle.com/janp
>> _______________________________________________
>> Uri-review mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/uri-review
>

-- 
Jan Pechanec <[e-mail]>