What solutions exist for the empty PRMD and O problem?

[[e-mail]]

More than a month has passed since Kevin Jordan made his proposal how the
problem with the empty organization and empty prmd could be solved.  No real
discussion has been done in the meantime.  Therefore I try to get the discussion
moving again.

To find a solution we have to recap how RFC 1327 maps addresses between X.400
and RFC 822, what it does special for the cases above and how this functionality
could be achieved with a MHS-DS based implementation.

RFC 1327 introduced

- a textual representation of X.400 addresses
- an ordering/hierarchy in the set of O/R address attributes
- a placeholder for missing attributes
- a format for lookup tables

This allowed mappings like

   O$@.PRMD$@.ADMD$cdnnet.C$ca#cdnnet.ca#    and
   cdnnet.ca#O$@.PRMD$@.ADMD$cdnnet.C$ca#

The mapping itself was always a combination of a lookup and algorithmic part.
To map an O/R address with a omitted PRMD or O to a RHS encoding at least an
entry must be made in the tables which included the omitted attribute. This
empty attribute value is represented by '@'.

Now, how could this be resolved with Routing Trees?

I see the following possibilities:

1) Change RFC 1327 in the way omitted components are handled. Use the changed
   algorithm for MHS-DS.
2) The RFC 1327 approach. I will call this the lookup approach.

   This means all attributes must be represented in a O/R address routing tree.
   If the value of a component is empty, use a placeholder.  In the domain
   routing tree the attributes associatedORAddress,
   nonAuthorativeAssociatedORAddress and associatedX400Gateway ommitted
   attributes must be specified, as the value a placeholder is used.

   The mapping is done as described in RFC 1327.

3) The algorithmic approach.

   Define how an algorithm can be specified, which will at least be able to
   do the same mapping as defined in RFC 1327. But this algorithm may give you
   more possibilities.

4) Use a combination of 2) and 3), that means use first a lookup and then use
   the algorithm found with that lookup.

   The algorithm found can specify how to map the whole address, or the rest of
   the address not matched by the lookup.

Are there any other solutions?

My comments to these solutions:

1) I have no idea how this could be done. Even if there would be a way it would
   mean to specify a new RFC and the gateways conforming to this RFC are
   incompatible to the gateways of RFC 1327. I think we can forget this
   possibility.
2) This would mean a change of the representation of O/R addresses in routing
   trees. And a value for the placeholder must be found. The change of this
   document would not be as big as a change to RFC 1327, because there are
   only a few implentations out there. This solution would be possible to make.
3) This would require no change, but an extension to current definitions.
   It must be defined how to lookup this algorithm.
4) This approach is the most powerful. It would resolve the problem and allow
   more things to do. This is the approach suggested by Kevin Jordan.


Everybody should now comment, if there exists other solutions and which
solution seems to be the best to solve the problem. Then we can discuss how
the choosen solution could be defined.

--

Michael Storz
================================================================================
                                      !   X.400 : G=michael;S=storz;OU1=lrz;
   Leibniz-Rechenzentrum              !           P=lrz-muenchen;A=d400;C=de
   Barer Str. 21                      !   RFC822: [e-mail]
   80333 Muenchen                     !   Fax   : ++ 49 89 2809460
   Germany                            !   Tel   : ++ 49 89 2105 8720
================================================================================