[Ietf-not43] First draft on Relay bags in FIRS
Peter Gietz
Peter.Gietz at daasi.de
Fri Aug 15 19:30:56 EDT 2003
Steven,
Thanks for your comment. I do favour the controlValue solution. The URL
stuff seems to be more of a rathole to me (see the cons listed in my
prior posting).
I will include
>> SEQUENCE OF SEQUENCE {
>> ldapurl [0] LDAPURL,
>> relayBag [1] OCTET STRING
>> }
into the next version of the Draft (which I will hopefully have ready on
Monday).
As to the empty SearchResultReference: A possibility to get away with
it, without violating 2251, we could include something in the line of:
"
A server may send back referrals without a Relay Bag, referrals with a
Relay Bag and a combination of both.
Referrals without Relay Bag MUST be submitted via the
SearchResultReference construct specified in RFC 2251, section 4.5.2
for this purpose.
Referrals with a Relay Bag MUST be submitted inside the controlValue
field as specified above, without redundantly storing the referrals in
the SearchResultReference construct.
If only referrals with Relay Bag are submitted, the server MUST store a
dummy-referral in the SearchResultReference construct. The dummy
referral, which MUST be ignored by the client, is:
ldap:///
"
Eric: You being the only one preferring the URL solution, can you live
with this? Or do you see any serious issues?
Steven Legg wrote:
>
>
> I think you are getting hung up on your own assumptions here.
> Suppose that the format of the controlValue in a response were
> something like this:
>
> SEQUENCE OF SEQUENCE {
> ldapurl [0] LDAPURL,
> relayBag [1] OCTET STRING
> }
>
> The referral URL is clearly associated with the relay bag and the relay bag
> is still opaque. Anything else that's needed can be added to the SEQUENCE.
> The ldapurl field duplicates information in the SearchResultReference,
> but we can deal with that in the definition of the control by saying
> that any URL included in the controlValue is omitted from the
> SearchResultReference.
>
> RFC 2251 does not allow SearchResultReference to be empty but I don't
> see any interoperability problems from explicitly allowing that constraint
> to be violated since the response is never unsolicited (as far as I know)
> The LDAPbis working group might also be willing to drop the constraint.
>
> Regards,
> Steven
>
>
>>
>>Now comes Solution II:
>>
>>The alternative, Eric is proposing, is to use the extension
>>mechanism in
>>the LDAP URL, which is specified in RFC 2255 (text in [[ ]] are my
>>comments):
>>
>>
>>> extensions = extension *("," extension)
>>> extension = ["!"] extype ["=" exvalue]
>>> extype = token / xtoken
>>> exvalue = LDAPString from section 4.1.2 of [RFC
>>
>>2251] [[basically an OCTET STRING]]]
>>
>>> token = oid from section 4.1 of [RFC2252] [[an
>>
>>oid either numeric or as object descriptor]]
>>
>>> xtoken = ("X-" / "x-") token
>>>The extensions construct provides the LDAP URL with an extensibility
>>>mechanism, allowing the capabilities of the URL to be
>>
>>extended in the
>>
>>>future. Extensions are a simple comma-separated list of type=value
>>>pairs, where the =value portion MAY be omitted for options not
>>>requiring it. Each type=value pair is a separate extension. These
>>>LDAP URL extensions are not necessarily related to any of the LDAPv3
>>>extension mechanisms. Extensions may be supported or unsupported by
>>>the client resolving the URL. [...]
>>
>>There are pros and cons here:
>>
>>Pro:
>>- This solves our problem.
>>- for every referral we have a Relay Bag
>>
>>Cons:
>>- There is a "media change". Since clients usually don't communicate
>>with servers via LDAP URLs, the client has to convert this
>>information
>>into the search control as specified in the new draft. Not
>>too complex
>>though:
>> * the token (provided the numeric od form is used) can be
>>the same as
>> the controlType
>> * the criticality sign ('!') or its absebse can be stored in the
>> criticality field
>> * the exvalue is the controlValue (might need reencoding
>>though, see
>> next bullet)
>>
>>- the exvalue has to be URLencoded, in the words of 2255:
>>
>>>Note that any URL-illegal characters (e.g., spaces), URL special
>>>characters (as defined in section 2.2 of RFC 1738) and the reserved
>>>character '?' (ASCII 63) occurring inside a dn, filter, or other
>>>element of an LDAP URL MUST be escaped using the % method described
>>>in RFC 1738 [5]. If a comma character ',' occurs inside an extension
>>>value, the character MUST also be escaped using the % method.
>>
>>- The URL might not be a very good vehicle to transport
>>greater amounts
>>of data, which might restrict the usage of relay bags. I think it is
>>doable though and I don't know of any length restrictions for URLS
>>(hasn't there been a data field extensions for http urls as well?
>>
>>- we loose the symmetry between request extension and response
>>extension, which would have made the implementation fairly easy, the
>>client had only to take the whole control construct and add it to its
>>next request
>>
>>Solution III:
>>Another very easy solution would be to always give back only one
>>referral to the client, but that might not be what we want either.
>>If the Relay Bag is to store information about the referring
>>server and
>>about the client, we would not need more than one relay bag. But this
>>would make it impossible, e.g. to encrypt the relay bag information
>>with the public key of the server referred to, and we might
>>want to have
>>that.
>>
>>
>>You see I am biased and none of the solutions looks very
>>promissing to
>>me. But I think we have to choose between Solution I and II.
>>
>>
>>Peter
>>
>>
>>>-andy
>>>
>>
>>--
>>______________________________________________________________
>>_________
>>
>>Peter Gietz (CEO)
>>DAASI International GmbH phone: +49 7071 2970336
>>Wilhelmstr. 106 Fax: +49 7071 295114
>>D-72074 Tübingen email: peter.gietz at daasi.de
>>Germany Web: www.daasi.de
>>
>>Directory Applications for Advanced Security and Information
>>Management
>>______________________________________________________________
>>_________
>>
>>_______________________________________________
>>Ietf-not43 mailing list
>>Ietf-not43 at lists.verisignlabs.com
>>https://lists.verisignlabs.com/mailman/listinfo/ietf-not43
>>
>
>
--
_______________________________________________________________________
Peter Gietz (CEO)
DAASI International GmbH phone: +49 7071 2970336
Wilhelmstr. 106 Fax: +49 7071 295114
D-72074 Tübingen email: peter.gietz at daasi.de
Germany Web: www.daasi.de
Directory Applications for Advanced Security and Information Management
_______________________________________________________________________
More information about the Ietf-not43
mailing list