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. -------------------------------------------------------------------------
- Rep : Object Identifier Aliasing (OSI-DS 36 -- Co… Ascan Woermann
- Re: Rep : Object Identifier Aliasing (OSI-DS 36 -… Colin Robbins