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.