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.