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

Tim Howes (tim@umich.edu)
Sun, 17 Dec 1995 19:28:11 -0500


Message-Id: <199512180028.TAA19608@terminator.rs.itd.umich.edu>
From: "Tim Howes" <tim@umich.edu>
To: Larry Masinter <masinter@parc.xerox.com>
Cc: ietf-asid@umich.edu, uri@bunyip.com
Subject: Re: notes on draft-ietf-asid-ldap-format-01.txt 
In-Reply-To: Your message of "Sun, 17 Dec 1995 14:15:49 PST."
             <95Dec17.141554pst.2733@golden.parc.xerox.com> 
Date: Sun, 17 Dec 1995 19:28:11 -0500

> From:    Larry Masinter <masinter@parc.xerox.com>
> To:      tim@umich.edu

> 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.

Thanks for the comments!

> 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?

Could do that, but as long as there is a representation already defined,
we should use it. In practice, there will be many characters that need
escaping (spaces in DNs, for example). The set of URL-unsafe characters
is rather large, unfortunately. When trying to fit existing stuff into
the URL scheme, this is bound to happen. I think it's better to use
the existing stuff, though, than reinvent new stuff just for the URL
format.

I will add a clarifying note about the escaping issue with filters,
though, like the one that's already there for DNs.

> 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'.

I don't think so. I've seen other things go through like this. The
real test is whether what it references is well-defined and stable,
which 1558 is. At least, that's the way it was last time I checked
with the RFC editor.

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

Will add a note, as mentioned above.

> ================================================================
> | <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. 

That should be 1777, which obsoletes 1487. I'll fix that. And 1777
is currently undergoing a revision to clarify the definition of
attribute type, which is what this refers to. I'll make sure the
references coincide and are understandable.                    -- Tim