ietf-822
[Top] [All Lists]

Where should X.400 mappings be defined?

1994-05-22 23:40:03
    It is suggested that RFC 1327 be updated to produce the Content-
    Language: header, and to turn this header into the ISO/CCITT
    specified Language components rather than the RFC-822-headers
    heading extension.

Should a standards track document express opinions about an
administrative matter such as how other Internet standards
should be revised?

This is an interesting point. One could generalize the problem and
say: Should all information about gatewaying between Internet mail
and X.400 be RFC 1327 and future revisions of it, or should such
information instead be in the standard which describes the Internet
mail functionality being gatewayed.

The advantage with the latter solution is that it is natural to
produce and describe the X.400 mapping at the same place where
the Internet mail functionality being mapped is described. They
are usually (or should usually) be developed at the same time.
Putting this information into RFC 1327 creates a need for many
small amendments to RFC 1327.

One can probably envisage that in the future we are going
to get more and more specialized additions to Internet mail
for more and more specialized application areas like voice
messaging, EDI etc. Would int not then be better to let these
standards themselves define their X.400 mapping?

One can compare the way in which X.400 handles new content types
in the P7 protocol. Instead of extending the standard describing
the P7 protocol, every time a new content types requires new
P7 definitions, such new P7 definitions are put into the description
of the new content type instead of into the P7 standards document.

For example, IPM attributes in P7 are described in the IPM
standard (X.420) and not in the P7 standard (X.413). And EDI
attributes in P7 are described in the EDI document (X.435).


<Prev in Thread] Current Thread [Next in Thread>