LDAP Syntaxes draft issues

Erik Huizer <Erik.Huizer@surfnet.nl> Fri, 16 April 1993 09:31 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01430; 16 Apr 93 5:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01426; 16 Apr 93 5:31 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa06104; 16 Apr 93 5:31 EDT
X400-Received: by mta haig.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Fri, 16 Apr 1993 08:58:56 +0100
Date: Fri, 16 Apr 1993 08:58:56 +0100
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.427:16.03.93.07.58.56]
Priority: Non-Urgent
DL-Expansion-History: osi-ds@cs.ucl.ac.uk ; Fri, 16 Apr 1993 08:58:56 +0100;
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Erik Huizer <Erik.Huizer@surfnet.nl>
Message-ID: <"survis.sur.730:15.03.93.15.00.12"@surfnet.nl>
To: RARE & IETF OSI-DS wg <osi-ds@cs.ucl.ac.uk>
Subject: LDAP Syntaxes draft issues
Organisation: SURFnet bv
Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL
Phone: +31 30 310290
Telefax: +31 30 340903

Since the drafts I have did not include the addresses of the authors I
am sending this to the whole list. I hope Colin, Steve, Tim and
Wengyik will react appropriately.

Here are questions from the RFC-editor on the draft and a first
reaction from mtr, which suggests solutions.

Erik
---------
Date: Tue, 13 Apr 1993 11:27:54 -0700
Sender: iesg-request@IETF.CNRI.Reston.VA.US
From: Jon Postel <postel@isi.edu>
Message-Id: <199304131827.AA23229@zephyr.isi.edu>
To: IESG@isi.edu
Subject: re: String Representation of Attribute Syntaxes
Cc: IAB@isi.edu, RFC-Editor@isi.edu


Dear IESG:

While looking over the memo "The String Representation of Standard
Attribute Syntaxes" (which ought to have "X.500" in the title someplace),
from the file <draft-ietf-osids-syntaxes-01.txt>, the RFC Editor noticed
a few curious points.

This memo is to be published as a proposed standard.  This specification
incorporates by reference some specification language from other sources.

1) A "Distinguished Name" [4.12] is as defined in OSI-DS Doc 23.  The RFC 
Editor detects this as a tricky reference to an Internet-Draft.

2) A "Presentation Address" [4.20] is defined in RFC 1278.  The RFC Editor
recallls that 1278 is for information only and not a standard, and that in
the old world order this was a matter of great discussion, with the IAB very
concerned that this not be on the standards track.

3) A "Photo" [4.33] is defined in terms of JPEG File Interchange Format,
but no reference is provided.

4) A "Fax" [4.34] is defined in terms of Group 3 Fax images, but no 
reference is provided.  (Would RFC 1314 be suitable ?)

5) There are a number a "security" related features, were these checked
by the security experts?  See 4.25 thru 4.29.

6) There may be something funny about the definition of <keystring>.  It
seems like it can start with a dash and include alphas and dashes but not
digits.

It seems to the RFC Editor that this document needs more work.

--jon.
--------------

--------------
Date: Tue, 13 Apr 1993 16:08:47 -0800 GMT
Sender: iesg-request@IETF.CNRI.Reston.VA.US
From: Marshall Rose (via RadioMail) <mrose@dbc.mtview.ca.us>
Subject: string rep. of AS
To: rfc-editor@isi.edu
Cc: iesg@CNRI.Reston.VA.US, iab@isi.edu

jon - I was not involved w/ the review of this I-D, but after reading it on
the plane (where I am keying this response), I have the following comments:

1. DN syntax - yes, that reference is to an I-D.  I suggest this I-D get
sync'd with that one.

2. PAddr syntax - yes, it is defined in
an informational document -- but, I seem
to recall that the earlier discussion took place when the syntax was for
humans needing to write things down.
In the current case, the syntax is needed for programs to interoperate.
So, perhaps this is OK.

3. Photo syntax - yes, they should provide a reference.

4. Fax syntax - yes, should provide a reference, but NOT RFC1314, which is
a TIFF format.  The reference should be something like T.30 or T.4, I forget
which.

5. Security attributes - these are OK.  The only thing this doc is doing is
defining an encoding for attributes that are defined in a "international
standard".

6. keystring bnf - it's botched.  I think it should be

<k> ::= <a> | <d> | '-'
<keystring> ::= <a> | <a> <anhstring>
<anhstring> ::= <k> | <k> <anhstring>

/mtr