On Tue, 2006-03-21 at 19:09 -0800, Philip Guenther wrote:
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".
the added text is good, but s/such/so/ ? (I'm not a native speaker ...)
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.
if the target is just a plain e-mail account, this sounds like a bizarre
caveat, so perhaps "target service" or "target system" is better to get
into the right context. (also s/message/messages/)
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.
all of these seem like overkill to me.
we could either suggest a version number be part of all capability
names, or we could just say the suffix "" is version 1, and tack on "2",
"3" etc as needed for the next versions. we don't have to be creative
with every new "next generation" capability.
--
Kjetil T.