[Ietf-not43] [Fwd: I-D ACTION:draft-ietf-rescap-rc-01.txt]

[Keith Moore]

[not on the list yet, replying via the archive...]

> Michael Mealling wrote:
> 
> > Are there other issues you think RESCAP would need?
> 
> I only read through it once, and quickly at that. A detailed comparison to
> the requirements document would take a fair bit of time, and the
> requirements document itself needs a bit more work.

I'll try to look at the requirements document myself to see how close
I think it is.  

> One thing that the LDAP angle offers over RC is that OIDs allow attribute
> names to be internationalized easily, while RC relies on ASCII strings
> which is less straightforward (and internationalization needs to be added
> to the requirements doc, btw).

OIDs are easy to use as RC attribute names (or values); just represent them 
as ASCII strings of the form

1*DIGIT * ("." 1*DIGIT)

you can even do wildcard queries for OID subtrees.  


> I also mentioned redirects because of:
> 
>  | 8. Differences from RC version 2
> 
>  |    RCv2 supported the notion of redirects - the ability to redirect
>  |    queries for portions of URI-space - at the protocol level; this is
>  |    omitted in RCv3 because they were too much trouble to use.
>  |    Redirects could be implemented in RCv3 by making them ordinary
>  |    attributes and by using the QUERY_RECURSE bit in queries for that
>  |    attribute name.

RCv2 supported redirects at the protocol level, meaning that you 
could tell the server "for any URI lexicographically between x and y,
return a redirect to server z rather than trying to do the lookup".  
This introduced a number of oddities that had to be sorted out -
for instance, how to handle redirects with subset and overlapping 
ranges - and it tended to slow down the server.  Basically it was 
an attempt to generalize something like DNS's NS handling.  But
it really wasn't general enough for URI redirection, and we found 
that it was easier to manage a separate redirect for each URI than to 
manage a separate list of redirect ranges.  Also, RCv2 predated NAPTR
records.  Once we had NAPTR records defined they seemed to provide 
a roughly-equivalent capability to the "redirects based on lexicographic 
ranges" that RCv2 provided.

Again, I'll have to look carefully at the !43 requirements document
before I understand whether RC's existing mechanisms would be 
satisfactory.  But thanks for considering it.

Keith