Comments from Steve Kent on String repr. of DN

Erik Huizer <Erik.Huizer@surfnet.nl> Wed, 11 November 1992 18:26 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07888; 11 Nov 92 13:26 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07884; 11 Nov 92 13:26 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa12428; 11 Nov 92 13:27 EST
X400-Received: by mta haig.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Wed, 11 Nov 1992 16:34:41 +0000
Date: Wed, 11 Nov 1992 16:34:41 +0000
X400-Originator: osi-ds-request@cs.ucl.ac.uk
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=uk.ac/ADMD=gold 400/C=gb/; haig.cs.uc.646:11.10.92.16.34.41]
Priority: Non-Urgent
DL-Expansion-History: osi-ds@cs.ucl.ac.uk ; Wed, 11 Nov 1992 16:34:41 +0000;
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Erik Huizer <Erik.Huizer@surfnet.nl>
Message-ID: <"survis.sur.913:11.10.92.16.33.21"@surfnet.nl>
To: RARE & IETF OSI-DS wg <osi-ds@cs.ucl.ac.uk>
Subject: Comments from Steve Kent on String repr. of DN
Organisation: SURFnet bv
Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL
Phone: +31 30 310290
Telefax: +31 30 340903

I already replied to Steve Kent on this. I will report in the OSI-DS
session next monday.

Erik

------- Forwarded Message

Date:    Mon, 09 Nov 92 22:46:27 -0500
From:    Steve Kent <kent@bbn.com>
To:      Erik Huizer <Erik.Huizer@surfnet.nl>
cc:      Greg Vaudreuil <gvaudre@CNRI.Reston.VA.US>US>, 
	 Internet Engineering Steering Group <iesg@IETF.CNRI.Reston.VA.US>US>, 
	 iesg-tech@CNRI.Reston.VA.US, kent@bbn.com
Subject: Re: Agenda for the November 9th Teleconference

Erik,

	I have comments on this proposal, but am having trouble
getting them off my power book (out of MS Wrod) and in the mail.  The
gist if the comments (which were interleaved with the I-D text) is as
follows:

	- I think the set of examples should be expanded to illustrate
	representation of DNs with a multi-component RDN (this
	situation is mentioned in the text and the syntax, but is
	never illustrated)

	- I think it would be preferable for the character strings that
	represent the attribute types were registered by the IANA, to
	allow for orderly extension of the set, rather than just local
	extensions

	- The alternative approach cited here is not recommended, and
	conflicts with the recommended approach, so why is it included?
	I don't see any justification for this in the document.  If one
	includes such a contrasting apporoach, and does not recommend it,
	then I think it deserves some rationale.

Steve 

------- End of Forwarded Message