Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard

[Mark Prior <]

Curtis Villamizar wrote:

> How is RPSLng not a superset of RPSL?  Nothing has been removed from
> RPSL.
Superset is probably not the best word to describe what I want.

> The issue is just how do you make transition easiest, supporting older
> RPSL only clients.  If you just extend import rather than rename it
> mp-import and extend it, then old RPSL only clients will consider you
> autnum broken.  If you include mp-import but forget to reflect you
> IPv4 policy in plain import then the old RPSL client will pick up a
> subset of you policy.
>
> In either case, extending import, or adding mp-import and putting the
> extensions there, it would make for a smoother transition if the
> server code could recognize old clients and feed them with objects
> translated into plain RPSL.
I think I have been consistent in wanting the smarts to be in the 
software and not the language. I would prefer to overload the syntax 
then create new syntax and let the software work out what is required. 
We don't use different syntax in computer languages when we want to 
operate on integers rather than reals so why make the distinction in 
RPSL? If we have a route object that has a IPv6 address in it surely the 
software can work out if it wants it or not given it's current context?

I know you (and others :-) keep on about the old clients but we have 
left them behind once before in the transition from RIPE 181 to RPSL so 
do it again but this time lets leave some mechanism behind so that when 
we need (RPSLng)ng we don't go through this pain yet again. Saying it's 
not part of the language is a pathetic excuse in my book for not fixing 
it. If we need a "shim" document to describe the interaction between a 
server and a client then lets do it. It would make the client software 
writers life a lot easier if there weren't (at least) 3 server 
interaction languages to deal with.

Mark.