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

> 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

Received on Sunday, 17 December 1995 20:22:23 UTC