Subject: 3028bis: post-meeting changes

From: Philip Guenther <[email-masked]>
Date: Tue, 21 Mar 2006 19:09:46 -0800

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/[email-masked]/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

---

From: Ken Murchison <[email-masked]>
Date: Wed, 22 Mar 2006 10:32:11 -0500

Philip Guenther wrote:
>  ...

These look good to me.

> 3. IANA template

I need to give this some more thought.

-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 22 Mar 2006 13:43:09 -0800

>   ends" would appear in IMAP as "odds &- ends".
I like that.

>    designed to handle large message.
This is intentionally vague, but it is probably Ok with me.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 22 Mar 2006 13:51:37 -0800

>and 'imapflags'), but perhaps the above is an overreaction.
Sounds good to me.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 22 Mar 2006 13:50:30 -0800

>arguments" fields, leaving:
The proposal from the meeting was:
Have a require capability name.
Have a short description of what an extension does.
Have separate lists for all new tests/actions/etc., so that we can avoid 
incompatible action/test/etc. names between multiple extensions.

>review policy for the registry.
I still think have a single true place for listing all actions/tests is 
a good thing.

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 22 Mar 2006 23:05:51 +0100

>    ends" would appear in IMAP as "odds &- ends".

the added text is good, but s/such/so/ ?  (I'm not a native speaker ...)

>     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/)

> 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.

---

From: Ned Freed <[email-masked]>
Date: Wed, 22 Mar 2006 15:54:25 -0800 (PST)

> >   ends" would appear in IMAP as "odds &- ends".

So do I. +1.

> This is intentionally vague, but it is probably Ok with me.

Agree, but s/message./messages./

				Ned