Subject: Progress update: negotiation

From: Graham Klyne <[email-masked]>
Date: Tue, 30 Jan 2001 10:57:21 +0000

Folks,

At the last IETF meeting, I agreed to get drafts for negotiation and timely 
delivery ready as candidates for WG last call by the end of this month.

I have just submitted an updated negotiation draft.  Here are the main changes:

   04a  17-Oct-2000  Fix error in description of recipient processing
                     when data is no longer available.

   04b  23-Jan-2001  Define Original-Message-ID header.  Add negotiate-
                     down example.  Flesh out text of IANA
                     considerations, internationalization
                     considerations and security considerations
                     sections.  Write up outstanding implementation
                     issues (NOTE: transient receiver capabilities seem
                     to be addressed rather neatly by A.5).

   04c  29-Jan-2001  Add note to discuss range of alternatives to be
                     disclosed using the Content-alternatives header.

The draft is all there now, but there are some specific points I would like 
to discuss.  One in particular that the authors jointly feel would benefit 
from group discussion has arisen from the late addition of a negotiate-down 
example:  if the sender has an alternative that assumed _lower_ 
capabilities than the version actually sent, should those lower 
capabilities be described explicitly by a Content-alternatives 
header?  When the draft is available, I'll post more details of this 
issue.  Other points regarding which WG revciew is explicitly requested are:

   REVIEW CHECKLIST:

   (Points to be checked more widely on or before final review)

   o  Cache-control for recipient features? (e.g. colour offered for
      selected senders only). (3.2.3)

   o  Check the correct final disposition for lost message data (3.4)

   o  Define Content-alternative in a separate document? (Possibly,
      because it might be used separately from the content negotiation
      framework;  e.g. in a fashion similar to the HTTP vary: header.)
      (4)

   o  Describe interaction between Content-alternative and
      message/partial.  Is the discussion in RFC 2298 section 2.5
      sufficient? (4)

   o  Special considerations for defining composite document
      characteristics (e.g. MRC) in Content-alternative headers? (4)

   o  Add E164 address type for reporting fax offramp disposal?  (6.2)

   o  Discuss the options that should be exposed using Content-
      alternative;  e.g. is it necessary to declare 'baseline'
      capabilities.

#g

------------
Graham Klyne
([email-masked])