notes on draft-ietf-asid-ldap-format-01.txt

Larry Masinter (masinter@parc.xerox.com)
Sun, 17 Dec 1995 14:15:49 PST


To: tim@umich.edu
Cc: ietf-asid@umich.edu, uri@bunyip.com
In-Reply-To: "Tim Howes"'s message of Thu, 14 Dec 1995 06:36:59 -0800 <199512141437.JAA22165@terminator.rs.itd.umich.edu>
Subject: notes on draft-ietf-asid-ldap-format-01.txt
From: Larry Masinter <masinter@parc.xerox.com>
Message-Id: <95Dec17.141554pst.2733@golden.parc.xerox.com>
Date: Sun, 17 Dec 1995 14:15:49 PST

Sorry for the belated review, the ASID minutes said that the draft of
the subject had been circulated to the URI mailing list, but I don't
remember it.

Comments:

| <filter> := a string as defined in RFC 1558

The strings in RFC 1558 can contain many characters that are not
allowed in URLs. RFC 1558 introduces one quoting mechanism (backslash)
for attribute values that contain '*', '(', or ')' (and presumably
'\', although it doesn't say that.)

Then you'll have to %hex encode any part of the LDAP search filter
that might be illegal in URLs.

This is all pretty unpleasant. Perhaps some other linearization of
LDAP search filters that doesn't use URL-unsafe characters might be
more suitable?

As a procedural matter, I predict it may be difficult to get
draft-ietf-asid-ldap-format-01.txt to be accepted as standards track
as long as it depends on RFC1558, which is 'Informational'.

If this remains, draft-ietf-asid-ldap-format should spell out that
%hex encoding and decoding is necessary for the <filter> from RFC
1558.

================================================================
| <attribute> ::= a string as defined in RFC 1487

RFC 1487 defines many strings and none of them is labelled
<attribute>. It actually isn't clear which string of RFC 1487 you're
assuming.