Re: Rep : Object Identifier Aliasing (OSI-DS 36 -- Colin Robbins)

Colin Robbins <c.robbins@xtel.co.uk> Mon, 25 January 1993 10:57 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08366; 25 Jan 93 5:57 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08362; 25 Jan 93 5:57 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa07804; 25 Jan 93 5:59 EST
X400-Received: by mta haig.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Mon, 25 Jan 1993 09:45:51 +0000
Date: Mon, 25 Jan 1993 09:45:51 +0000
X400-Originator: osi-ds-request@cs.ucl.ac.uk
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=uk.ac/ADMD=gold 400/C=gb/; haig.cs.uc.498:25.00.93.09.45.51]
Priority: Non-Urgent
DL-Expansion-History: osi-ds@cs.ucl.ac.uk ; Mon, 25 Jan 1993 09:45:51 +0000;
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Colin Robbins <c.robbins@xtel.co.uk>
Message-ID: <"26564 Mon Jan 25 09:32:27 1993"@xtel.co.uk>
To: "Ascan Woermann (Tel +33 93-65-34-65)" <Woermann@osi.e3x.fr>
Cc: "Steve Hardcastle Kille (Hyphen)" <S.Kille@isode.com>, osi-ds@cs.ucl.ac.uk
In-Reply-To: <72769561221144woer*/S=Woermann/OU=OSI/O=E3X/PRMD=E3X/ADMD=atlas/C=FR/@MHS>
Subject: Re: Rep : Object Identifier Aliasing (OSI-DS 36 -- Colin Robbins)


   >If this documents current practise the migration is not that smooth for
   >non-quipu users. To get access to some of the Cosine + Internet schema
   >attributes (friendlyCountry, audio, ...) I (as a non-quipu user) still need
   >to know about the old quipu-specific OIDs. I request the attribute with its
   >new OID, I get the value tagged with the old OID. Maybe this just needs the
   >order of OIDs to be reversed in the quipu attribute tables, but then I 
   >suppose you'd keep out quipu users that haven't upgraded.
   >
   >Ascan Woermann
   >E3X

Ascan,

You raise here a problem, and I agree it is a problem, however it is
not a QUIPU problem, BUT a general one of updating OIDs.  This paper
describes the mechanism implemented in QUIPU to solve a particular
problem that arose.  I am suggesting this mechanism can be used in a
more general manner.  

The paper was written after a discussion at a PARADISE meeting about
what happens to the X.500 pilot when/if RFC 1274 is forced to change
its OIDs from the present numbers to a different set (Please --- lets
not debate this issue here though).  For the pilot to continue, a
migration strategy is needed if OIDs change, this paper suggests such
a startegy. 

Your specific point is what happens if there is a migration from the
OID set A to a new set B.  But for certain reasons (e.g., only seeing
the very latest copy of a document such as RFC 1274, or migrating from
old-QUIPU to RFC etc), you only know about OID set B.
Well, what can you do?  

	You clearly have to use OID set B.
	If possible, use set A as aliases.

1) Anybody in the "old world only" will use set A and fail all over the place.
(fail because you will pass "B" back)
(What "fail" means here is some attributes will not be recognised ---
the operation should work with the standard 'unchanged' attributes.)

2) People in the "old world" with "new world" aliases will work fine:
       	They will send you "A", which you'll map to "B".
	You will send them "B" which they will map to "A".
If you don't have the aliases for "A", then it will be like case 1) above.

3) People in the "new world" with "old world" aliases will work fine"

4) People in the "new world only", will work fine (unless talking to a
"old world only" DSA/DUA.

So if you get the mappings in place early enough, a smooth transition
is possible even if some DSA/DUAs only use the "new world" OIDs.

I hope this answers your point.

In any follow up, please lets try and keep this discussion general,
talking about QUIPU specifics just adds to confusion.


Colin


PS
It is possible to make case 1) work if the other DSA/DUA has the
alaises for "A".  Rather than declaring always return "B", you return
whatever set you were passed.  This was considered, but the
implementation would be no where as near as simple as the mechanisim
described (in my view).  Plus, a set of rules would be required to
define special cases, such as what if you are passed some A and some B
attributes, what do you return?
I think for simplicity, the 90% solution described above will suffice.
(no I can't justify the 90%, its a figure off the top of my head that
feels about right).

-------------------------------------------------------------------------   
Please note that X-Tel Services is not connected in any way with Extel
Financial or the Exchange Telegraph Company Limited and is about to
change its name to prevent any such confusion.
-------------------------------------------------------------------------