CURRENT_MEETING_REPORT_


Reported by Robert Hagens/University of Wisconsin

MINUTES

The meeting was convened by chairman Rob Hagens.  An attendance list
will be published with the Proceedings of the IETF.

The group (much smaller than the last meeting) began the meeting by
discussing the sort of address structure required when X.400/MHS is
introduced into the Internet.  The group concluded that there is no need
to design or define an interm/transition address structure.  RFC
987/1138 defines an acceptable transition structure:  the RFC-822 domain
defined attribute.  There was some discussion about the lack of
widespread support for DDAs.  It appears that most ADMD providers
support DDAs in their MTAs, however there may be user agents that do not
support the entry of DDAs.  The general feeling was that this was a
shortcoming of the specific user agents; it could be corrected.  It
should not effect the organization of the NREN X.400/MHS service.

After this, the group discussed the need for a PRMD authority for the
NREN. Note:  the group's definition of NREN is the US portion of the
IP-connected Internet.

Several points were discussed:


   o An NREN PRMD is a long term solution for certain organizations.
   o Organizations may "grow out" of the NREN PRMD and register
     elsewhere.
   o As X.400 software is deployed within the NREN, we need to organize
     a coherent MTS before chaos decends.
   o We must provide cheap and quick registration services for the NREN
     PRMD.
   o The NREN PRMD may negotiate with US ADMDs for international
     service.  Such negotiations must be on the basis of originator
     keeps all revenue.
   o The NREN PRMD may relay traffic for other PRMDs
   o An NREN PRMD must provide a registration service as well as manage
     operational connectivity (i.e., routing).
   o The 'ole ADMD field question:  there is a general desire to keep
     the ADMD field blank.  Many ADMD providers require the ADMD field
     to contain the name of the ADMD. Should the NREN PRMD automatically
     fill in the ADMD field?  One suggestion was that within the US, the
     ADMD field should be kept blank, but international traffic would
     have the ADMD field set as the message leaves the country.  Some
     discussion of munging P1.originator vs.  P2.originator ensued.  Is
     that a protocol violation?  How does it effect security?  How does
     it effect a "reply"?
   o The question was raised as to whether the NREN could register
     itself as an ADMD. The answer was not known.

                                   1