CURRENT_MEETING_REPORT_


Reported by Kevin Jordan/CDC

X400OPS Minutes

Review of Agenda

The Agenda was approved without change.  Although, some minor
adjustments were made as the meeting progressed.

Review of Charter

It was made clear that the focus of the Working Group is the operation
of X.400 mail on the Internet.

Rob Hagens presented a one page draft document describing the strategy
for deployment of X.400 in the Internet.  The goals described in the
document were reviewed and discussed.  The goals drafted by Rob were:


  o The X.400 service will not, in the near future, completely replace
    existing Internet mail service.

     -  It was pointed out that this is an assumption, not a goal.  It
        was suggested that a useful goal would be to work with the SMTP
        Verison 2 Working Group in order to facilitate gatewaying
        between SMTP V2 and X.400.

     -  People who had attended the SMTP V2 meetings on Monday, 3/11,
        reported briefly on what was discussed there.  It seems that
        the SMTP V2 Working Group has just begun defining requirements,
        so judging from previous experience, it will probably be at
        least two years before SMTP V2 is widely implemented and
        operational.


  o The X.400 service in the Internet shall be fully connected to the
    existing Internet Mail service via gateways.


     -  It was recommended that this goal be revised so that it
        includes a clause about the need for X.400 gateways to be
        highly interoperable with the existing Internet mail services.



                                  1






  o The X.400 service in the Internet will be connected to
    international  R&D  X.400 service initiatives.


     -  UW-Madison has already established a direct X.400 link to
        Norway, Finland, Canada, UK, France, Switzerland and Spain.
        The Norwegian connection has agreed (at least for now) to act
        as a relay between XNREN and the other participants of the
        COSINE X.400 project in Europe, not directly connected to
        XNREN.


  o The X.400 service in the Internet will be connected to major ADMD
    providers in the U.S., provided that a suitable arrangement can be
    made.


     -  There was general consensus that this is a very important goal.
        However, it is not yet clear how this goal will be attained due
        to the fact that the ADMD providers are commercial
        organizations who normally account and charge money for their
        services.

     -  On the second day of meetings, Vint Cerf indicated that CNRI is
        already pursuing this goal.  CNRI is willing to provide the
        physical plant necessary to provide a connection to an ADMD
        provider, but human resource limitations may delay
        implementation.  Rob Hagens indicated that UW-Madison could
        help.


  o Although the 1984 protocols may be used on an experimental basis,
    the primary deployment of X.400 should be based upon the 1988
    version of X.400.


     -  It was recommended that this goal should be rewritten in terms
        of driving toward general deployment of 1988 X.400 (or perhaps
        1992 X.400), but that it is also necessary to provide backward
        interworking with 1984 X.400.  Conversion from 1984 to 1988 to
        1992 and beyond will not occur all at once.  The transitions
        will probably be gradual, so backward interworking is
        desirable.


  o With respect to management domains, the Internet will be organized
    as a collection of Private Management Domains.


Finally, the Technology section of the draft document contained the
following statement:

                                  2






    The X.400 service in the Internet will conform to the US GOSIP
    profiles.

It was recommended that this statement be qualified because, for
example, GOSIP requires OSI lower layers, but the Interent X.400 service
will be based primarily upon TCP/IP (RFC1006) initially.

Relationship to other techinical groups

Some members of the X.400 Operations Working Group are also members of
other technical groups.  It was suggested that this informal cross
participation would be used for communications between the X.400
Operations group and other groups.  The groups mentioned were:  IETF-DS,
IETF-ODA, RARE-WG1,  R&D  MHS Managers, NIST Workshops.

Round table presentation of current X.400 service status

Each of the Working Group participants discussed how X.400 is being used
(or is planned to be used) within his/her organization.  Most sites are
planning to use X.400, but are not using it actively yet.  Notable
exceptions are UW-Madison and CDC; these organizations are actively
using X.400 now.

Overall organization of the X.400 service in the Internet


  o Technical requirements
    Two types of MTA's were defined:


     -  MTA's supporting RFC1006, informally called Internet MTA's
     -  MTA's supporting TP0/X.25, informally called PDN MTA's


    It was generally agreed that organizations wishing to particpate in
    the Internet X.400 project should support Internet MTA's, meaning
    that participating organizations should provide an MTA which
    supports RFC1006.
    However, the Working Group does not want to preclude participation
    by organizations which are connected only to X.25-based PDN's.
    Such an organization will need to make a bilateral agreement with
    an organization which supports both RFC1006 and TP0/X.25, and
    arrange for that organization to relay mail between the X.25-based
    connection and the RFC1006-based Internet connection, or each PRMD
    should implement mechanisms to insure end-user connectivity on top
    of both stacks.
    We should also be prepared to serve MTA's connected to the TP4/CLNP
    infrastructure.

                                  3






    It was noted that these technical requirements are essentially the
    inverse of the connection requirements established by COSINE for
    its members.  COSINE requires all participating organizations to
    support TP0/X.25 connections to their respective country's PDN.
    RFC1006 is not defined as mandatory by COSINE. This implies that
    interconnection of COSINE and the Internet X.400 project will:


     -  require a relay in the U.S. to support both X.25 and RFC1006,
        or
     -  require a relay in Europe to support both X.25 and RFC1006.
        This, in fact, is the current state of affairs, or
     -  combinations of a.  and b.  above.


    It was generally agreed that GOSIP should serve as a reference
    document for X.400 upper layer technical requirements, where
    ``upper layers'' is defined to be the OSI Session layer and the
    layers above it.
    The term ``Internet WEP'' was introduced to identify a special MTA
    acting as a Well-Known-Entry-Point for an Internet PRMD. UW-Madison
    will distribute a draft definition of an Internet WEP to the list
    for review.

  o Internal organization of PRMD's
    It was agreed that naming authority should be hierarchically
    organized.  Specifically, the names of organizations should be
    coordinated with the PRMD's in which the organizations are created.
    Similarly, the names of organizational units should be coordinated
    with the organizations in which the organizational units are
    created (but not necessarily with the PRMD administrators).
    UW-Madison will maintain a list of Internet PRMD's.
    UW-Madison will maintain FTP-able documents which describe
    participating organizations and information about MTA's (e.g.  MTA
    connection information).  ONLY operational organizations and MTA's
    will be described in these documents.
    It was agreed that an important characteristic to describe about an
    MTA is its ability to operate over both RFC1006 and TP0/X.25.
    Publishing this characteristic will make it easy for prospective
    participants supporting only TP0/X.25 to locate existing
    participants who might be willing to act as Internet relays.
    UW-Madison will distribute a draft definition of an MTA document
    format to the list for review.


Specification of RFC822 addresses in the X.400 world

It was agreed that RFC822 addresses should be expressed using X.400
domain defined attributes.  Furthermore, a special PRMD named
``Internet'' will be defined to facilitate the specification of RFC822
addresses.  For example, an X.400 user will address an RFC822 recipient


                                  4






by constructing an X.400 address such as:


    /c=us/admd= /prmd=Internet/dd.RFC-822=user(a)some.place.edu/


Participating MTA's will be configured to recognize ``/c=us/admd=
/prmd=Internet/'' as a special case.  The presence of this address will
cause a message to be routed to a regional RFC987 gateway.  In effect,
this special PRMD identifies a community of gateways to RFC822
recipients.  This strategy is user friendly in that all users everywhere
need only remember this one gateway address, and it is efficient in that
it avoids having to establish a single, common gateway which would tend
to become a bottleneck and single point of failure.

Specification of X.400 addresses in the RFC822 world

After considerable discussion, it was agreed that RFC822 users should be
able to address X.400 recipients in RFC822/Internet terms.  This implies
the necessity of maintaining and distributing address mapping tables to
all participating RFC987 gateways, at least in the short term.  Other
mapping strategies were discussed (loudly and enthusiastically), but it
was shown that these alternate strategies would sometimes cause messages
(or replies to messages) to pass through more than one gateway.  Since
this behavior would probably cause information to be lost in
translation, it was quickly agreed that the alternate strategies were
inferior to the good old table driven approach.

Nevertheless, it was also pointed out that some X.400 addresses do not
map cleanly to RFC822 addresses, even when the table driven mapping
strategy is used.  For example, X.400 personal names which contain
generation qualifiers, personal names which contain initials but no
given name, and initials which contain periods can not be mapped to
RFC822 symmetrically such that a reverse mapping is possible.
Similarly, X.400 addresses which contain X.121 address elements
(sometimes used for expressing fax telephone numbers), unique UA
identifiers, or physical addressing attributes can not be mapped nicely.
Consequently, it will be necessary for RFC987 gateways to generate
RFC987 address syntax occasionally.

It was recommended that our RFC should contain guidelines for the
creation of X.400 personal names.  In following these guidelines, users
will avoid creating personal names which can not be mapped nicely
between X.400 and RFC822.

It was generally agreed that long term reliance upon static mapping
tables is unacceptable.  Therefore, it was agreed that the X.400
Operations Working Group should devise a strategy for using X.500
directory services instead.

                                  5






Another option could be to use the DNS system for this purpose, if the
X.500 infrastructure appears to be too premature.

Future issues

The following list of issues were agreed to be important for the future
service, and the group should follow these issues closely:


  o X.400/84 <--> 88 interworking.
  o Use of DNS for RFC 987 address mapping management
  o Use of an X.500 infrastructure for routing, table management and
    user catalog purposes.
  o Body types other than text.


Presentation of outline for RFC

Rob Hagens proposed an outline for the RFC to be produced by the Working
Group.  Participants made comments and suggested additions.

UW-Madison will write a first draft and distribute it to the list for
review.

Future meetings

A tentative meeting has been scheduled for May 30 and 31.  This meeting
will be held in Madison, Wisconsin or San Jose, California.  The purpose
of the meeting will be to resolve comments against the draft RFC, in
case there are comments which can not be resolved via email.

The next general IETF meeting is scheduled for July 29 - August 2 in
Atlanta, Georgia.  The X.400 Operations Working Group will definitely
meet at that time.

Action items



Rob Hagens   Update and distribute the X.400 Internet Service Strategy
            document.
            Update and distribute outline for the RFC.

Alf Hansen   Write and distribute a definition of ``Internet WEP''.

                                  6






Kevin Jordan  Distribute minutes from St.  Louis meeting.  Distribute
            the X.500 schemas used by CDC to record information about
            X.400 routes, MTA's, and address mappings.  Include a
            description of how these schemas are used by CDC's X.400
            products.
            Distribute a description of CDC's extensions to RFC987 in
            support of multipart/multimedia X.400 messages.



Attendees

Vikas Aggarwal           [email protected]
Vinton Cerf              [email protected]
Cyrus Chow               [email protected]
Alan Clegg               [email protected]
John Dudeck              [email protected]
Ned Freed                [email protected]
Charles Fumuso           [email protected]
Shari Galitzer           [email protected]
Tony Genovese
Robert Hagens            [email protected]
Alf Hansen               [email protected]
Kevin Jordan             [email protected]
Mukesh Kacker            [email protected]
Jim Knowles              [email protected]
Ruth Lang                [email protected]
Mike Little              [email protected]
John Reinart             [email protected]
Ursula Sinkewicz         [email protected]
Michael Stanton          "[email protected]"
Michael Tharenos         [email protected]
Linda Winkler            [email protected]
Russ Wright              [email protected]



                                  7

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.