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

[Ascan Woermann <[e-mail]>]

> 
>    >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.

And precisely these will "fail all over the place" when interacting with the
"old" and "mixed world". This seems a strange set of priorities for
non-quipu users. However, I can live with the situation IF I know about it ...

> 
> 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.
> 
OK, but what has been missing sofar is non-quipu documentation (at least
to my knowledge). RFC1274 makes no mention of these alias mappings. I had to 
get hold of some quipu oid tables to find this out. Same goes for new additions 
such as JPEG photos. People talk about them, but you have to look in quipu
oid tables to find out that pilot attribute oid 60 has been assigned and
then do some more digging to find its syntax (silly, it's just an octet
string).

> 
> Colin
> 
> 

Ascan