5322bis

Issue #7 - Trace header field:

Pete:

• multiple existing definitions
• 5322 very general
• 5321 more restrictive

New text is in draft for review

Issue #74 - Received header syntax:

Pete: shows multiple ABNF options

Levine: give up and define as unstructured (option #6) - this follows reality
Klensin: +1 to above - option 6
Alexey: prefers option 2
Ken: don't define any syntax in rfc5322bis and refer to rfc5321bis
Pete: prefers option 1 and 3 (least amount of change) - going to unstructured may to lead to junk being generated by new implementations
Klensin: if we make it more restrictive in 5322 that could lead to rejecting previously valid headers

Back and forth on the merits of change vs no change

Barry & Ken: least change is better
Barry: who else other than SMTP adds this header?
Pete: anti-spam engines

ACTION: John & Pete - keep existing ABNF with comment and craft text

Issue 81 (registry for Trace header fields)?

Alexey: To preframe the discussion: I talked to Graham Klyne and he thought that adding a new column to the Message Header Field Name registry that is trace header field specific is fine.

Pete: use existing Message Header registry (with comment) or new registry?
Barry: new registry would have to be a subset of existing - we should annotate trace headers fields in existing registry
Levine: no new registry.  new column in existing
Alexey: prefer new registry, but can live with a new column in existing
Klensin: no strong preference.  just need to identify Trace header Fields
Ken: +1 to Levine and Barry
Pete: what are the semantics of a new column in existing header?
Alexey: use Ned's definition of Trace, as in the current rfc5321bis-04.

ACTION: extend existing registry - may have to go into 5322bis

5321bis

Klensin: covers recent changes - asks for disagreements on new text be posted on list

Issue #76 - IANA registries for non-Service extensions

• Address Literal Tags
• Proposed IANA procedure: Standards Action
  
• Mail transmission types (VIA and WITH)
  
• Proposed IANA procedure: IETF review (basically what is in the document + allow IETF Stream Informational)
  
• Additional registered clauses
• Proposed IANA procedure: IETF review (basically what is in the document + allow IETF Stream Informational)
  
  

Issue #56 - SMTP extensions registry:

Barry/Alexey: likes new text proposed by John K on the mailing list just before the meeting. Basically it more or less suggests to keep the current registration procedure for SMTP extensions defined in IETF Stream RFC, and also suggests creation of "provisional" (like for URIs) registry with FCFS registration procedure.

ACTION: John and Barry will work on the terminology for "permanent" vs "provisional", and answer other questions about this registry.

A/S

Ken: reviewed recent changes in -06/-07

Issue #78- Advise against using URL %-encoding in non-ASCII email addresses

ACTION: Ken to try and craft some text

Issue #51- HTML ABNF for email addresses

Levine: in favor of just a reference to HTML ABNF
Klensin: would prefer prose rather than ABNF, and also to not normatively reference the HTML document

ACTION: Klensin to craft some suggested text

Issue #38 - 78 octet limit vs 998 line length limit

ACTION: Ken to work with Pete on text