CURRENT MEETING REPORT Minutes of the MIME-X.400 Gateway Working Group (MIXER) Reported by Ned Freed, Innosoft Review/Finalization of MIXER Core Document (draft-ietf-mixer- rfc1327bis-02.txt) Steve Kille stated his belief that the document from the Richmond meeting is pretty solid now. Steve has received approximately half a dozen comments via e-mail since then, none of them requiring discussion here. Kevin Jordan pointed out the following problems: (1) Redirection history is missing a to address (page 72). This is a typo that Steve will correct. (2) Converted trace info (page 85) causes problems in that it prevents certain types of loops from being detected. Steve will specify logic to detect such loops after some number of iterations. (3) FTBP-header fields are referred to in the BNF summary. These are part of the body part document and will be removed from the core document. It was pointed out that security elements should not simply be discarded. Steve responded that this is taken care of by the "critical for delivery" marking. Harald Alvestrand pointed out that when a report is transferred from X.400 to RFC822 the original recipient is in RFC822 format. The current recipient, however, is in X.400 format. Keith Moore pointed out that addresses in X.400 delivery notifications may have started out in any form, and that the criteria for conversion to RFC822 form should be based on address mapping (e.g. whether or not a DD.RFC822 field is present). Harald added that there are several issues of this sort. Steve suggested that detailed comments regarding this issue be sent via e-mail. Urs Eppenberger noted that a new version of the document is needed to deal with these comments and that comments should be sent to Steve no later than December 20, 1995. Steve believes that he can have a new draft with change bars out by the first week of January 1996. A two week Working Group Last Call should be issued then, at the end of which a new draft will be released without change bars. Document Dependency Issues Urs noted that the core and bodymap documents are interrelated and that the other three drafts depend on the core and bodymap documents. Review of The Bodymap Document (draft-ietf-mixer-bodymap-03.txt) Harald pointed out that he and Steve disagree on organization; Steve wants things organized by direction of conversion, whereas Harald wants thing organized more by type. Ned Freed pointed out that there needs to be a clear separation between specification and rationale text. The rationale text absolutely needs to be present, but there needs to be a break between the two. Ned also pointed out that the organization needs to be optimized for implementors. Mark Joseph reemphasized the importance of having prose that clearly explains the rationale behind various choices made in designing the mappings. Harald agreed to try to deal with these issues with better formatting and breaking sections where appropriate. The issue was raised that users should not trust private keys to a gateway, and thus the option of dealing with decrypting multipart/encrypted at the gateway is problematic. Ned pointed out that this option is used when per-user keys are not assigned in lieu of a single gateway key (i.e. a trusted mail gateway). However, this is only viable with the gateway and user systems are within a secure environment. Harald agreed to add text to the document to clarify this point and make sure implementors are aware of the risks involved. Kevin Jordan pointed out that the mapping of content-disposition calls for filenames beginning with "/" be mapped to complete-pathname, which is not part of the EMA profile and may not interoperate with systems conforming to the EMA profile. This is a real issue because the EMA profile calls for tunneling FTBPs containing FTBP fields not listed in the profile. Ned pointed out that while conforming to the EMA profile may be appropriate when converting to X.400 (be conservative in what you emit), it may be appropriate to accept more than EMA calls when converting to X.400 (be liberal in what you accept). Kevin argued that XAPI will only present messages conforming to XAPI in broken out form, which creates a consistency problem in how liberal different implementations can be without duplicating XAPI functionality in the gateway itself (a substantial task). Keith said that this can be dealt with by documenting the limitations of the interface and how gateways should act in their presence. Steve asked whether or not the EMA would be open to suggestions from the MIXER Working group regarding additions MIXER feels are necessary. Various EMA MAWG members present (Ed Owens, Niranj Jain, etc.) indicated that the EMA would probably be open to such suggestions. The issue was then raised as to legacy systems implemented according the extant EMA profile. It was generally felt that timely feedback would minimize the number of such implementations. Harald then suggested, and it was agreed that, the MIXER document will recommend changes as appropriate and these will be referred to the EMA for action. Discussion then turned to the various date and object size parameters. Discussion on the list pointed out the need for these to appear as content- header fields in order to conform to MIME header field naming rules. Ned then commented that these might be better treated as content- disposition parameters because of the inherently "file oriented" nature. Ned also pointed out the problem with the content-disposition RFC only being an experimental protocol, but then noted that MIXER is already using it so this issue exists regardless of how these parameters in particular are mapped. It was agreed that text will be composed defining these parameters and that this material will be passed back to the content-disposition document author Steve Dorner via Pete Resnick (Pete was present at the meeting ,but Steve was not; both work for Qualcomm. It should be noted that the status of the content-disposition document is an issue that transcends the MIXER Working Group-other documents and working groups, including the MacMIME document, the IMAP Working Group, and the possible future HTML-in-e-mail Working Group, have similar problems in this regard.) Discussion then returned to the XAPI issue. Ed Owens pointed out that the specification of the XAPI extension in the EMA FTBP profile is merely a suggestion in an appendix of the EMA MAWG document-it is not normative and that it is really appropriate for XAPIA rather than the EMA to specify this. Steve asked for a number of editorial changes, including the removal of the term "HARPOON" which is used without definition and hence is somewhat confusing. There is also confusion surrounding the use of the term "tunneling" in the context of FTBP. Harald is reluctant to change the latter. Keith Moore agreed to write some prose that attempts to satisfy both Steve and Harald on this point. Harald will try to match Steve's schedule for getting the new draft of the bodypart mapping out. There being no other business, the group adjourned.