SRV Name: draft-ietf-pkix-srvsan-02.txt: typos, examples

["Manger, James H" <James.H.Manger@xxxxxxxxxxxxxxxx>]

Comments on draft-ietf-pkix-srvsan-02.txt


1. Abstract, page 1, typo:
  "filed" -> "field"


2. It would be nice if the full value of the id-on-dnsSRV object identifier was provided in this document, without requiring a separate lookup of RFC 3280. Add the following ASN.1 comment just above the id-on definition in Appendix A.1 (page 8), Appendix A.2 (page 8) and section 2 "Name Definitions" (page 3):
  -- id-pkix OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7}


3. Include an example with an IDN so it is immediately obvious that punycode is not used in an SRVName value.  Add the following after the current example in section 2, page 4:

  Example:
  The "mail" service at na<LATIN SMALL LETTER I WITH DIAERESIS>ve.net
  (an IDN, which becomes xn--nave-6pa.net when encoded as an IDNA)
  would use the following 15-character SRVName value:
    _mail.na<LATIN SMALL LETTER I WITH DIAERESIS>ve.net
  Its 16-byte UTF-8 encoding is (in hex):
    5F 6D 61 69 6C 2E 6E 61 C3 AF 76 65 2E 6E 65 74


4. Appendix A.2 (page 9), glitch:
  "permanentIdentifier" -> "srvName"


5. Why bother with the (SIZE (1..MAX)) restriction?  Delete it.


6. SRVName is defined (in section 2) to have the form _Service.Name.  The very next section violates that definition by allowing SRVName to hold just a service name or just a domain name.  The syntax to hold a name is not necessarily the same syntax required to hold a matching rule for that name.  This is a general fault with the construction of the nameConstraints extension so it does not need to be fixed in this specification (I am just having a rant).


7. Appendix A, page 7:
  "augmented with 1993 the UNIVERSAL Type" ->
  "augmented with the 1993 UNIVERSAL Type"


8. Appendix A.  Are the modules names supposed to end with "..SAN88" and "..SAN93", or is it supposed to be "..ASN88" and "..ASN93"?


-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Internet-Drafts@xxxxxxxx
Sent: Friday, 23 June 2006 8:50 AM
To: i-d-announce@xxxxxxxx
Cc: ietf-pkix@xxxxxxx
Subject: I-D ACTION:draft-ietf-pkix-srvsan-02.txt 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Subject Alternative Name for expression of service name
	Author(s)	: S. Santesson
	Filename	: draft-ietf-pkix-srvsan-02.txt
	Pages		: 11
	Date		: 2006-6-22
	
This document defines a new name form for inclusion in the otherName
filed of an X.509 Subject Alternative Name extension which allows a
certificate subject to be associated with the service name and domain
name components of a DNS Service Resource Record.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-srvsan-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-srvsan-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@xxxxxxxxx
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-srvsan-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.