Subject: I-D Action:draft-daboo-imap-annotatemore-13.txt (fwd)
From: Cyrus Daboo <[email-masked]>
To: IMAPEXT <[email-masked]>, Lemonade <[email-masked]>
Date: Tue, 22 Apr 2008 09:52:18 -0400
List-Id: <ietf-imapext.imc.org>

Hi folks,
I have posted a new version of the METADATA extension. This is undergone 
some major changes following discussions of simplification last month. The 
key changes are the removal of the LIST-EXTENDED dependency, and the 
removal of attributes from the data model. Please review.

------------ Forwarded Message -----------
Date: April 21, 2008 7:45:02 PM -0700
From: [email-masked]
To: [email-masked]
Subject: I-D Action:draft-daboo-imap-annotatemore-13.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : IMAP METADATA Extension
	Author(s)       : C. Daboo
	Filename        : draft-daboo-imap-annotatemore-13.txt
	Pages           : 21
	Date            : 2008-04-21

---------- End Forwarded Message ----------

-- 
Cyrus Daboo

Date: Wed, 9 Apr 2008 10:29:47 -0700
From: Mark Crispin <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: IMAP Extensions <[email-masked]>
Subject: Re: Last work item - ACL2?
Organization: Networks & Distributed Computing
Sender: [email-masked]

IMHO, ACL2 should be dropped.

As currently constituted, ACL2 does not address my issues.

There needs to be a means to export a simpler form of access control in 
IMAP, such as provided by a filesystem.  The IMAP ACL framework does not 
offer this capability, and it's become painfully apparent that attempts to 
make the ACL framework do so only make matters worse.

I think that a more productive course, *outside* of IMAPEXT, would be the 
following:

I define a generic specification for access control that sets "read" and 
"write" access for "owner", "group", and "world"; along with a way to "set 
owner", "set/add group".

Alexey, Chris, and any other interested parties define an informational 
RFC that describes how a server that implements both ACL and the simpler 
access control specification should map the two.

Alexey, Chris, and any other interested parties consider a simplified 
version of ACL that deletes tied rights and other features that attempted 
to accomodate filesystem semantics.  The result is that a server that 
implements ACL is required to implement the One True Way of ACL.

The long term view is to make the simpler form mandatory to implement for 
all servers, at least to the point of locking in read-write for owner and 
no-access for world.  ACL would not be mandatory to implement, but with a 
single True Form for ACL would be more likely to be implemented.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Cc: Pete Resnick <[email-masked]>, IMAP Extensions <[email-masked]>
From: Timo Sirainen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: Last work item - ACL2?
Date: Wed, 9 Apr 2008 20:21:45 +0300
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-30--326244318
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

On Apr 9, 2008, at 7:52 PM, Alexey Melnikov wrote:

> If there are at least 3 other people who want to work on ACL2, I  
> would be happy to revive the document and do it as an individual  
> submission.

I'm having doubts that there even is a need for a standard ACL  
protocol. There most likely will be ACL features in servers that can't  
easily be added to a standard, so using those features can't be done  
via (standard) IMAP anyway.

--Apple-Mail-30--326244318
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-30--326244318--

Date: Wed, 09 Apr 2008 17:52:03 +0100
From: Alexey Melnikov <[email-masked]>
To: Pete Resnick <[email-masked]>
CC: IMAP Extensions <[email-masked]>
Subject: Re: Last work item - ACL2?
Sender: [email-masked]

Pete Resnick wrote:

> Now that everything is in the RFC Editor Queue, officially we have one 
> last work item on our charter: ACL2. We and the IESG agreed that we 
> might decide to drop this or bring it to a new working group if we 
> thought it was going to be stuck.
>
> What say the group?

Our current milestones say:

May 2008 	   	New draft of ACL2 proposal which would *obsolete* existing 
ACL RFC
Jul 2008 	   	ACL2 to WG Last Call--note that if this milestone is not 
met we agreed to close the WG and defer ACL2 to another WG

Clearly the milestone in May 2008 was missed.

So, speaking as an individual contributor, I think this WG is done and 
we shouldn't do anything on ACL2.

If there are at least 3 other people who want to work on ACL2, I would 
be happy to revive the document and do it as an individual submission.

Date: Wed, 9 Apr 2008 11:23:55 -0500
To: IMAP Extensions <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Last work item - ACL2?
Sender: [email-masked]

Now that everything is in the RFC Editor Queue, officially we have 
one last work item on our charter: ACL2. We and the IESG agreed that 
we might decide to drop this or bring it to a new working group if we 
thought it was going to be stuck.

What say the group?

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Tue, 8 Apr 2008 10:53:14 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Russ Housley <[email-masked]>
cc: Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Protocol Action: 'INTERNET MESSAGE ACCESS PROTOCOL - SORT  AND THREAD EXTENSIONS' to Proposed Standard
Organization: UW Technology
Sender: [email-masked]

Bob:

As the author in question, I assert that nobody EVER stated the existence 
of any such "norm" to me.

I indeed copied RFC 822's form in the earliest IMAP RFC and retained it. 
In reviewing the titles of the RFCs that I have written I see no 
consistent application of case.  Some are all-upper, others are title. 
The all-upper ones apparently began with a stripped down form of the IMAP 
RFC used as a template.

Not only don't I care what case is used, I assert that the application of 
a standardized case for RFC titles is an RFC Editor function, *IF* there 
is such a standard.  Is there?  If not, why not?

The matter is not worth raising with ietf-imapext, iab, or imapext-chairs. 
It may be worth raising with rfc-editor.

Last, and certainly least: as someone who was frequently stuck behind a 
Model 33 or 35 Teletype prior to 1977, and in later years used early 
personal computers with no lowercase capability, I object to the comment 
about "network-illiterate Big Iron users".  Some people who sent all-caps 
messages had no choice.

On Tue, 8 Apr 2008, Russ Housley wrote:
>
> Bob:
>
> I am not pushing for one or the other for this document.  I'm simply pointing 
> out that the authors used the same title case as the document that is being 
> updated.
>
> Russ
>
> At 01:39 PM 4/7/2008, Bob Braden wrote:
>
>
>>   *>
>>   *> See RFC 3501
>>   *>
>> 
>> Russ,
>> 
>> I am trying to figure out whether you are serious.  Of course, there
>> have been individual failures in the past.  In fact, 821 or 822 (I foreget
>> which) was a title-case failure.  But the existence of an occasional
>> error does not seem to justify deliberately doing it wrong in the
>> future.  (I will have to admit to a certain bias... upper-cased
>> titles remind me of the days when network-illiterate Big Iron
>> users would sometimes send all-caps messages to the Internet.)  It
>> is generally agreed, I believe, that some reasonable uniformity of
>> style is desirable in the RFC series.  And the title appears in the
>> index and a dumb-looking title stands out as a wierdness.
>> 
>> Bob Braden
>>
>>   *> At 05:27 PM 4/3/2008, Bob Braden wrote:
>>   *>
>>   *>
>>   *> >   *> The IESG has approved the following document:
>>   *> >   *>
>>   *> >   *> - 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD 
>> EXTENSIONS '
>>   *> >   *>    <draft-ietf-imapext-sort-20.txt> as a Proposed Standard
>>   *> >   *>
>>   *> >
>>   *> >Why is this document shouting at us?  Title case is the norm for
>>   *> >RFCs.
>>   *> >
>>   *> >RFC Editor/bb
>>   *> >
>>   *> >  *> Two simple/optional improvements:
>>   *> >   *> Add a normative reference to STD 63 (RFC3629) for UTF-8.
>>   *> >   *> Instead of allowing any 8-bit in BLOBCHAR and NONWSP,
>>   *> > reference the rules
>>   *> >   *> in RFC 3629 for well-formed UTF-8 (UTF8-2, UTF8-3, UTF8-4).
>>   *> >   *>
>>   *>
>
>

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 08 Apr 2008 10:39:06 -0400
To: Bob Braden <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Protocol Action: 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS' to Proposed Standard
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Bob:

I am not pushing for one or the other for this document.  I'm simply 
pointing out that the authors used the same title case as the 
document that is being updated.

Russ

At 01:39 PM 4/7/2008, Bob Braden wrote:

>   *>
>   *> See RFC 3501
>   *>
>
>Russ,
>
>I am trying to figure out whether you are serious.  Of course, there
>have been individual failures in the past.  In fact, 821 or 822 (I foreget
>which) was a title-case failure.  But the existence of an occasional
>error does not seem to justify deliberately doing it wrong in the
>future.  (I will have to admit to a certain bias... upper-cased
>titles remind me of the days when network-illiterate Big Iron
>users would sometimes send all-caps messages to the Internet.)  It
>is generally agreed, I believe, that some reasonable uniformity of
>style is desirable in the RFC series.  And the title appears in the
>index and a dumb-looking title stands out as a wierdness.
>
>Bob Braden
>
>   *> At 05:27 PM 4/3/2008, Bob Braden wrote:
>   *>
>   *>
>   *> >   *> The IESG has approved the following document:
>   *> >   *>
>   *> >   *> - 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD 
> EXTENSIONS '
>   *> >   *>    <draft-ietf-imapext-sort-20.txt> as a Proposed Standard
>   *> >   *>
>   *> >
>   *> >Why is this document shouting at us?  Title case is the norm for
>   *> >RFCs.
>   *> >
>   *> >RFC Editor/bb
>   *> >
>   *> >  *> Two simple/optional improvements:
>   *> >   *> Add a normative reference to STD 63 (RFC3629) for UTF-8.
>   *> >   *> Instead of allowing any 8-bit in BLOBCHAR and NONWSP,
>   *> > reference the rules
>   *> >   *> in RFC 3629 for well-formed UTF-8 (UTF8-2, UTF8-3, UTF8-4).
>   *> >   *>
>   *>

Date: Fri, 04 Apr 2008 12:12:06 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Russ Housley <[email-masked]>, Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Protocol Action: 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS' to Proposed Standard
Sender: [email-masked]

Mark Crispin wrote:

>
> The author of the document(s) in question hereby states his complete
> lack of concern as to whether the title of the published RFC is
> uppercase or titlecase. He was doing nothing other than following past
> precedents; and those precedents that he used were all uppercase.
>
> Of greater concern to the author is the BLOBCHAR/NONWSP issue. I have
> already contacted Chris Newman on this matter. This change can be
> interpreted as imposing a mandate on IMAP server implementations that
> does not currently exist; arguably conflicts with RFC 5051; and in
> real life is moot due to external specifications (RFC 2822 among
> others). Due to the last point, a string that triggers this rule is an
> invalid string.
>
> With Chris' permission, I request that this particular RFC Editor note
> either be waived or be made as a documentation suggestion only.

Speaking as an individual: +1.

According to <https://datatracker.ietf.org/idtracker/ballot/1157/> Chris
agreed with this and he updated his comment to only mention adding the
reference to RFC 3629.

> On Thu, 3 Apr 2008, Russ Housley wrote:
>
>>
>> See RFC 3501
>>
>> At 05:27 PM 4/3/2008, Bob Braden wrote:
>>
>>> *> The IESG has approved the following document:
>>> *>
>>> *> - 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS '
>>> *> <draft-ietf-imapext-sort-20.txt> as a Proposed Standard
>>> *>
>>>
>>> Why is this document shouting at us? Title case is the norm for
>>> RFCs.
>>>
>>> RFC Editor/bb
>>>
>>> *> Two simple/optional improvements:
>>> *> Add a normative reference to STD 63 (RFC3629) for UTF-8.
>>> *> Instead of allowing any 8-bit in BLOBCHAR and NONWSP, reference
>>> the rules
>>> *> in RFC 3629 for well-formed UTF-8 (UTF8-2, UTF8-3, UTF8-4).
>>> *>
>>

Date: Thu, 3 Apr 2008 15:06:45 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Russ Housley <[email-masked]>
cc: Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Protocol Action: 'INTERNET MESSAGE ACCESS PROTOCOL - SORT  AND THREAD EXTENSIONS' to Proposed Standard
Sender: [email-masked]

The author of the document(s) in question hereby states his complete lack 
of concern as to whether the title of the published RFC is uppercase or 
titlecase.  He was doing nothing other than following past precedents; and 
those precedents that he used were all uppercase.

Of greater concern to the author is the BLOBCHAR/NONWSP issue.  I have 
already contacted Chris Newman on this matter.  This change can be 
interpreted as imposing a mandate on IMAP server implementations that does 
not currently exist; arguably conflicts with RFC 5051; and in real life is 
moot due to external specifications (RFC 2822 among others).  Due to the 
last point, a string that triggers this rule is an invalid string.

With Chris' permission, I request that this particular RFC Editor note 
either be waived or be made as a documentation suggestion only.

On Thu, 3 Apr 2008, Russ Housley wrote:
>
> See RFC 3501
>
> At 05:27 PM 4/3/2008, Bob Braden wrote:
>
>
>>   *> The IESG has approved the following document:
>>   *>
>>   *> - 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS '
>>   *>    <draft-ietf-imapext-sort-20.txt> as a Proposed Standard
>>   *>
>> 
>> Why is this document shouting at us?  Title case is the norm for
>> RFCs.
>> 
>> RFC Editor/bb
>>
>>  *> Two simple/optional improvements:
>>   *> Add a normative reference to STD 63 (RFC3629) for UTF-8.
>>   *> Instead of allowing any 8-bit in BLOBCHAR and NONWSP, reference the 
>> rules
>>   *> in RFC 3629 for well-formed UTF-8 (UTF8-2, UTF8-3, UTF8-4).
>>   *>
>
>

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Thu, 03 Apr 2008 17:44:09 -0400
To: Bob Braden <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Protocol Action: 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS' to Proposed Standard
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

See RFC 3501

At 05:27 PM 4/3/2008, Bob Braden wrote:

>   *> The IESG has approved the following document:
>   *>
>   *> - 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS '
>   *>    <draft-ietf-imapext-sort-20.txt> as a Proposed Standard
>   *>
>
>Why is this document shouting at us?  Title case is the norm for
>RFCs.
>
>RFC Editor/bb
>
>  *> Two simple/optional improvements:
>   *> Add a normative reference to STD 63 (RFC3629) for UTF-8.
>   *> Instead of allowing any 8-bit in BLOBCHAR and NONWSP, 
> reference the rules
>   *> in RFC 3629 for well-formed UTF-8 (UTF8-2, UTF8-3, UTF8-4).
>   *>

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, imapext mailing list <[email-masked]>, imapext chair <[email-masked]>
Subject: Protocol Action: 'INTERNET MESSAGE ACCESS PROTOCOL -  SORT AND THREAD EXTENSIONS' to Proposed Standard 
Date: Thu,  3 Apr 2008 12:03:23 -0700 (PDT)
Sender: [email-masked]

The IESG has approved the following document:

- 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS '
   <draft-ietf-imapext-sort-20.txt> as a Proposed Standard

This document is the product of the Internet Message Access Protocol 
Extension Working Group. 

The IESG contact persons are Lisa Dusseault and Chris Newman.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-20.txt

Technical Summary
 
   This document describes the base-level server-based sorting and
   threading extensions to the IMAP protocol.  These extensions
   provide substantial performance improvements for IMAP clients which
   offer sorted and threaded views.
 
Working Group Summary
 
   This document is a product of the IMAPEXT working group.
 
Protocol Quality
 
   This has gone completely back through the system due to the long time
delay while the standards around a comparator registry and IMAP i18n 
were written.  The proposal has not changed much in approach, but the 
context has changed. 

   Ned Freed (first pass) and Lisa Dusseault (second pass) reviewed the
specification for the IESG.

Note to RFC Editor

Two simple/optional improvements:
Add a normative reference to STD 63 (RFC3629) for UTF-8.
Instead of allowing any 8-bit in BLOBCHAR and NONWSP, reference the rules
in RFC 3629 for well-formed UTF-8 (UTF8-2, UTF8-3, UTF8-4).

Date: Wed, 02 Apr 2008 09:39:06 -0400
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: OT: Conference on Email and Anti-Spam final call for papers
Sender: [email-masked]

This seems sufficiently on-topic for this list:
The 2008 Conference on Email and Anti-Spam submission deadline is approaching,=20
and has been extended by a week, to 10 April.  If you have any work to report on=20
in the area of Internet messaging abuse and its prevention =E2=80=94 not limited =
to=20
email spam; see the topic list in the CfP, below =E2=80=94 please form it into a =
paper=20
by next week, and submit it.

Barry

----------------------------------------------------------------------
      THE FIFTH CONFERENCE ON EMAIL AND ANTI-SPAM (CEAS 2008)

            Thursday August 21 and Friday August 22, 2008
                   Microsoft Research Silicon Valley
                      Mountain View, California
                        <http://www.ceas.cc>

                       FINAL CALL FOR PAPERS

The Conference on Email and Anti-Spam (CEAS) invites the submission
of papers for its fifth meeting. Papers are invited on all aspects of
electronic communication including email, instant messaging, text
messaging, and voice over internet protocol (VoIP). Topics of interest
include novel applications of electronic messaging, abatement of abuses
of electronic messaging, spam, spit (spam over internet telephony), spim
(spam over instant messenger), phishing, identity theft via messaging,
viruses, and spyware.

Paper submissions can be either research papers, extended abstracts,
industry reports, or law and policy papers. Submissions from
practitioners and vendors are encouraged. Papers will be selected by
peer review for presentation at CEAS 2008. Papers will be reviewed based
on their contribution to the literature.

SUGGESTED TOPICS:

*  Message filtering, blocking, authentication
   -  Machine learning
   -  Natural language processing
   -  Adversarial learning
   -  Challenge-response
   -  Payment schemes
   -  Disposable addresses
   -  Messaging protocols
   -  Digital signatures
*  Evaluation
   - Corpus and benchmark creation
   - Measures and methodologies
   - Comparative tests of methods or products
*  Analysis
   - Economics of spam, spit, spim, phishing, etc.
   - Abuse tactics and patterns
   - Legitimate use patterns
   - Historical data
*  Message organization and search
   - Advanced calendaring and scheduling
   - Automatic foldering
   - Automatic routing
   - Summarization
   - Search
*  Systems and network issues
   - Performance & scalability
   - Reliability & security
   - Archival & retrieval
*  User issues
   - User interfaces
   - Usability studies
   - Messaging in support of user activities
*  Social issues
   - Deducing social networks
   - Costs and benefits of messaging use and abuse
   - Other social impacts
*  Industry
   - Cooperation for stopping abuse
   - Messaging and abuse reporting standards
   - Interoperability
*  Legal issues
   - Spam, spit, spim and phishing, etc.
   - Identity theft
   - Privacy
   - Freedom of speech
   - Digital rights management

KEY DATES:

*  Submission deadline: April 10, 2008 (10:59pm UTC) -- EXTENDED DATE
*  Notification of acceptance: June 6, 2008.
*  Final camera-ready version of papers: June 21, 2008
*  Conference: August 21 and 22, 2008

REQUIREMENTS:

Papers may be of one of two types:
*  Extended abstracts (up to 2 pages) may outline work in progress,
   exceptional papers published for different scientific communities,
   original research, or industry reports.
*  Full papers (up to 10 pages). Work may not have been previously
   published in, or under consideration for publication in any other
   conference or journal.

Submissions must use the CEAS electronic system at:
https://cmt.research.microsoft.com/CEAS2008/. The style for
submissions and final papers is a two-column, 8.5 by 11 inch format. See
http://www.ceas.cc/2008/format.htm for details.

Papers will be reviewed by a committee of experts from academic and
industrial research centers. Accepted papers will be made freely
available on the web, and will be published on CD-ROM. Authors will
retain copyright of their work.

CONTACT:

*  The conference chair and co-chairs can be reached at
   [email-masked]

CEAS PRESIDENT

*  Gordon Cormack
   University of Waterloo
   http://plg.uwaterloo.ca/~gvcormac/

GENERAL CONFERENCE CHAIR:

*  Aleksander Kolcz
   Microsoft Live Labs
   http://ir.iit.edu/~alek/

PROGRAM CO-CHAIRS:

*  Andrej Bratko
   Jozef Stefan Institute
   http://ai.ijs.si/andrej/

*  Barry Leiba
   IBM Research
   http://www.research.ibm.com/people/l/leiba/

*  Tobias Scheffer
   Max Planck Institute for Computer Science
   http://www.mpi-inf.mpg.de/~scheffer/
----------------------------------------------------------------------

Date: Tue, 22 Apr 2008 09:52:18 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAPEXT <[email-masked]>, Lemonade <[email-masked]>
Subject: I-D Action:draft-daboo-imap-annotatemore-13.txt  (fwd)
Sender: [email-masked]

Hi folks,
I have posted a new version of the METADATA extension. This is undergone 
some major changes following discussions of simplification last month. The 
key changes are the removal of the LIST-EXTENDED dependency, and the 
removal of attributes from the data model. Please review.

------------ Forwarded Message -----------
Date: April 21, 2008 7:45:02 PM -0700
From: [email-masked]
To: [email-masked]
Subject: I-D Action:draft-daboo-imap-annotatemore-13.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : IMAP METADATA Extension
	Author(s)       : C. Daboo
	Filename        : draft-daboo-imap-annotatemore-13.txt
	Pages           : 21
	Date            : 2008-04-21

---------- End Forwarded Message ----------

-- 
Cyrus Daboo

Date: Wed, 9 Apr 2008 10:29:47 -0700
From: Mark Crispin <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: IMAP Extensions <[email-masked]>
Subject: Re: Last work item - ACL2?
Organization: Networks & Distributed Computing
Sender: [email-masked]

IMHO, ACL2 should be dropped.

As currently constituted, ACL2 does not address my issues.

There needs to be a means to export a simpler form of access control in 
IMAP, such as provided by a filesystem.  The IMAP ACL framework does not 
offer this capability, and it's become painfully apparent that attempts to 
make the ACL framework do so only make matters worse.

I think that a more productive course, *outside* of IMAPEXT, would be the 
following:

I define a generic specification for access control that sets "read" and 
"write" access for "owner", "group", and "world"; along with a way to "set 
owner", "set/add group".

Alexey, Chris, and any other interested parties define an informational 
RFC that describes how a server that implements both ACL and the simpler 
access control specification should map the two.

Alexey, Chris, and any other interested parties consider a simplified 
version of ACL that deletes tied rights and other features that attempted 
to accomodate filesystem semantics.  The result is that a server that 
implements ACL is required to implement the One True Way of ACL.

The long term view is to make the simpler form mandatory to implement for 
all servers, at least to the point of locking in read-write for owner and 
no-access for world.  ACL would not be mandatory to implement, but with a 
single True Form for ACL would be more likely to be implemented.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Cc: Pete Resnick <[email-masked]>, IMAP Extensions <[email-masked]>
From: Timo Sirainen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: Last work item - ACL2?
Date: Wed, 9 Apr 2008 20:21:45 +0300
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-30--326244318
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

On Apr 9, 2008, at 7:52 PM, Alexey Melnikov wrote:

> If there are at least 3 other people who want to work on ACL2, I  
> would be happy to revive the document and do it as an individual  
> submission.

I'm having doubts that there even is a need for a standard ACL  
protocol. There most likely will be ACL features in servers that can't  
easily be added to a standard, so using those features can't be done  
via (standard) IMAP anyway.

--Apple-Mail-30--326244318
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-30--326244318--

Date: Wed, 09 Apr 2008 17:52:03 +0100
From: Alexey Melnikov <[email-masked]>
To: Pete Resnick <[email-masked]>
CC: IMAP Extensions <[email-masked]>
Subject: Re: Last work item - ACL2?
Sender: [email-masked]

Pete Resnick wrote:

> Now that everything is in the RFC Editor Queue, officially we have one 
> last work item on our charter: ACL2. We and the IESG agreed that we 
> might decide to drop this or bring it to a new working group if we 
> thought it was going to be stuck.
>
> What say the group?

Our current milestones say:

May 2008 	   	New draft of ACL2 proposal which would *obsolete* existing 
ACL RFC
Jul 2008 	   	ACL2 to WG Last Call--note that if this milestone is not 
met we agreed to close the WG and defer ACL2 to another WG

Clearly the milestone in May 2008 was missed.

So, speaking as an individual contributor, I think this WG is done and 
we shouldn't do anything on ACL2.

If there are at least 3 other people who want to work on ACL2, I would 
be happy to revive the document and do it as an individual submission.

Date: Wed, 9 Apr 2008 11:23:55 -0500
To: IMAP Extensions <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Last work item - ACL2?
Sender: [email-masked]

Now that everything is in the RFC Editor Queue, officially we have 
one last work item on our charter: ACL2. We and the IESG agreed that 
we might decide to drop this or bring it to a new working group if we 
thought it was going to be stuck.

What say the group?

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Tue, 8 Apr 2008 10:53:14 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Russ Housley <[email-masked]>
cc: Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Protocol Action: 'INTERNET MESSAGE ACCESS PROTOCOL - SORT  AND THREAD EXTENSIONS' to Proposed Standard
Organization: UW Technology
Sender: [email-masked]

Bob:

As the author in question, I assert that nobody EVER stated the existence 
of any such "norm" to me.

I indeed copied RFC 822's form in the earliest IMAP RFC and retained it. 
In reviewing the titles of the RFCs that I have written I see no 
consistent application of case.  Some are all-upper, others are title. 
The all-upper ones apparently began with a stripped down form of the IMAP 
RFC used as a template.

Not only don't I care what case is used, I assert that the application of 
a standardized case for RFC titles is an RFC Editor function, *IF* there 
is such a standard.  Is there?  If not, why not?

The matter is not worth raising with ietf-imapext, iab, or imapext-chairs. 
It may be worth raising with rfc-editor.

Last, and certainly least: as someone who was frequently stuck behind a 
Model 33 or 35 Teletype prior to 1977, and in later years used early 
personal computers with no lowercase capability, I object to the comment 
about "network-illiterate Big Iron users".  Some people who sent all-caps 
messages had no choice.

On Tue, 8 Apr 2008, Russ Housley wrote:
>
> Bob:
>
> I am not pushing for one or the other for this document.  I'm simply pointing 
> out that the authors used the same title case as the document that is being 
> updated.
>
> Russ
>
> At 01:39 PM 4/7/2008, Bob Braden wrote:
>
>
>>   *>
>>   *> See RFC 3501
>>   *>
>> 
>> Russ,
>> 
>> I am trying to figure out whether you are serious.  Of course, there
>> have been individual failures in the past.  In fact, 821 or 822 (I foreget
>> which) was a title-case failure.  But the existence of an occasional
>> error does not seem to justify deliberately doing it wrong in the
>> future.  (I will have to admit to a certain bias... upper-cased
>> titles remind me of the days when network-illiterate Big Iron
>> users would sometimes send all-caps messages to the Internet.)  It
>> is generally agreed, I believe, that some reasonable uniformity of
>> style is desirable in the RFC series.  And the title appears in the
>> index and a dumb-looking title stands out as a wierdness.
>> 
>> Bob Braden
>>
>>   *> At 05:27 PM 4/3/2008, Bob Braden wrote:
>>   *>
>>   *>
>>   *> >   *> The IESG has approved the following document:
>>   *> >   *>
>>   *> >   *> - 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD 
>> EXTENSIONS '
>>   *> >   *>    <draft-ietf-imapext-sort-20.txt> as a Proposed Standard
>>   *> >   *>
>>   *> >
>>   *> >Why is this document shouting at us?  Title case is the norm for
>>   *> >RFCs.
>>   *> >
>>   *> >RFC Editor/bb
>>   *> >
>>   *> >  *> Two simple/optional improvements:
>>   *> >   *> Add a normative reference to STD 63 (RFC3629) for UTF-8.
>>   *> >   *> Instead of allowing any 8-bit in BLOBCHAR and NONWSP,
>>   *> > reference the rules
>>   *> >   *> in RFC 3629 for well-formed UTF-8 (UTF8-2, UTF8-3, UTF8-4).
>>   *> >   *>
>>   *>
>
>

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 08 Apr 2008 10:39:06 -0400
To: Bob Braden <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Protocol Action: 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS' to Proposed Standard
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Bob:

I am not pushing for one or the other for this document.  I'm simply 
pointing out that the authors used the same title case as the 
document that is being updated.

Russ

At 01:39 PM 4/7/2008, Bob Braden wrote:

>   *>
>   *> See RFC 3501
>   *>
>
>Russ,
>
>I am trying to figure out whether you are serious.  Of course, there
>have been individual failures in the past.  In fact, 821 or 822 (I foreget
>which) was a title-case failure.  But the existence of an occasional
>error does not seem to justify deliberately doing it wrong in the
>future.  (I will have to admit to a certain bias... upper-cased
>titles remind me of the days when network-illiterate Big Iron
>users would sometimes send all-caps messages to the Internet.)  It
>is generally agreed, I believe, that some reasonable uniformity of
>style is desirable in the RFC series.  And the title appears in the
>index and a dumb-looking title stands out as a wierdness.
>
>Bob Braden
>
>   *> At 05:27 PM 4/3/2008, Bob Braden wrote:
>   *>
>   *>
>   *> >   *> The IESG has approved the following document:
>   *> >   *>
>   *> >   *> - 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD 
> EXTENSIONS '
>   *> >   *>    <draft-ietf-imapext-sort-20.txt> as a Proposed Standard
>   *> >   *>
>   *> >
>   *> >Why is this document shouting at us?  Title case is the norm for
>   *> >RFCs.
>   *> >
>   *> >RFC Editor/bb
>   *> >
>   *> >  *> Two simple/optional improvements:
>   *> >   *> Add a normative reference to STD 63 (RFC3629) for UTF-8.
>   *> >   *> Instead of allowing any 8-bit in BLOBCHAR and NONWSP,
>   *> > reference the rules
>   *> >   *> in RFC 3629 for well-formed UTF-8 (UTF8-2, UTF8-3, UTF8-4).
>   *> >   *>
>   *>

Date: Fri, 04 Apr 2008 12:12:06 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Russ Housley <[email-masked]>, Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Protocol Action: 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS' to Proposed Standard
Sender: [email-masked]

Mark Crispin wrote:

>
> The author of the document(s) in question hereby states his complete
> lack of concern as to whether the title of the published RFC is
> uppercase or titlecase. He was doing nothing other than following past
> precedents; and those precedents that he used were all uppercase.
>
> Of greater concern to the author is the BLOBCHAR/NONWSP issue. I have
> already contacted Chris Newman on this matter. This change can be
> interpreted as imposing a mandate on IMAP server implementations that
> does not currently exist; arguably conflicts with RFC 5051; and in
> real life is moot due to external specifications (RFC 2822 among
> others). Due to the last point, a string that triggers this rule is an
> invalid string.
>
> With Chris' permission, I request that this particular RFC Editor note
> either be waived or be made as a documentation suggestion only.

Speaking as an individual: +1.

According to <https://datatracker.ietf.org/idtracker/ballot/1157/> Chris
agreed with this and he updated his comment to only mention adding the
reference to RFC 3629.

> On Thu, 3 Apr 2008, Russ Housley wrote:
>
>>
>> See RFC 3501
>>
>> At 05:27 PM 4/3/2008, Bob Braden wrote:
>>
>>> *> The IESG has approved the following document:
>>> *>
>>> *> - 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS '
>>> *> <draft-ietf-imapext-sort-20.txt> as a Proposed Standard
>>> *>
>>>
>>> Why is this document shouting at us? Title case is the norm for
>>> RFCs.
>>>
>>> RFC Editor/bb
>>>
>>> *> Two simple/optional improvements:
>>> *> Add a normative reference to STD 63 (RFC3629) for UTF-8.
>>> *> Instead of allowing any 8-bit in BLOBCHAR and NONWSP, reference
>>> the rules
>>> *> in RFC 3629 for well-formed UTF-8 (UTF8-2, UTF8-3, UTF8-4).
>>> *>
>>

Date: Thu, 3 Apr 2008 15:06:45 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Russ Housley <[email-masked]>
cc: Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Protocol Action: 'INTERNET MESSAGE ACCESS PROTOCOL - SORT  AND THREAD EXTENSIONS' to Proposed Standard
Sender: [email-masked]

The author of the document(s) in question hereby states his complete lack 
of concern as to whether the title of the published RFC is uppercase or 
titlecase.  He was doing nothing other than following past precedents; and 
those precedents that he used were all uppercase.

Of greater concern to the author is the BLOBCHAR/NONWSP issue.  I have 
already contacted Chris Newman on this matter.  This change can be 
interpreted as imposing a mandate on IMAP server implementations that does 
not currently exist; arguably conflicts with RFC 5051; and in real life is 
moot due to external specifications (RFC 2822 among others).  Due to the 
last point, a string that triggers this rule is an invalid string.

With Chris' permission, I request that this particular RFC Editor note 
either be waived or be made as a documentation suggestion only.

On Thu, 3 Apr 2008, Russ Housley wrote:
>
> See RFC 3501
>
> At 05:27 PM 4/3/2008, Bob Braden wrote:
>
>
>>   *> The IESG has approved the following document:
>>   *>
>>   *> - 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS '
>>   *>    <draft-ietf-imapext-sort-20.txt> as a Proposed Standard
>>   *>
>> 
>> Why is this document shouting at us?  Title case is the norm for
>> RFCs.
>> 
>> RFC Editor/bb
>>
>>  *> Two simple/optional improvements:
>>   *> Add a normative reference to STD 63 (RFC3629) for UTF-8.
>>   *> Instead of allowing any 8-bit in BLOBCHAR and NONWSP, reference the 
>> rules
>>   *> in RFC 3629 for well-formed UTF-8 (UTF8-2, UTF8-3, UTF8-4).
>>   *>
>
>

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Thu, 03 Apr 2008 17:44:09 -0400
To: Bob Braden <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Protocol Action: 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS' to Proposed Standard
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

See RFC 3501

At 05:27 PM 4/3/2008, Bob Braden wrote:

>   *> The IESG has approved the following document:
>   *>
>   *> - 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS '
>   *>    <draft-ietf-imapext-sort-20.txt> as a Proposed Standard
>   *>
>
>Why is this document shouting at us?  Title case is the norm for
>RFCs.
>
>RFC Editor/bb
>
>  *> Two simple/optional improvements:
>   *> Add a normative reference to STD 63 (RFC3629) for UTF-8.
>   *> Instead of allowing any 8-bit in BLOBCHAR and NONWSP, 
> reference the rules
>   *> in RFC 3629 for well-formed UTF-8 (UTF8-2, UTF8-3, UTF8-4).
>   *>

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, imapext mailing list <[email-masked]>, imapext chair <[email-masked]>
Subject: Protocol Action: 'INTERNET MESSAGE ACCESS PROTOCOL -  SORT AND THREAD EXTENSIONS' to Proposed Standard 
Date: Thu,  3 Apr 2008 12:03:23 -0700 (PDT)
Sender: [email-masked]

The IESG has approved the following document:

- 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS '
   <draft-ietf-imapext-sort-20.txt> as a Proposed Standard

This document is the product of the Internet Message Access Protocol 
Extension Working Group. 

The IESG contact persons are Lisa Dusseault and Chris Newman.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-20.txt

Technical Summary
 
   This document describes the base-level server-based sorting and
   threading extensions to the IMAP protocol.  These extensions
   provide substantial performance improvements for IMAP clients which
   offer sorted and threaded views.
 
Working Group Summary
 
   This document is a product of the IMAPEXT working group.
 
Protocol Quality
 
   This has gone completely back through the system due to the long time
delay while the standards around a comparator registry and IMAP i18n 
were written.  The proposal has not changed much in approach, but the 
context has changed. 

   Ned Freed (first pass) and Lisa Dusseault (second pass) reviewed the
specification for the IESG.

Note to RFC Editor

Two simple/optional improvements:
Add a normative reference to STD 63 (RFC3629) for UTF-8.
Instead of allowing any 8-bit in BLOBCHAR and NONWSP, reference the rules
in RFC 3629 for well-formed UTF-8 (UTF8-2, UTF8-3, UTF8-4).

Date: Wed, 02 Apr 2008 09:39:06 -0400
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: OT: Conference on Email and Anti-Spam final call for papers
Sender: [email-masked]

This seems sufficiently on-topic for this list:
The 2008 Conference on Email and Anti-Spam submission deadline is approaching,=20
and has been extended by a week, to 10 April.  If you have any work to report on=20
in the area of Internet messaging abuse and its prevention =E2=80=94 not limited =
to=20
email spam; see the topic list in the CfP, below =E2=80=94 please form it into a =
paper=20
by next week, and submit it.

Barry

----------------------------------------------------------------------
      THE FIFTH CONFERENCE ON EMAIL AND ANTI-SPAM (CEAS 2008)

            Thursday August 21 and Friday August 22, 2008
                   Microsoft Research Silicon Valley
                      Mountain View, California
                        <http://www.ceas.cc>

                       FINAL CALL FOR PAPERS

The Conference on Email and Anti-Spam (CEAS) invites the submission
of papers for its fifth meeting. Papers are invited on all aspects of
electronic communication including email, instant messaging, text
messaging, and voice over internet protocol (VoIP). Topics of interest
include novel applications of electronic messaging, abatement of abuses
of electronic messaging, spam, spit (spam over internet telephony), spim
(spam over instant messenger), phishing, identity theft via messaging,
viruses, and spyware.

Paper submissions can be either research papers, extended abstracts,
industry reports, or law and policy papers. Submissions from
practitioners and vendors are encouraged. Papers will be selected by
peer review for presentation at CEAS 2008. Papers will be reviewed based
on their contribution to the literature.

SUGGESTED TOPICS:

*  Message filtering, blocking, authentication
   -  Machine learning
   -  Natural language processing
   -  Adversarial learning
   -  Challenge-response
   -  Payment schemes
   -  Disposable addresses
   -  Messaging protocols
   -  Digital signatures
*  Evaluation
   - Corpus and benchmark creation
   - Measures and methodologies
   - Comparative tests of methods or products
*  Analysis
   - Economics of spam, spit, spim, phishing, etc.
   - Abuse tactics and patterns
   - Legitimate use patterns
   - Historical data
*  Message organization and search
   - Advanced calendaring and scheduling
   - Automatic foldering
   - Automatic routing
   - Summarization
   - Search
*  Systems and network issues
   - Performance & scalability
   - Reliability & security
   - Archival & retrieval
*  User issues
   - User interfaces
   - Usability studies
   - Messaging in support of user activities
*  Social issues
   - Deducing social networks
   - Costs and benefits of messaging use and abuse
   - Other social impacts
*  Industry
   - Cooperation for stopping abuse
   - Messaging and abuse reporting standards
   - Interoperability
*  Legal issues
   - Spam, spit, spim and phishing, etc.
   - Identity theft
   - Privacy
   - Freedom of speech
   - Digital rights management

KEY DATES:

*  Submission deadline: April 10, 2008 (10:59pm UTC) -- EXTENDED DATE
*  Notification of acceptance: June 6, 2008.
*  Final camera-ready version of papers: June 21, 2008
*  Conference: August 21 and 22, 2008

REQUIREMENTS:

Papers may be of one of two types:
*  Extended abstracts (up to 2 pages) may outline work in progress,
   exceptional papers published for different scientific communities,
   original research, or industry reports.
*  Full papers (up to 10 pages). Work may not have been previously
   published in, or under consideration for publication in any other
   conference or journal.

Submissions must use the CEAS electronic system at:
https://cmt.research.microsoft.com/CEAS2008/. The style for
submissions and final papers is a two-column, 8.5 by 11 inch format. See
http://www.ceas.cc/2008/format.htm for details.

Papers will be reviewed by a committee of experts from academic and
industrial research centers. Accepted papers will be made freely
available on the web, and will be published on CD-ROM. Authors will
retain copyright of their work.

CONTACT:

*  The conference chair and co-chairs can be reached at
   [email-masked]

CEAS PRESIDENT

*  Gordon Cormack
   University of Waterloo
   http://plg.uwaterloo.ca/~gvcormac/

GENERAL CONFERENCE CHAIR:

*  Aleksander Kolcz
   Microsoft Live Labs
   http://ir.iit.edu/~alek/

PROGRAM CO-CHAIRS:

*  Andrej Bratko
   Jozef Stefan Institute
   http://ai.ijs.si/andrej/

*  Barry Leiba
   IBM Research
   http://www.research.ibm.com/people/l/leiba/

*  Tobias Scheffer
   Max Planck Institute for Computer Science
   http://www.mpi-inf.mpg.de/~scheffer/
----------------------------------------------------------------------