Subject: DRUMS working group meeting minutes

From: Chris Newman <[email-masked]>
Date: Wed, 16 Dec 1998 10:20:36 -0800 (PST)

43 IETF DRUMS working group meeting minutes
Met on Wednesday Dec 9 at 1:00 p.m.

Recorded by: John-Paul Sicotte <[email-masked]>

Agenda
------

Discuss 822bis draft
Discuss 821bis draft
Discuss ABNF   draft
Discuss closure of working group
Discusss what new things people would like to see done in the area of 
      messaging once DRUMS work complete.

822bis
------
Issues with draft-ietf-drums-msg-fmt-06.txt

The postmaster requirement from RFC 822 is no longer in the 822bis spec.  Do we still need 
it?  Consensus is to leave it out and to change the 821bis postmaster reference to be strictly 
internal.

There was a concern about the text describing the proper use of message ids.
Sec 3.6.4 the paragraphs starting 

    'The "Message-ID:" field provides a unique message identifier that refers
to a particular version of a particular message. The uniqueness of the ...'

The complaint was that it confusing with regards to what exactly should 
require a new message id to be used.  It was mentioned that the examples 
given in the text of when to change the message-ids were just examples and that the 
exact mechanisms which require the message id to change need to be 
evaluated on a usage by usage basis.  There is no SYNTACTICAL way of determining
that messages are different and a semantic change needs to be evaluated in 
context to determine if it requires a change in the message id.

Consensus is Pete Resnick will post clarifying text to the list.

It was suggested that the text regarding the use of Re: in section 3.6.5 
was unclear and that Re: should be made a requirement rather than optional. 
This was countered with the statement that the draft already had too many 
SHOULDs/MUSTs which are not required for interoperability.  Group consensus 
was to leave the text alone unless the list could reach consensus on 
replacement text before the end of December.

This draft is currently in working group last call and there was strong 
consensus that these last few changes will be incorporated in to draft 07 
which will then go to IESG last call.

Pete Resnick agreed that January 8th is deadline for 07 publication.

821bis
------

There are still some loose ends in the document.  These have been around 
for quite a while without comment so unless there is rapid list consensus 
the editors will decide.  They will post decisions to list.

The following known loose ends are mentioned in the draft.

- trace fields:  John Klensin has received no comments and unless they come
                 in current text will stand.

- syntax differences with 822 but not with 821
- definitions for link and receipt fields.

A few new issues were brought up.

Section 3.3  - Section needs a bit of clarifying text added.  This will be 
done.

Section 5, Paragraph 4 - "Multiple MX records contain a preference indication that SHOULD be used in
sorting (see below)." Suggestion that SHOULD be changed to MUST.  No objections from the room.  This will 
be changed.

Section 5, Last paragraph - "If it determines that it should relay the message without rewriting the
address, it MUST sort the MX records ..."

The exact concern revolves around the sentence containing the last MUST in the 
paragraph.  There is a conflict between RFC 974 which allows a MAY and 821bis which 
requires MUST.  John Klensin recounted an explanation from one of the RFC 
974 authors that states it was a mistake in RFC 974 and so 821bis 
shouldn't be required to match 974.  People have mentioned that mta's can be configured to 
behave as described in 974.  It was countered that this is bad behaviour.

Summary of problem:
If you go through a list of MX records and none of them can successfully 
be used to route the message, can you then use an A record.  
This is different than finding no MX records and finding an A record. 

There are some options if none of the mx records are 
viable:  you can smart host, bounce the message or use the A record.  Consensus is 
that using the A record is not a good idea, but concern was that people 
may be using this mechinism.  

A records have been used in the past but this may not prevent current restrictions.
It is not the intent of the text in 821 to prohibit smarthosting.  

Rough consensus is this isn't important enough to force a change to the text.
John Klensin wants some people to examine the text to insure that prevention 
of the smart host option is not present or implied.

The small changes brought up will be put into draft 09 before end of IETF 
and this will go to working group last call.

ABNF status
-----------

The current draft is in working group last call.  Dave Crocker 
agreed to have all minor outstanding revisions into a new draft before 
next Friday.  Consensus was that this new draft will go to IESG last call.

Getting working group documents to RFC.
---------------------------------------

There was strong consensus from the group that due to the long duration of 
DRUMS and the extensive review the documents have undergone that 
unnecessary delays should be minimized.

There was strong consensus that, as a point of process, comments, other than straight 
forward editorial changes, require at least 4 visible people with support 
before they will be considered.  Visible means that they themselves bring 
up or show support for a point; they can't just be mentioned.

What to do after DRUMS?
-----------------------

This was an opportunity for people to discuss things in the messaging area 
that they would like to see done after the DRUMS working group is 
shutdown.  Some of the following minutes are done in a stream of 
consciousness style because that is the way the discussion was going.  
This section of the meeting was used to throw out ideas and judge 
peoples' interest.

Summary of MAILCAP by Keith Moore
----------------------------------

The problem: You have a mail address and want to get information about it.

- Can they accept color? Multipart/Alternative?  
- Language, charset, UA Capability
- Security supported with keys or URL's to keys.
- other ways to contact this person like voice address (Suggestion was 
	that this point may be out of scope.)

This is intended to allow the sender to discover what is legal before a 
message is sent.  The same problem exists when you have a phone number or
a URI and want information on them.

Proposed plan is to have separate group (ENUM) to do phone numbers.
URIs and EMAIL addresses would fall under MAILCAP.

Some stuff has been done with the URI problem (NAPTR/SRV)
Schema definition is not meant to be part of the scope.  Although 
registration procedures could be done.   There was a security concern 
mentioned about the potential to use this service to discover information 
about what email addresses are valid.  There was also some discussion on 
the types of solutions for this problem.

A draft charter has been made.  Chairs are chosen and a mailing list is 
operational. Send mail to <[email-masked]> to join the list. 
The charter has not yet been circulated.

Revision of Delivery Status Notifications
-----------------------------------------
Suggestion is that we should look at this with the possibility of re-forming 
the Notification Working Group.    One perception was that we have fairly wide deployment 
of the server support but few clients.  A counter statement was made that 
there are bugs in implementations that are not being exposed because of 
lack of use of the service.  Can this problem be fixed with a working group or better 
by someone like the IMC with an interoperability event like MailConnect.  Suggested informational document 
on client uses of DSN.  Did we solve a problem which doesn't exist or did 
we solve it the wrong way?  

Are positive acknowledgements of delivery useful?  Are these only for 
diagnostic purposes?   One of the powers of these is that they 
could be dealt with by software.  FAX community does expect the use of 
these, including positive acknowledgements.  We need to consider that there may be 
classes of mail, like there is in the paper world, that 
may make use of DSNs (e.g. registered mail).

Routing Slips
-------------

Routing slips are used to route a piece of mail sequentially through a 
list of address rather than to all of the address at once.  This is useful 
for "workflow" type problems.  For example if you have a purchase order 
which first has to go to your boss, then to his boss and then to the President 
before you get approval.

One problem mentioned was that you can't really send these out without 
knowledge that all members can handle this or the messages get dropped.

821 recipient list extension
----------------------------
One of RFC821's limits is that you can place at most 100 recipients on
one line.  Removing this limit could be done as an extension to  EHLO.  
Suggestion was that this could be proposed through an individually 
submitted draft.

Several small issues
--------------------
- Work on support for server to server authentication
- Loop Control
- Mailing lists
- Filtering 
- The issue of security when applications are sent inside mail

Randy Gellens takes photo of the group.
Round of applause for Chair and Editors.
Meeting adjourned.

---

From: Jacob Palme <[email-masked]>
Date: Fri, 18 Dec 1998 04:32:16 +0100

> replacement text before the end of December.

My memory was that we decided to recommend against
translation of "Re: " to other languages, like "An: " in
German. My suggested added text for this is the following:

    If a user interface uses another language than English, and
    translates "Re: " to another language, like "An: " in
    German, then this must be translated to "Re: " when sending
    messages, just like the names of e-mail headers must always
    be in English when messages are sent.
------------------------------------------------------------------------
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme

---

From: Pete Resnick <[email-masked]>
Date: Thu, 17 Dec 1998 22:14:47 -0600

On 12/18/98 at 4:32 AM +0100, Jacob Palme wrote:
>> Group consensus was to leave the text alone unless the list could 
>> reach consensus on replacement text before the end of December.

This was my recollection as well.
> German.

I do not remember that being the consensus of the room, though the 
discussion was rather short.

> My suggested added text for this is the following:

The current document says in section 3.6.5:

        When used in a reply, the field body MAY start with the string
        "Re: " (from the Latin "res", in the matter of) followed by the
        contents of the "Subject:" field body of the original message.

And then in the examples section A.2:

        When sending replies, the Subject field is often retained, though
        prepended with "Re: " as described in section 3.6.5.

This is followed by examples of a reply, and a reply to a reply, each 
using the literal "Re: ".

I think this quite sufficient to mean "the literal string 'Re: ' and 
nothing else" and is as strong as we want the text to get. In no 
event am I happy with the suggested text that includes words like 
"user interfaces"; there are already a few too many of those sorts of 
things in the document now for my liking.

If there is some consensus out there to add something, please speak up now.

pr
--
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated
Work: (217)337-6377 or (619)651-4478
Fax: (217)337-1980 or (619)651-1102

---

From: Randall Gellens <[email-masked]>
Date: Fri, 18 Dec 1998 18:35:41 -0800

> If there is some consensus out there to add something, please speak up now.

I thought there was some consensus on the list for adding a small bit 
of text to clarify that using anything other than "Re: " is harmful. 
Something like

Note that only the literal string "Re: " should be used, any other 
sequence leads to undesirable consequences, such as "Re: An: Re: An: 
Lunch"

---

From: [email-masked] (Kai Henningsen)
Date: 19 Dec 1998 17:55:00 +0200

> sequence leads to undesirable consequences, such as "Re: An: Re: An:

Just to remind people that the awful German translation is AW:, not An:.  
(Actually, both are extremely non-intuitive to German speakers. A  
*correct* translation, as in that's what's used in paper mail, would have  
been "Betr.:" or something along those lines, though that's nearly the  
same as "Subject:". Not that it matters much, since we don't want it  
anyway.)

MfG Kai

---

From: Jacob Palme <[email-masked]>
Date: Sat, 19 Dec 1998 18:20:44 +0100

> sequence leads to undesirable consequences, such as "Re: An: Re: An:

I know that people do not like mentioning the user interface,
but some implementors may wrongly assume that this also
applies to the user interface. Perhaps one could write:

   'only the literal string "Re: " should be used in the
   protocol sent on the wire'.

Then nothing is explicitly said about the user interface,
but readers will still understand that the "Re: "
requirement only applies to what is sent between agents,
not to what is shown to the users.
------------------------------------------------------------------------
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme

---

From: Pete Resnick <[email-masked]>
Date: Sat, 19 Dec 1998 11:45:36 -0600

On 12/19/98 at 6:20 PM +0100, Jacob Palme wrote:

> applies to the user interface.

If an implementer is unable to read and understand the "Note:" 
paragraph in section 1.1, perhaps it is better that he put "Re: " in 
the user interface to prevent it from leaking out onto the net.

I am not at all in support of Jacob's text. I am ambivalent about 
Randy's text, but would put it (or something similar) in with further 
support from the WG.

pr

---

From: John Beck <[email-masked]>
Date: Sat, 19 Dec 1998 10:07:06 -0800

Pete> If there is some consensus out there to add something, please speak up
Pete> now.

Randy> I thought there was some consensus on the list for adding a small bit 
Randy> of text to clarify that using anything other than "Re: " is harmful. 
Randy> Something like

Randy> Note that only the literal string "Re: " should be used, any other 
Randy> sequence leads to undesirable consequences, such as "Re: An: Re: An: 
Randy> Lunch"

Jacob> I know that people do not like mentioning the user interface,
Jacob> but some implementors may wrongly assume that this also
Jacob> applies to the user interface. Perhaps one could write:

Jacob>    'only the literal string "Re: " should be used in the
Jacob>    protocol sent on the wire'.

Pete> I am not at all in support of Jacob's text.

Neither am I.

Pete> I am ambivalent about Randy's text, but would put it (or something
Pete> similar) in with further support from the WG.

I support Randy's suggestion.

-- John

---

From: [email-masked] (Kai Henningsen)
Date: 20 Dec 1998 00:50:00 +0200

> Randy> sequence leads to undesirable consequences, such as "Re: An: Re: An:

Pete>> I am ambivalent about Randy's text, but would put it (or something
Pete>> similar) in with further support from the WG.

> I support Randy's suggestion.

Same here.

MfG Kai