Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/mixer/mixer-minutes-95jul.txt

Text File | 1995-10-18 | 12KB | 266 lines

CURRENT_MEETING_REPORT_

Reported by Allan Cargille/MCI

Minutes of the MIME - X.400 Gateway Working Group (MIXER)


Charter Review

Urs had several editorial changes to the draft charter.  It will be
submitted to the Area Directors for IESG/IAB approval and publication.


Comments

Erik Huizer said the document needs to clarify that there is an
operational 1327 network right now that MIXER must not break (must
support to interwork).


Review of draft-kille-mixer-rfc1327bis-00.txt

Discussion was limited to the list of issues that had previously been
compiled by Steve Kille from discussion on the mailing list.  Issues are
covered one by one below and are labeled 3.N where N was the issue
number from Urs' summary.

3.1.  There was discussion on whether one character set should be
specified or should it be left as a choice in the specification.  There
was consensus that a choice should be made.  The use of the ISO 8859-1
character set was viewed as preferable; however, some T.61 strings
cannot be translated into 8859-1.  The group decision was that the ISO
8859-1 character set will always be used when this is possible; when
this is not possible, Teletex will be used.

3.2.  The group decision was that the specification must distinguish
between envelope addresses and header addresses.  Envelope address must
always be translated correctly, even when this means delaying the
message indefinitely.  Header addresses should attempt to be mapped, but
if the mappings are unavailable after a reasonable timeout period, the
default (LHS) encoding may be applied instead.  The specification will
mention that one to four hours is a reasonable timeout period, and that
these timeout periods should be configurable in an implementation.

3.3.  The group decision was that the DDA RFC 822 may always be
gatewayed immediately into RFC 822 and routed through MTS-822.  It was
noted that this will break some non-standard uses of the DDA. If
alternate behavior is required, the specification will recommend the use
of a private DDA. It will also contain an example of such a private DDA
type.

3.4.  The group decision was to use an IANA OID, not an ISO-defined OID.

3.5.  The text will be clarified on Page 91 that this only applies to
the 1984 version of US GOSIP. (Chapter 5.1.6)

3.6.  There was a discussion about how at some times it is desirable to
be able to ``terminate'' or ``disable'' the application of a mapping
rule below some level.  This had been mentioned as causing ``operational
problems'', but in the experience of the academic and research X.400
community, any problems with this can be solved by itemizing numerous
mappings at a lower level in the tree.  This leads to large mapping
tables.  But in a distributed environment using DNS or X.500 the size
problem disappears.

3.7.  The group decided that implementations should continue to generate
the ``ADMD= '' field when it is present in addresses.  However, in the
case of received messages with no ADMD field present, they should
interpret this as indicating ``ADMD= ''.

3.8.  The text will be changed to identify heuristics one through five
as mandatory, and leave six as optional.  People should review the
impact of these changes on the mailing list and comment on any problems
that this might cause.  (See chapter 4.3.4.1 of the MIXER draft.)

3.9.  There was discussion about whether this specification should
introduce the opposite of the 1148-gate table to aid gateways in
producing LHS-encoded RFC 822 addresses that will be accepted by an
X.400 gateway in the reverse direction.  This relates to gateway and
X.400 policy restrictions, not just outputting routable RFC 822
addresses.  The group decision is that it is preferable to publish
mappings instead of 1148-gate style tables.  It was noted that it may
even be desirable to delete the 1148-gate table entirely if we were
re-designing the specification, but that this would not be appropriate
due to the current installed base.  Text will also be added to the
document that when gateways know that a return message to their gateway
will not be routable based on policy restrictions, that an appropriate
gateway address may be used instead.  Such a gateway should be at least
informally known as willing to route traffic to the X.400 address in
question.  It is expected that such information might be maintained by
the MailFlow project team if there is an operational requirement for
this.  (This discussion refers to Page 65 of the MIXER draft.)

3.10.  Option one in section 4.6.2.2 will be deleted from the document
because it is not implemented and not used.

3.11.  It was decided that support for reverse mappings will be made
mandatory.  (Section 5.1.7, Pages 94/95.)

3.12.  The second option (to store messages at the gateway and correlate
with NDNs to support return of content) will be dropped from the
document.  (Section 5.2, Page 101.)

3.13.  [Ref Page 108, Section 5.3.4.3] It was agreed that the
Content-Disposition header will be used where appropriate, but that it
is not required to turn everything into a File Transfer Body Part which
contains this header.  The FTBP will be used only when it is
appropriate.

3.14.  There was discussion on whether the RFC 822 transport used should
be left general, as it is in the current version (822-MTS), or changed
to the most common RFC 822 transport protocol, SMTP. It was pointed out
that the use of the string ``822'' when discussing the 822-MTS can cause
a reader to mistakenly interpret this as referring to the RFC 822
content (headers) instead of the RFC 822 mail transport layer.  It was
also pointed out that referring directly to the SMTP transport in the
body of the document is more friendly to readers from the Internet
community.  The group decided to change this terminology in the body of
the document to refer to SMTP, and to discuss the use of alternate
transports (BITNET, UUCP, etc.)  in one or more appendices.

There was also a discussion at this point about whether the SMTP
extensions supporting SMTP DSNs (the NOTARY work) should be required in
this document.  It was decided to continue this discussion on the
mailing list.  If NOTARY extensions are not required in the body of the
document, these extensions will also be discussed in an appendix.

3.15.  There was a discussion about the standards terminology used in
the document, ISO rules (shall, may, may not) versus IETF (MAY, SHOULD,
MUST). It was decided that it is fine to continue to use ISO language in
the document, but that this should be called out early in the document,
and explained in terms of IETF terminology.  It was also decided that
the document must avoid the use of profiles; it must be a complete
specification.  It was clarified that the document should not use the
terminology ``should'' to describe gateway behavior because this is not
utilized in ISO terminology.

3.16.  The X.400 portions of the document describes things in terms of
the IPMS Abstract Service, the MT Abstract Service, and the MTA Service.
It also identifies manipulations outside of these standard services as
layering violations.  The question was raised whether this model should
be retained in the document or it should be removed.  It was pointed out
that this would require sweeping changes to the document, which would
require a lot of work (and therefore time) and would make it more
difficult for readers to identify the significant changes between
RFC 1327 and this specification.  It was decided to retain the current
model of the document, but to remove sections which are unnecessary
sources of potential confusion.  In particular it was recommended that
the ``layering violation'' text be moved to footnotes.  The author
requests for reviewers to identify any areas of the text which are
unnecessarily confusing.  It was also clarified that the document is a
specification, not a protocol, and explicitly warns readers that they
must be highly knowledgeable of both the RFC 822 and X.400 protocols to
understand the document.



Review of draft-ietf-mixer-bodymap-00.txt


This document is a revision of RFC 1494.

Changes from RFC 1494


   o It was clarified that the MIXER document above incorporated the
     ``base functionality'' of how to map body parts if no mapping is
     defined from RFC 1494.

   o The Teletex body map mapping was added based on input from Alan
     Young.

   o The bit order (in a byte) was made explicit.  This had been
     implemented different ways by implementors.

   o Number of documents -- right number?


Discussion and Decisions

a.  Harald will solicit feedback from Ned Freed, Alan Young, and Julian
Onions (implementors) on whether the current specification is
satisfactory.

b.  There was a discussion on whether the File Transfer Body Part (FTBP)
mapping should be in the main document above or in this document.

c.  There was discussion about mapping text/plain charset=Teletex body
parts.  The current document recommends mapping these into ISO 8859-1 or
another common character set if possible.  However, if this body part is
gatewayed again it will be translated into GeneralText.  It would then
be dependent on X.400 88 to 84 downgrading to get the original text
back.  The teletex character set maps back, but using 8859-1 is a more
sensible and pragmatic solution.  The question is which case you
optimize for, the tunneling case or the simple case (such as two people
using Norwegian on different sides of the gateway).  A decision was made
to optimize this ``simple'' case and using the ISO 8859-1 character set.

d.  There was a discussion on the best way to organize the body part
mapping document(s).

Options:

  1. Consolidate into one document (the present draft)

  2. Break into an X.400 piece, a MIME piece, and a document specifying
     the mapping between them, or

  3. Break each X.400-MIME mapping into a separate document.


It was clarified that it is desirable to define generic mechanisms in
the main MIXER document -- framework mechanisms, options for
transferring, and ways one could do something.  The RFC 1494bis document
will discuss how to handle specific body parts and how things should be
gatewayed into the other environment.

There was discussion about the concern that the EEMA may adopt different
gatewaying specifications than the IETF and that this would cause
operational problems.  It was agreed that only one mapping mechanism
should be in general use for every body part.  It was clarified that the
EEMA is likely to follow IETF specifications unless they are done poorly
or badly publicized.  It was clarified that the mapping recommendation
for a body part can be updated if general practice changes.

An on-line registry for body part mappings was discussed.  Harald
clarified that this is included in the current document.

It was pointed out that it is desirable to keep the description of
parallel MIME and X.400 body parts in the same document so that it is
clear why certain elements were included or designed like they were.

Maintainability was discussed as an important issue -- how many
documents would have to change if a given mapping changed?

It was clarified that IANA requests very clear documentation on any
registration role that this document or group would ask them to
undertake.

e.  There was general agreement that each related MIME and X.400 body
part (and the mapping between them) should be broken out into a separate
document.  Any remaining issues will be discussed on the list.  Harald
will put out the revised, split documents by the end of August.


Follow-up Work on Main MIXER Specification

It was agreed that any discussion on the content of the specification
should be sent to the list immediately.  There will be a one-day meeting
at the ISODE Consortium (England); the tentative date is 18 September.
This will be used for editorial review only and a page-by-page
walk-through.  The meeting will be regarded as an off-site MIXER Working
Group meeting, and the results must be published (in great detail) to
the list.  They must also include detailed explanation of any changes
which are at all controversial.  The author will also include updated
change bars in the new version of the document.


Charter Review

The working group chair will leave the milestones as they are at
present, because it is unknown whether a meeting at the next IETF will
be required or not.