To: email@example.com Cc: firstname.lastname@example.org, email@example.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 <firstname.lastname@example.org> Message-Id: <95Dec17.email@example.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.