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