headers
Internet-Drafts | 1 Feb 2008 22:30
Picon
Favicon

I-D Action:draft-ietf-imapext-i18n-15.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title           : Internet Message Access Protocol Internationalization
	Author(s)       : C. Newman, et al.
	Filename        : draft-ietf-imapext-i18n-15.txt
	Pages           : 19
	Date            : 2008-02-01

Internet Message Access Protocol (IMAP) version 4rev1 has basic
 support for non-ASCII characters in mailbox names and search
 substrings.  It also supports non-ASCII message headers and content
 encoded as specified by Multipurpose Internet Mail Extensions
 (MIME).  This specification defines a collection of IMAP extensions
 which improve international support including comparator negotiation
 for search, sort and thread, language negotiation for international
 error text, and translations for namespace prefixes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-15.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Crispin | 7 Feb 2008 02:18
Favicon

[Imap-protocol] IETF no longer accepts free-format Internet-drafts

It seems that a consequence of the IETF's new service provider, it is no 
longer possible to upload a free-format Internet-draft.  Instead of just 
emailing to internet-drafts <at> ietf.org, we're now supposed to use a web page
 	https://datatracker.ietf.org/idst/upload.cgi
which enforces the idnits requirements and spews forth:
 	Pages [sic] is not in numeric format.

Bah, humbug.  Pretty formatting is the RFC Editor's job.  Requiring such 
for drafts is a waste of time.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-protocol mailing list
Imap-protocol <at> u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-protocol
Permalink | Reply | 0 comments |
headers
The IESG | 20 Feb 2008 00:29
Picon
Favicon

Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard

The IESG is considering the following document again now that 
important dependencies are ready:

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

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2008-03-04. Exceptionally, 
comments may be sent to iesg <at> ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-19.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=4540&rfc_flag=0

_______________________________________________
IETF-Announce mailing list
IETF-Announce <at> ietf.org
http://www.ietf.org/mailman/listinfo/ietf-announce
Permalink | Reply | 0 comments |
headers
Timo Sirainen | 23 Feb 2008 20:09
Picon
Picon
Favicon

Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard

REFERENCES -> (1) -> (A) has:

                If a message does not contain a Message-ID header line,
                or the Message-ID header line does not contain a valid
                Message ID, then assign a unique Message ID to this
                message.

                If two or more messages have the same Message ID, then
                only use that Message ID in the first (lowest sequence
                number) message, and assign a unique Message ID to each
                of the subsequent messages with a duplicate of that
                Message ID.

But these apply to (B) part as well. Some kind of text restructuring to
move them to (1) level would make it more logical. But I guess this
doesn't matter all that much.

REFERENCES -> (1) -> (B):

             If the current message already has a parent, [..], so break
             the current parent/child link before creating the new
             correct one.  As in step 1.A, do not create the parent/child
             link if creating that link would introduce a loop.

Should the original parent/child link be broken if adding the new one
would introduce a loop? I think this should be clarified in the text.
Permalink | Reply | 8 comments |
headers
Timo Sirainen | 23 Feb 2008 20:32
Picon
Picon
Favicon

Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard

On Sat, 2008-02-23 at 21:09 +0200, Timo Sirainen wrote:
> REFERENCES -> (1) -> (B):
> 
>              If the current message already has a parent, [..], so break
>              the current parent/child link before creating the new
>              correct one.  As in step 1.A, do not create the parent/child
>              link if creating that link would introduce a loop.
> 
> Should the original parent/child link be broken if adding the new one
> would introduce a loop? I think this should be clarified in the text.

I was pretty sure that it shouldn't have been broken, but looks like
UW-IMAP does break it. Also strictly reading the text I suppose that's
the correct interpretation. So Dovecot has been doing this wrong for
years.
Permalink | Reply | 0 comments |
headers
Timo Sirainen | 23 Feb 2008 20:34
Picon
Picon
Favicon

Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard

On Sat, 2008-02-23 at 11:29 -0800, Mark Crispin wrote:

> > Should the original parent/child link be broken if adding the new one
> > would introduce a loop? I think this should be clarified in the text.
> 
> It doesn't say that that should be done; therefore it is not done.

I think it's ambiguous. And now it's even more ambiguous because you say
it shouldn't be broken, but your implementation breaks it.
Permalink | Reply | 5 comments |
headers
Mark Crispin | 23 Feb 2008 20:29
Favicon

Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard


On Sat, 23 Feb 2008, Timo Sirainen wrote:
> But these apply to (B) part as well. Some kind of text restructuring to
> move them to (1) level would make it more logical. But I guess this
> doesn't matter all that much.

It doesn't matter, since (1)(B) results directly from (1)(A) and thus that 
decision has already been made.

> Should the original parent/child link be broken if adding the new one
> would introduce a loop? I think this should be clarified in the text.

It doesn't say that that should be done; therefore it is not done.

It's possible to add an infinite number of "should I do this" that isn't 
stated in the document.  I don't think that we should attempt to 
exhaustively list all the things that should not be done; rather specify 
precisely what should be done.

-- 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.
Permalink | Reply | 6 comments |
headers
Mark Crispin | 23 Feb 2008 20:43
Favicon

Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard


On Sat, 23 Feb 2008, Timo Sirainen wrote:
> On Sat, 2008-02-23 at 11:29 -0800, Mark Crispin wrote:
>>> Should the original parent/child link be broken if adding the new one
>>> would introduce a loop? I think this should be clarified in the text.
>> It doesn't say that that should be done; therefore it is not done.
> I think it's ambiguous. And now it's even more ambiguous because you say
> it shouldn't be broken, but your implementation breaks it.

Sorry; I meant to type "IF it doesn't say that should be done; therefore 
it is not done."

I wasn't judging whether or not it said it should be done.  In re-reading 
the description, I don't see how it can be any other way though.

-- 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.
Permalink | Reply | 4 comments |
headers
Mark Crispin | 23 Feb 2008 20:47
Favicon

Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard


On Sat, 23 Feb 2008, Mark Crispin wrote:
> I wasn't judging whether or not it said it should be done.  In re-reading 
> the description, I don't see how it can be any other way though.

In particular, UW imapd does NOT explicitly break the parent->child link 
if there is a loop; it just disregards it in that case.  However, implicit 
behavior from first executing the previous part of that rule is a 
different matter.

-- 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.
Permalink | Reply | 3 comments |
headers
Timo Sirainen | 23 Feb 2008 21:41
Picon
Picon
Favicon

Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard

On Sat, 2008-02-23 at 11:47 -0800, Mark Crispin wrote:
> On Sat, 23 Feb 2008, Mark Crispin wrote:
> > I wasn't judging whether or not it said it should be done.  In re-reading 
> > the description, I don't see how it can be any other way though.
> 
> In particular, UW imapd does NOT explicitly break the parent->child link 
> if there is a loop; it just disregards it in that case.  However, implicit 
> behavior from first executing the previous part of that rule is a 
> different matter.

I suppose we're talking about the same thing. To translate the text to
pseudocode:

if msg->parent != NULL
  unlink(msg)
if not is_a_loop(msg, new_parent)
  link(msg, new_parent)

This is how all servers seem to implement it, except Dovecot. I
originally understood the text to mean:

if not is_a_loop(msg, new_parent)
  if msg->parent != NULL
    unlink(msg)
  link(msg, new_parent)
Permalink | Reply | 2 comments |

Gmane