ietf-mta-filters
[Top] [All Lists]

3028bis: post-meeting changes

2006-03-21 20:37:05


These are in response to the discussions earlier today in Dallas.
The log of the jabber room can be found at:
        
http://www.ietf.org/meetings/ietf-logs/sieve(_at_)rooms(_dot_)jabber(_dot_)ietf(_dot_)org/2006-03-21.html


Opinions on any of the following, whether yeah or nay, are appreciated,
especially on the last point.


1. The first paragraph of section 4.1 ("Action fileinto") now reads:

   The "fileinto" action delivers the message into the specified folder.
   Implementations SHOULD support fileinto, but in some environments
   this may be impossible.  Implementations MAY place restrictions on
   folder names; use of an invalid folder name MAY be treated as an
   error or result in delivery to an implementation-defined folder.  If
   the implementation uses a different encoding scheme than UTF-8 for
   folder names, it SHOULD reencode the folder name from UTF-8 to its
   encoding scheme.  For example, the Internet Message Access Protocol
   [IMAP] uses modified UTF-7, such that a folder argument of "odds &
   ends" would appear in IMAP as "odds &- ends".

(Hmm, need to tweak the line wrap...)


2. In the Security Considerations section, I've added:

    Use of the "redirect" command to generate notifications may
    easily overwhelm the target address, especially if it was not
    designed to handle large message.


3. IANA template

I think we should simply drop the "Capability name" and "Capability
arguments" fields, leaving:

   Capability keyword:
   Standards Track/IESG-approved experimental RFC number:
   Person and email address to contact for further information:

As I see it, there are two major concerns for the registry:
 1) capabilities should be unique, so that require "foo" has the
    same meaning everywhere it works
 2) given a standardized capability, you need to be able to find
    the current RFC describing it

Concerns about different capabilities enabling the same action or
test are better addressed, IMHO, by reexamining the naming and
review policy for the registry.

For example, perhaps we should
1) adjust the vendor namespace rules to instead be FCFS registration
   of trees ("vnd.acme.*"),
2) break out a namespace for draft extensions (ala Alexey's
   "X-DRAFT-[IW]#-name" proposal for IMAP extension drafts), and
3) switch the rest of the namespace from FCFS to Specification
   required or IETF Consensus (c.f. RFC 2434)

I included (2) because we've had problems with extensions that saw
significant change after a long period of statis (e.g., 'notify'
and 'imapflags'), but perhaps the above is an overreaction.


Thoughts?


Philip Guenther

<Prev in Thread] Current Thread [Next in Thread>