Subject: Re: Jabbering - [email-masked]
From: [email-masked]
To: Lyndon Nerenberg <[email-masked]>
Cc: Pete Resnick <[email-masked]>, [email-masked]
Date: Fri, 31 Oct 2003 13:13:41 -0800 (PST)
List-Id: <ietf-imapext.imc.org>

> > Did you have tool
> > problems, or was the jabber scribe simply not saying anything
> > comprehensible enough for you?

> The problem with Jabber is that the scribe cannot keep up with the
> discussion in real time.

Well, it pretty much depends on how fast a typist you are. I've done this a
couple of times, including one very busy ASRG meeting, and I think I've managed
to keep up and cover the relevant points, but then again I'm a very fast
typist. And if you do this you most certainly aren't going to be able to do
much in the way of contributing to the discussion. It is also hard work by any
measure, and not something I'd be willing to do for more than a couple of
sessions at any given IETF.

> And neither can the remote correspondents.

Speaking as someone who has tried to participate remotely on a couple of
occasions, the problem is usually not having enough information to keep up with
rather than having too much.

> And it
> is impossible to transcribe the nuances of the conversation on the fly, and
> without that context it's very easy to misinterpret what's really being
> said. (I used to work for a court reporting company. There is a reason
> those people get paid as much as they do.)

Indeed. Transcription is in all its various forms is clearly an art, and it is
silly to believe that any random person will be able to do it well. (Not even
when we're talking about random IETF attendees.) Clearly this is no real
substitute for actually being there.

> > > The mailing lists are not broken -- let's not try to fix them.

> > And this has what to do with the existence of the jabber room?

> Everything. We're talking about communication within the WG. I am making
> the claim that the mailing list is a useful and appropriate tool for the WG
> members to communicate -- accurately -- their thoughts. I am also making
> the claim that Jabber does not allow for accurate communication, and is the
> wrong tool to solve this problem (if indeed there really is a problem here
> that needs solving).

Hmm. Well, I think I see your point, but on the other hand, the ability to talk
to the chair right away when issues come up is an intriguing one that may have
some real advantages. I think it is worth trying at least. If it helps,
great, and if it sucks we'll at least have learned something.

				Ned

Date: Fri, 31 Oct 2003 13:47:06 -0700
From: Lyndon Nerenberg <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: [email-masked]
Subject: Re: Jabbering - [email-masked]
Sender: [email-masked]

> Did you have tool
> problems, or was the jabber scribe simply not saying anything
> comprehensible enough for you?

The problem with Jabber is that the scribe cannot keep up with the 
discussion in real time. And neither can the remote correspondents. And it 
is impossible to transcribe the nuances of the conversation on the fly, and 
without that context it's very easy to misinterpret what's really being 
said. (I used to work for a court reporting company. There is a reason 
those people get paid as much as they do.)

>> The mailing lists are not broken -- let's not try to fix them.
>
> And this has what to do with the existence of the jabber room?

Everything. We're talking about communication within the WG. I am making 
the claim that the mailing list is a useful and appropriate tool for the WG 
members to communicate -- accurately -- their thoughts. I am also making 
the claim that Jabber does not allow for accurate communication, and is the 
wrong tool to solve this problem (if indeed there really is a problem here 
that needs solving).

--lyndon

Date: Fri, 31 Oct 2003 11:33:42 -0600
To: Lyndon Nerenberg <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Jabbering - [email-masked]
Cc: [email-masked]
Sender: [email-masked]

On 10/31/03 at 9:53 AM -0700, Lyndon Nerenberg wrote:

>My experience with jabber over the last few IETFs is that it's 
>nothing more than a pain in the a**.

I've successfully used jabber during the face-to-face, both for 
watching side commentary while in a large session (to ask questions 
for simple things while the session is going on) as well as watching 
what was going on in a session I couldn't be at while in another 
room. Did you have tool problems, or was the jabber scribe simply not 
saying anything comprehensible enough for you?

>The mailing lists are not broken -- let's not try to fix them.

And this has what to do with the existence of the jabber room?

Again, the jabber room is NOT trying to fix anything about the 
mailing list, and it's CERTAINLY NOT trying to replace it for 
official business. It's another channel of communication (just like 
private e-mail between members of a working group) where people can 
work minor things out without wasting the time of the entire working 
group. Is there some problem with that?

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

Date: Fri, 31 Oct 2003 09:53:48 -0700
From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
Subject: Re: Jabbering - [email-masked]
Sender: [email-masked]

> Absolutely, though my feeling is that serious discussions should *not*
> take place in jabber at this point.

My experience with jabber over the last few IETFs is that it's nothing more 
than a pain in the a**. The mailing lists are not broken -- let's not try 
to fix them.

--lyndon

Date: Fri, 31 Oct 2003 09:50:15 -0600
To: Cyrus Daboo <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Jabbering - [email-masked]
Cc: [email-masked]
Sender: [email-masked]

On 10/31/03 at 10:45 AM -0500, Cyrus Daboo wrote:

>If serious discussions are going to take place on the jabber list, 
>is it possible to have some summary of those posted to the email list

Absolutely, though my feeling is that serious discussions should 
*not* take place in jabber at this point. Jabber might be a nice way, 
if someone happens to be around, to ask a quick "Hey, what's the 
status of my draft?" or "I don't understand a piece of this draft. 
Can someone explain what I'm missing, or should I bring this to the 
author as a problem?" kind of question. I expect serious issue 
discussions to always be on the list.

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

Date: Fri, 31 Oct 2003 10:45:24 -0500
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Jabbering - [email-masked]
Sender: [email-masked]

Hi Pete,

- --On Thursday, October 30, 2003 23:21 -0600 Pete Resnick 
<[email-masked]> wrote:

| Just to let folks know: I plan to "hang out" in the IMAPEXT room on the
| new jabber server that Marshall recently announced. Everyone should feel
| free to "hang out" or drop in for group related questions.

Frankly, right now I have enough trouble keeping up with email, let alone 
anything that's more 'real-time' than that. If serious discussions are 
going to take place on the jabber list, is it possible to have some summary 
of those posted to the email list (I'm not talking about a URL to jabber 
archive but a real email message with any jabber discussions from the last 
week, say).

- -- 
Cyrus Daboo

Date: Thu, 30 Oct 2003 23:21:14 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Jabbering - [email-masked]
Sender: [email-masked]

Just to let folks know: I plan to "hang out" in the IMAPEXT room on 
the new jabber server that Marshall recently announced. Everyone 
should feel free to "hang out" or drop in for group related questions.
-- 
Pete Resnick <http://wwww.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Thu, 30 Oct 2003 09:28:58 -0800 (PST)
From: [email-masked]
Subject: IESG review of draft-ietf-imapext-condstore-04.txt
To: IMAP extensions Mailing List <[email-masked]>
Sender: [email-masked]

The IESG reviewed this document today, and Ted Hardie has recorded the
following discuss comments:

----

Section 3.2 says:

Note: A client trying to make an atomic change to the state of a particular
      metadata item (or a set of metadata items) should be prepared
      to deal with the case when the server returns MODIFIED response code
      if the state of the metadata item being watched hasn't changed (but
      the state of some other metadata item has). This is necessary, because
      some servers don't store separate mod-sequences for different metadata
      items. However, a server implementation SHOULD avoid generating
      spurious MODIFIED responses for +FLAGS/-FLAGS STORE operations,
      even when the server stores a single mod-sequence per message.

      Upon the receipt of MODIFIED response code the client SHOULD try to
      figure out if the required metadata items have indeed changed. If they
      haven't the client SHOULD retry the command.

First, this is a classic case of IMAP being so server focused as to make a
client's life hell.  In order to avoid keeping per-metadatum state, the
protocol now forces client round trips to check that what it wants to change
isn't the bit that has already been changed.  While I won't challenge that
design choice based on my own preference, I'm not sure that I believe "SHOULD
try to figure out" is a realistic piece of protocol specification, and seeing
it in a document about conditional storage makes my head hurt.  Cleaning up the
language so it is clear exactly what the client has to do would be useful.

I also think the sentence "a server implementation SHOULD avoid generating
spurious MODIFIED responses for +FLAGS/-FLAGS STORE operations, even when the
server stores a single mod-sequence per message" doesn't make any sense.  What
is the server supposed to do here?  Not send a modified response even though it
knows something changed and doesn't know what, based on some extra-protocol
knowledge?  This doesn't seem like a win for interoperability.  If it doesn't
know what changed (because it is using a single mod-sequence) it's not
spurious, just lame.

I believe we normally have documents that update other RFCs mention that in
the abstract, and since this does, it probably ought to.

----

					Ned

Date: Thu, 30 Oct 2003 07:32:46 +0800
From: James Seng <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Abhijit Menon-Sen <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

> I do not believe that this is true for Chinese.  AFAIK, Chinese primary
> school kids use Latin script with hanyu-pinyin as a stopgap prior to their
> mastery of Han script (which takes many years).

Nope. Hanyu Pinyin was designed to replace the Han ideograph but it 
never did.

> Note that when I say "recognize Latin script", I mean the ability to
> determine that "dog" is a three-letter word that has the letters "d", "o",
> and "g", each of which the individual recognizes and can name.  This does
> not include the ability to recognize that this refers to a domesticated
> canine.

Based on your reasonings, I think we should all reverted back to 
numbers, because that is the only universal recongizable set of symbols 
we have.

We have this argument in IDN before and we certainly dont need this 
again. If you feel we should all stick to Latin, yes, you are entitled 
to your opinion but please do so in other place, and not here. The group 
is suppose to work on Internationalization of Email address 
(identifiers), not debate whether we need it or not.

-James Seng

Date: Thu, 30 Oct 2003 07:26:28 +0800
From: James Seng <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Mark Davis <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Crispin,

You need to get out of US (or Wsshington) more often.

-James Seng

> I am not convinced that it is possible to use a computer on the Internet
> anywhere in the world without at least a basic acquaintance with Latin
> script.
> 
> I do not believe many individuals (other than primary school children) are
> literate in their native language but are completely illiterate in Latin
> script.  This does not mean "being able to read or write the English
> language"; rather, this simply means knowing the Latin script alphabet.
> 
> Put another way, individuals who are completely illiterate in Latin script
> are also likely to be illiterate in their native language script as well.
> 
> No other script on the planet has such international recognition.
> 
> There is undoubtably a *preference* for one's native script; and that
> preference should be respected as much as possible.
> 
> -- Mark --
> 
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
> Si vis pacem, para bellum.
> 
> 
> 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: [idn] FYI: BOF on Internationalized Email Addresses (IEA)
Date: Wed, 29 Oct 2003 15:18:45 -0800
From: "Michel Suignard" <[email-masked]>
To: "James Seng" <[email-masked]>, =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Pete Resnick" <[email-masked]>, "Ted Hardie" <[email-masked]>, "Ned Freed" <[email-masked]>
Sender: [email-masked]

JS>I seen John and Paul proposal but I have not seen Michel. Is there a draft that I can read
JS>up? 

I don't have a proposal. I am listed there as a co-editor of the IRI spec which has a peripheral impact on the IEA (such as extending the URI mailto scheme). Like many I am listening with interest to the points made for or against the two proposals.

Michel Suignard

Date: Wed, 29 Oct 2003 16:18:35 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

On Wed, 29 Oct 2003, Cyrus Daboo wrote:

> | This version includes the change in the capability name as well as the
> | revised base64 text.
>
> Minor point from the protocol police: the examples are all missing the
> tagged OK for the CAPABILITY command.

Oh! How embarrassing.

Thanks, this will be fixed.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----

Date: Wed, 29 Oct 2003 16:17:01 -0500
From: Cyrus Daboo <[email-masked]>
To: Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

Hi Rob,

--On Wednesday, October 29, 2003 16:02 -0500 Rob Siemborski 
<[email-masked]> wrote:

| Since the ID editor apparently ate the update I tried to post to this
| document, I have posted an updated version of it here:
|
| http://www.contrib.andrew.cmu.edu/~rjs3/ietf/draft-siemborski-imap-sasl-i
| nitial-response-01b.txt
|
| This version includes the change in the capability name as well as the
| revised base64 text.

Minor point from the protocol police: the examples are all missing the 
tagged OK for the CAPABILITY command.

-- 
Cyrus Daboo

Date: Wed, 29 Oct 2003 16:02:30 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

On Mon, 13 Oct 2003 [email-masked] wrote:

> 	Title		: IMAP Extension for SASL Initial Client Response
> 	Author(s)	: R. Siemborski
> 	Filename	: draft-siemborski-imap-sasl-initial-response-00.txt
> 	Pages		: 7
> 	Date		: 2003-10-10

Since the ID editor apparently ate the update I tried to post to this
document, I have posted an updated version of it here:

http://www.contrib.andrew.cmu.edu/~rjs3/ietf/draft-siemborski-imap-sasl-initial-response-01b.txt

This version includes the change in the capability name as well as the
revised base64 text.

So, who's coming to IETF-58?

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----

Date: Wed, 29 Oct 2003 16:50:39 +0100
To: Zefram <[email-masked]>
From: "J-F C. (Jefsey)  Morfin" <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Cc: Dave Crocker <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On 10:31 28/10/03, Zefram said:
>I think the first task in this area should be to investigate the nature 
>and degree of desire for non-ASCII local parts.  This desire needs to be 
>weighed against the benefits we derive from writing all local parts in a 
>small, fixed alphabet (ASCII printables).

May I ask which part of the world you come from?

This being said only Americans want/are satisfied with "internationalized" 
(sic) names (the artificial extension of the American character set with 
most of the American foreign scripting, within an ascii frame). No one 
really wants multilingual names (a totally internationalized (sic) frame 
supporting languages and therefore some language oriented rules - at least 
ni management and user support). The users need vernacular support, that is 
to be able to freely do in the mail what they use to do elsewhere.

I note that for non-American writers "international names" means names that 
everyone from every nation will understand. It happens to be the ascii 
character set limited to the DNS used names (they were selected for that 
reason).
jfc

Date: Tue, 28 Oct 2003 17:41:55 -0800
To: [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Location of the IMAA list (was: RE: FYI: BOF on Internationalized Email Addresses (IEA))
Sender: [email-masked]

At 11:54 AM -0500 10/28/03, [email-masked] wrote:
>The BOF description lists [email-masked] as the
>discussion list, but this discussion is being
>cc:ed to [email-masked].  I'd suggest that you
>move this discussion to whichever of those lists
>is actually correct.

It is [email-masked], although because Patrik sent out the wrong 
address, I have made sure that both addresses work. An archive of the 
list, and links to the current versions of the drafts, can be found 
at <http://www.imc.org/ietf-imaa/>.

No more messages to all lists: that's what the IMAA list is for.

--Paul Hoffman, Director
--Internet Mail Consortium

From: [email-masked]
To: Mark Davis <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) 
Date: Tue, 28 Oct 2003 15:07:19 -0500
Sender: [email-masked]

--==_Exmh_-1503687178P
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, 27 Oct 2003 17:39:32 PST, Mark Davis said:

> email addresses. Mr. Tanaka can have one with Latin letters and one wit=
h
> Japanese (e.g. =E3=83=A0=E3=83=AB=E3=82=AF@=E3=82=AB=E3=82=AF.=E3=83=AF=
=E3=82=B7=E3=83=B3=E3=82=B0=E3=83=88=E3=83=B3.=E3=82=A8=E3=83=87=E3=82=A5=
).

This gets interesting in the context of a "reply all".

Apologies for breaking the UTF-8 in the quote, but it's illustrative - if=
 the
breakage had been in the To/Cc lines, things would have broken even worse=

unless whatever scheme we end up using is ASCII-transparent.

--==_Exmh_-1503687178P
Content-Type: application/pgp-signature

--==_Exmh_-1503687178P--

Date: Tue, 28 Oct 2003 12:36:07 -0500
From: John C Klensin <[email-masked]>
To: Marc Blanchet <[email-masked]>, Mark Davis <[email-masked]>, Mark Crispin <[email-masked]>, Abhijit Menon-Sen <[email-masked]>
cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

--On Tuesday, October 28, 2003 11:12 -0500 Marc Blanchet
<[email-masked]> wrote:

> it appears to me that this thread is not very different from
> the idn considerations on usage of idn in the world. So what
> is really new in this discussion?

See the draft.

Quick answer: DNS interfaces really exist at the protocol level,
and a large part of the hypothesis behind IDNA was that it would
be possible, after we had enough implementations, to prevent an
end-user from ever seeing an encoded domain name.  That story
just doesn't hold for a special encoding-based (aka MUA-only)
email local part implementation, and maybe not for email
generally.  For example, under current rules, an MTA is required
to stuff the name it actually sees in HELO/EHLO and the MAIL
command into various headers.  If it is expected to notice that
they have special encodings and decodes them, we've gone rather
far into "the infrastructure is involved", even if the actual
on-the-wire transport is not impacted.  If it doesn't do that,
the encodings --both the IDNA domain parts and the special mail
encoding-- are going to be in the user's face, in the most
literal sense of that term.  

The similarity of that situation to the early IDN discussions is
the importance of the "what problem are you solving" question.
And it is very clear to me that, for email addresses, the answer
has got to "user sees their own characters in their email
addresses and the email addresses of those whose languages they
speak/ recognize.  Users typically don't actually see envelopes.
But seeing, e.g., different forms/codings of an address in the
header "From:" field than appears in "Return-path:" or than
appears in a signature line in the message body, is going to
create real unhappiness.  Similarly as has been pointed out in
another context, seeing an address in different from when it
appears in a header than when it (and that header) are
encapsulated in a message/?? body part is just not going to
amuse any user to whom we've said "ok, now you have i18n
strings, enjoy your new found local language capabilities".  And
I guess that tells you what I think the problem is that we need
to solve.  YMMD.

     john

To: Mark Davis <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) 
From: [email-masked]
Date: Tue, 28 Oct 2003 15:07:19 -0500
Sender: [email-masked]

--==_Exmh_-1503687178P
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, 27 Oct 2003 17:39:32 PST, Mark Davis said:

> email addresses. Mr. Tanaka can have one with Latin letters and one wit=
h
> Japanese (e.g. =E3=83=A0=E3=83=AB=E3=82=AF@=E3=82=AB=E3=82=AF.=E3=83=AF=
=E3=82=B7=E3=83=B3=E3=82=B0=E3=83=88=E3=83=B3.=E3=82=A8=E3=83=87=E3=82=A5=
).

This gets interesting in the context of a "reply all".

Apologies for breaking the UTF-8 in the quote, but it's illustrative - if=
 the
breakage had been in the To/Cc lines, things would have broken even worse=

unless whatever scheme we end up using is ASCII-transparent.

--==_Exmh_-1503687178P
Content-Type: application/pgp-signature

--==_Exmh_-1503687178P--

Content-class: urn:content-classes:message
Subject: RE: Exchange server has a broken SASL implementation
Date: Tue, 28 Oct 2003 11:00:01 -0800
From: "Jeff Stephenson" <[email-masked]>
To: "IMAP Interest List" <[email-masked]>, "IMAP Extensions WG" <[email-masked]>
Sender: [email-masked]

Actually, Exchange didn't get around to implementing this recently -
it's been in Windows 2000 SMTP (which is what Exchange uses) since the
release of Windows 2K.  I'm dredging my memory here, but I believe that
the code for this was locked down during the ID stage of RFC 2554,
before the RFC was released.  As I recall, it was interop-tested at the
time, but there wasn't a lot to test against and I don't recall the
results.  I've passed this along to the Exchange folks, who say it's a
known issue that wasn't fixed when discovered out of fear of breaking
anything that might have relied on this behavior.  If this behavior is
breaking other apps, that would increase the impetus to fix it.

-- jeff

Jeff Stephenson
Software Developer
Microsoft Outlook

> -----Original Message-----
> From: Ken Murchison <[email-masked]>
> Subject: Re: Exchange server has a broken SASL implementation

...

> However, if there is/was any question about the specs, there 
> are mailing lists that can be contacted for clarification.  
> Interop testing could be done with non-MS products.  The CMU 
> SASL library comes with test harnesses which can be used for 
> testing.  There are at least 2 major MTAs (sendmail, postfix) 
> which use CMU SASL that could have been consulted for comparison.

Date: Tue, 28 Oct 2003 12:36:07 -0500
From: John C Klensin <[email-masked]>
To: Marc Blanchet <[email-masked]>, Mark Davis <[email-masked]>, Mark Crispin <[email-masked]>, Abhijit Menon-Sen <[email-masked]>
cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

--On Tuesday, October 28, 2003 11:12 -0500 Marc Blanchet
<[email-masked]> wrote:

> it appears to me that this thread is not very different from
> the idn considerations on usage of idn in the world. So what
> is really new in this discussion?

See the draft.

Quick answer: DNS interfaces really exist at the protocol level,
and a large part of the hypothesis behind IDNA was that it would
be possible, after we had enough implementations, to prevent an
end-user from ever seeing an encoded domain name.  That story
just doesn't hold for a special encoding-based (aka MUA-only)
email local part implementation, and maybe not for email
generally.  For example, under current rules, an MTA is required
to stuff the name it actually sees in HELO/EHLO and the MAIL
command into various headers.  If it is expected to notice that
they have special encodings and decodes them, we've gone rather
far into "the infrastructure is involved", even if the actual
on-the-wire transport is not impacted.  If it doesn't do that,
the encodings --both the IDNA domain parts and the special mail
encoding-- are going to be in the user's face, in the most
literal sense of that term.  

The similarity of that situation to the early IDN discussions is
the importance of the "what problem are you solving" question.
And it is very clear to me that, for email addresses, the answer
has got to "user sees their own characters in their email
addresses and the email addresses of those whose languages they
speak/ recognize.  Users typically don't actually see envelopes.
But seeing, e.g., different forms/codings of an address in the
header "From:" field than appears in "Return-path:" or than
appears in a signature line in the message body, is going to
create real unhappiness.  Similarly as has been pointed out in
another context, seeing an address in different from when it
appears in a header than when it (and that header) are
encapsulated in a message/?? body part is just not going to
amuse any user to whom we've said "ok, now you have i18n
strings, enjoy your new found local language capabilities".  And
I guess that tells you what I think the problem is that we need
to solve.  YMMD.

     john

From: "Mark Davis" <[email-masked]>
To: "Marc Blanchet" <[email-masked]>, "Mark Crispin" <[email-masked]>, "Abhijit Menon-Sen" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Tue, 28 Oct 2003 08:22:37 -0800
Sender: [email-masked]

I wouldn't have thought so either, but at least some people questioned the need
for non-Latin characters, and went so far as to exclude them from a proposed
problem statement:

> ... There is a growing need to use additional
> characters, specifically Latin characters with diacriticals and non-Latin
> characters, in email addresses to better serve the needs of the
> multi-national Internet community...

Mark
__________________________________
http://www.macchiato.com
► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- 
From: "Marc Blanchet" <[email-masked]>
To: "Mark Davis" <[email-masked]>; "Mark Crispin"
<[email-masked]>; "Abhijit Menon-Sen" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tue, 2003 Oct 28 08:12
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)

>
> it appears to me that this thread is not very different from the idn
> considerations on usage of idn in the world. So what is really new in this
> discussion?
>
> Marc.
>
> -- Tuesday, October 28, 2003 07:10:59 -0800 Mark Davis
> <[email-masked]> wrote/a ecrit:
>
> >> > (I agree that it's currently nearly impossible to use computers if one
> >> > isn't familiar with the Latin script, of course.)
> >>
> >> Which probably makes the rest of this discussion academic, unless we're
> >> going to undertake solving *that* problem for Microsoft and the various
> >> UNIX/Linux vendors...
> >
> > It is currently impossible to use the Internet without knowing the Latin
> > script. However, the goal of most well-designed client software and
> > operating systems is to permit the user to work entirely within their
> > native language, with a fully localized system. This is reaching to India
> > and other countries; Microsoft has introduced fully localized versions of
> > Indic Windows just recently, and Linux vendors are hard at work to
> > produce fully localized versions of their software.
> >
> > Email and Web addresses are the big remaining holdouts for most people.
> > People should not be forced to use a script that they are unfamiliar
> > with, just to use email addresses and sites in their own countries. Even
> > if they are familiar with the Latin script, it is very often a very bad
> > match for their languages, making it very difficult to figure out how
> > native words would be spelled in it.
> >
> > Mark
> >
>
>
>
> ------------------------------------------
> Marc Blanchet
> Hexago
> tel: +1-418-266-5533x225
> ------------------------------------------
> http://www.freenet6.net: IPv6 connectivity
> ------------------------------------------
>

Date: Tue, 28 Oct 2003 11:12:54 -0500
From: Marc Blanchet <[email-masked]>
To: Mark Davis <[email-masked]>, Mark Crispin <[email-masked]>, Abhijit Menon-Sen <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

it appears to me that this thread is not very different from the idn
considerations on usage of idn in the world. So what is really new in this
discussion?

Marc.

-- Tuesday, October 28, 2003 07:10:59 -0800 Mark Davis
<[email-masked]> wrote/a ecrit:

>> > (I agree that it's currently nearly impossible to use computers if one
>> > isn't familiar with the Latin script, of course.)
>> 
>> Which probably makes the rest of this discussion academic, unless we're
>> going to undertake solving *that* problem for Microsoft and the various
>> UNIX/Linux vendors...
> 
> It is currently impossible to use the Internet without knowing the Latin
> script. However, the goal of most well-designed client software and
> operating systems is to permit the user to work entirely within their
> native language, with a fully localized system. This is reaching to India
> and other countries; Microsoft has introduced fully localized versions of
> Indic Windows just recently, and Linux vendors are hard at work to
> produce fully localized versions of their software.
> 
> Email and Web addresses are the big remaining holdouts for most people.
> People should not be forced to use a script that they are unfamiliar
> with, just to use email addresses and sites in their own countries. Even
> if they are familiar with the Latin script, it is very often a very bad
> match for their languages, making it very difficult to figure out how
> native words would be spelled in it.
> 
> Mark
> 

------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------

From: "Mark Davis" <[email-masked]>
To: "Mark Crispin" <[email-masked]>, "Abhijit Menon-Sen" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Tue, 28 Oct 2003 07:10:59 -0800
Sender: [email-masked]

> > (I agree that it's currently nearly impossible to use computers if one
> > isn't familiar with the Latin script, of course.)
>
> Which probably makes the rest of this discussion academic, unless we're
> going to undertake solving *that* problem for Microsoft and the various
> UNIX/Linux vendors...

It is currently impossible to use the Internet without knowing the Latin script.
However, the goal of most well-designed client software and operating systems is
to permit the user to work entirely within their native language, with a fully
localized system. This is reaching to India and other countries; Microsoft has
introduced fully localized versions of Indic Windows just recently, and Linux
vendors are hard at work to produce fully localized versions of their software.

Email and Web addresses are the big remaining holdouts for most people. People
should not be forced to use a script that they are unfamiliar with, just to use
email addresses and sites in their own countries. Even if they are familiar with
the Latin script, it is very often a very bad match for their languages, making
it very difficult to figure out how native words would be spelled in it.

Mark

From: "Mark Davis" <[email-masked]>
To: "Stephane Bortzmeyer" <[email-masked]>
Cc: "Mark Crispin" <[email-masked]>, "Keith Moore" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "IMAP Extensions WG" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Tue, 28 Oct 2003 06:54:45 -0800
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0068_01C39D20.5EDF9090
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Sigh. I used "Greek" in an analogy because I was hoping that some of the =
Latin-only folks out there would at least recognize the name of one =
other script. But how comforable would you really be, if =
=D9=8A=D9=8F=D9=8F =D9=88=D9=90=D8=B1=D9=90 =
=D9=81=D9=8F=D8=B1=D8=B3=D9=90=D8=AF =D8=AA=D9=8F =
=D8=B1=D9=8E=D9=90=D8=AF =D9=8E=D9=86 =
=D9=90=D9=86=D8=AA=D9=90=D8=B1=D9=90=D9=84=D9=8A =
=D8=AF=D9=90=D9=81=D9=81=D9=90=D8=B1=D9=90=D9=86=D8=AA =
=D8=B3=D9=83=D8=B1=D9=90=D9=BE=D8=AA=D8=8C =
=D8=B3=D9=90=D9=85=D9=BE=D9=84=D9=8A =D8=AA=D9=8F =
=D9=8F=D9=86=D8=AF=D9=90=D8=B1=D8=B3=D8=AA=D9=8E=D9=86=D8=AF =
=D9=90=D9=85=D9=8E=D9=90=D9=84 =
=D9=8E=D8=AF=D8=AF=D8=B1=D9=90=D8=B3=D8=B3=D9=90=D8=B3=D8=8C =
=D9=8E=D9=86=D8=AF =D9=8E =D8=B3=D9=83=D8=B1=D9=90=D9=BE=D8=AA =
=D8=AA=D9=87=D9=8E=D8=AA =D9=83=D9=8F=D9=8F=D9=84=D8=AF =
=D9=8F=D9=86=D9=84=D9=8A =
=D9=BE=D9=8E=D8=B1=D8=AA=D9=8E=D9=90=D9=84=D9=84=D9=8A =
=D8=B1=D9=90=D9=81=D9=84=D9=90=D9=83=D8=AA =D8=AA=D9=87=D9=90 =
=D8=B1=D9=8E=D9=90=D9=84 =
=D8=B3=D9=BE=D9=90=D9=84=D9=84=D9=90=D9=86=DA=AF =D9=8F=D9=81 =
=D9=8A=D9=8F=D9=8F=D8=B1 =D9=88=D9=8F=D8=B1=D8=AF=D8=B3?

Mark
__________________________________

=20
----- Original Message -----=20
From: "Stephane Bortzmeyer" <[email-masked]>
To: "Mark Davis" <[email-masked]>
Cc: "Mark Crispin" <[email-masked]>; "Keith Moore" =
<[email-masked]>; <[email-masked]>; <[email-masked]>; =
<[email-masked]>; <[email-masked]>; <[email-masked]>; =
<[email-masked]>; <[email-masked]>; <[email-masked]>; =
<[email-masked]>; "IMAP Extensions WG" <[email-masked]>; =
<[email-masked]>; <[email-masked]>; <[email-masked]>; =
<[email-masked]>
Sent: Tue, 2003 Oct 28 00:50
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses =
(IEA)

> On Mon, Oct 27, 2003 at 05:39:32PM -0800,
>  Mark Davis <[email-masked]> wrote=20
>  a message of 76 lines which said:
>=20
> > We should remember that for a great many people in the world, Latin =
letters are
> > quite unnatural; it'd be a bit like if we had to use Greek letters =
in all email
> > addresses.=20
>=20
> It would be a bit like if we had to use Greek letters in mathematics
> :-)
>=20
> 
------=_NextPart_000_0068_01C39D20.5EDF9090
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
<META content=3D"MSHTML 6.00.2800.1264" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3D"Times New Roman">Sigh. I used "Greek" in an analogy =
because I=20
was hoping that some of the Latin-only folks out there would at least=20
recognize&nbsp;the name of one&nbsp;other script. But how comforable =
would you=20
really be, if =D9=8A=D9=8F=D9=8F =D9=88=D9=90=D8=B1=D9=90 =
=D9=81=D9=8F=D8=B1=D8=B3=D9=90=D8=AF =D8=AA=D9=8F =
=D8=B1=D9=8E=D9=90=D8=AF =D9=8E=D9=86 =
=D9=90=D9=86=D8=AA=D9=90=D8=B1=D9=90=D9=84=D9=8A =
=D8=AF=D9=90=D9=81=D9=81=D9=90=D8=B1=D9=90=D9=86=D8=AA =
=D8=B3=D9=83=D8=B1=D9=90=D9=BE=D8=AA=D8=8C =
=D8=B3=D9=90=D9=85=D9=BE=D9=84=D9=8A =D8=AA=D9=8F=20
=D9=8F=D9=86=D8=AF=D9=90=D8=B1=D8=B3=D8=AA=D9=8E=D9=86=D8=AF =
=D9=90=D9=85=D9=8E=D9=90=D9=84 =
=D9=8E=D8=AF=D8=AF=D8=B1=D9=90=D8=B3=D8=B3=D9=90=D8=B3=D8=8C =
=D9=8E=D9=86=D8=AF =D9=8E =D8=B3=D9=83=D8=B1=D9=90=D9=BE=D8=AA =
=D8=AA=D9=87=D9=8E=D8=AA =D9=83=D9=8F=D9=8F=D9=84=D8=AF =
=D9=8F=D9=86=D9=84=D9=8A =
=D9=BE=D9=8E=D8=B1=D8=AA=D9=8E=D9=90=D9=84=D9=84=D9=8A =
=D8=B1=D9=90=D9=81=D9=84=D9=90=D9=83=D8=AA =D8=AA=D9=87=D9=90=20
=D8=B1=D9=8E=D9=90=D9=84 =
=D8=B3=D9=BE=D9=90=D9=84=D9=84=D9=90=D9=86=DA=AF =D9=8F=D9=81 =
=D9=8A=D9=8F=D9=8F=D8=B1 =D9=88=D9=8F=D8=B1=D8=AF=D8=B3?</FONT></DIV>
<DIV><BR><FONT=20
size=3D2>Mark<BR>__________________________________<BR><BR>&nbsp;</FONT><=
/DIV>
<DIV><FONT size=3D2>----- Original Message ----- </FONT>
<DIV><FONT size=3D2>From: "Stephane Bortzmeyer" &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT =
size=3D2>[email-masked]</FONT></A><FONT=20
size=3D2>&gt;</FONT></DIV>
<DIV><FONT size=3D2>To: "Mark Davis" &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;</FONT></DIV>
<DIV><FONT size=3D2>Cc: "Mark Crispin" &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; "Keith =
Moore"=20
&lt;</FONT><A href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; =
&lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT =
size=3D2>[email-masked]</FONT></A><FONT=20
size=3D2>&gt;; &lt;</FONT><A href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT =
size=3D2>[email-masked]</FONT></A><FONT=20
size=3D2>&gt;; &lt;</FONT><A href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT =
size=3D2>[email-masked]</FONT></A><FONT=20
size=3D2>&gt;; &lt;</FONT><A href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; =
&lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT =
size=3D2>[email-masked]</FONT></A><FONT=20
size=3D2>&gt;; &lt;</FONT><A href=3D"mailto:[email-masked]"><FONT =

size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; "IMAP =
Extensions WG"=20
&lt;</FONT><A href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; =
&lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT =
size=3D2>[email-masked]</FONT></A><FONT=20
size=3D2>&gt;; &lt;</FONT><A href=3D"mailto:[email-masked]"><FONT =

size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; =
&lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; =
&lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT =
size=3D2>&gt;</FONT></DIV>
<DIV><FONT size=3D2>Sent: Tue, 2003 Oct 28 00:50</FONT></DIV>
<DIV><FONT size=3D2>Subject: Re: [idn] Re: FYI: BOF on Internationalized =
Email=20
Addresses (IEA)</FONT></DIV></DIV>
<DIV><FONT size=3D2><BR></FONT></DIV><FONT size=3D2>&gt; On Mon, Oct 27, =
2003 at=20
05:39:32PM -0800,<BR>&gt; &nbsp;Mark Davis &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt; wrote =
<BR>&gt; &nbsp;a=20
message of 76 lines which said:<BR>&gt; <BR>&gt; &gt; We should remember =
that=20
for a great many people in the world, Latin letters are<BR>&gt; &gt; =
quite=20
unnatural; it'd be a bit like if we had to use Greek letters in all=20
email<BR>&gt; &gt; addresses. <BR>&gt; <BR>&gt; It would be a bit like =
if we had=20
to use Greek letters in mathematics<BR>&gt; :-)<BR>&gt; <BR>&gt;=20
</FONT></BODY></HTML>

------=_NextPart_000_0068_01C39D20.5EDF9090--

From: Arnt Gulbrandsen <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Cc: [email-masked], [email-masked], IETF RFC-822 list <[email-masked]>, IMAA list <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked], Abhijit Menon-Sen <[email-masked]>, [email-masked], IETF/IDN WG <[email-masked]>
Date: Tue, 28 Oct 2003 11:15:17 +0100
Sender: [email-masked]

Mark Crispin writes:
> On Tue, 28 Oct 2003, Abhijit Menon-Sen wrote:
>> (I agree that it's currently nearly impossible to use computers if 
>> one isn't familiar with the Latin script, of course.)
>
> Which probably makes the rest of this discussion academic, unless 
> we're going to undertake solving *that* problem for Microsoft and the 
> various UNIX/Linux vendors...

You're not appreciating the full complexity of the problem. ;)

Not only should the email standards permit MUAs and MTAs of the year 
2020 to solve the problem Abhijit mentions, but they should even permit 
such future programs to interoperate with latinate ones of the present 
and near future. And if it's too hard for latinate MUAs to implement 
the IEA standard, that won't happen.

--Arnt

Date: Tue, 28 Oct 2003 01:13:50 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Pete Resnick <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, Dave Crocker <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Pete,

>>RB> Restricting the disucssion to local-parts runs the risk of excluding
>>RB> other potentially relevent issues.
PR> I agree. Limiting discussion at this point to local-part does not
PR> take into account some of the possibilities.

That was exactly the intent of the text.

We have already seen how nicely the text served to bring into pretty stark
relief one bit of expectation from one of the proposals. It is only fitting to
have it serve the same purpose for another one.

IETF BOF time is pretty lousy for an open-ended chat.  Having specifications
to chat about is only marginally better than not having them.

What makes the real difference is having serious focus to the meeting. If we
go into this meeting without even having a clear sense of the scope of the
problem to be tackled, then the chance of having a productive meeting is
pretty small.

At the moment, it appears that the focus of the meeting is likely to be:
Shall we break existing Internet mail or shall we lay an enhancement on top of
it that preserves the installed base.  (I'm sure that everyone else who was
present at the pre-MIME/ESMTP discussions is really looking forward to
repeating the experience.)

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

Date: Tue, 28 Oct 2003 09:50:23 +0100
From: Stephane Bortzmeyer <[email-masked]>
To: Mark Davis <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Organization: NIC France
Sender: [email-masked]

On Mon, Oct 27, 2003 at 05:39:32PM -0800,
 Mark Davis <[email-masked]> wrote 
 a message of 76 lines which said:

> We should remember that for a great many people in the world, Latin letters are
> quite unnatural; it'd be a bit like if we had to use Greek letters in all email
> addresses. 

It would be a bit like if we had to use Greek letters in mathematics
:-)

Date: Tue, 28 Oct 2003 01:20:58 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Cc: Roy Badami <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, Dave Crocker <[email-masked]>
Sender: [email-masked]

On 10/27/03 at 6:42 PM -0800, Dave Crocker wrote:

>RB> Even though, given IDNA now exists as a proposed standard, the main
>RB> issues relate to the local part, the issue under discussion is that of
>RB> internationalized mail addresses, not just internationalized
>RB> local-parts.
>
>Really?  What work needs to be done, except for local part?  IDNA takes care
>of the right-hand side.

Please review John Klensin's draft before making these kinds of assumptions.

>RB> Restricting the disucssion to local-parts runs the risk of excluding
>RB> other potentially relevent issues.

I agree. Limiting discussion at this point to local-part does not 
take into account some of the possibilities.

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

Date: Mon, 27 Oct 2003 20:42:19 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Abhijit Menon-Sen <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 28 Oct 2003, Abhijit Menon-Sen wrote:
> The number of people in India who can read and write only their native
> language, but have no usable knowledge of Latin script, is much larger
> than the tiny number who are familiar with both. I'm told that this is
> true for many native speakers of Chinese and Arabic as well.

I defer to your superior knowledge about India.

I do not believe that this is true for Chinese.  AFAIK, Chinese primary
school kids use Latin script with hanyu-pinyin as a stopgap prior to their
mastery of Han script (which takes many years).

> The use of local scripts is much more than just a "preference" for the
> numerous localisation efforts in India which focus on making computing
> more accessible to poor farmers and people in villages.

A poor farmer or villager in China is more likely to be totally illiterate
than to be literate in Han script but unable to recognize Latin script.

Note that when I say "recognize Latin script", I mean the ability to
determine that "dog" is a three-letter word that has the letters "d", "o",
and "g", each of which the individual recognizes and can name.  This does
not include the ability to recognize that this refers to a domesticated
canine.

> (I agree that it's currently nearly impossible to use computers if one
> isn't familiar with the Latin script, of course.)

Which probably makes the rest of this discussion academic, unless we're
going to undertake solving *that* problem for Microsoft and the various
UNIX/Linux vendors...

-- Mark --

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

Date: Tue, 28 Oct 2003 09:52:43 +0530
From: Abhijit Menon-Sen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

At 2003-10-27 19:37:37 -0800, [email-masked] wrote:
>
> I do not believe many individuals (other than primary school children) are
> literate in their native language but are completely illiterate in Latin
> script.  This does not mean "being able to read or write the English
> language"; rather, this simply means knowing the Latin script alphabet.

Mark,

The number of people in India who can read and write only their native
language, but have no usable knowledge of Latin script, is much larger
than the tiny number who are familiar with both. I'm told that this is
true for many native speakers of Chinese and Arabic as well.

The use of local scripts is much more than just a "preference" for the
numerous localisation efforts in India which focus on making computing
more accessible to poor farmers and people in villages.

(I agree that it's currently nearly impossible to use computers if one
isn't familiar with the Latin script, of course.)

-- ams

Date: Mon, 27 Oct 2003 19:37:37 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Mark Davis <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 27 Oct 2003, Mark Davis wrote:
> Based on what I've seen, I think it quite likely that people will want email
> addresses in their native script, even if that means that outsiders can't
> (easily) use those email address.

That may well be the case.

> We should remember that for a great many people in the world, Latin
> letters are quite unnatural; it'd be a bit like if we had to use Greek
> letters in all email addresses. And there are many projects underway in
> less-developed countries to bring computers to masses of people that
> will even less familiarity with Latin letters.

I am not convinced that it is possible to use a computer on the Internet
anywhere in the world without at least a basic acquaintance with Latin
script.

I do not believe many individuals (other than primary school children) are
literate in their native language but are completely illiterate in Latin
script.  This does not mean "being able to read or write the English
language"; rather, this simply means knowing the Latin script alphabet.

Put another way, individuals who are completely illiterate in Latin script
are also likely to be illiterate in their native language script as well.

No other script on the planet has such international recognition.

There is undoubtably a *preference* for one's native script; and that
preference should be respected as much as possible.

-- Mark --

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

Date: Mon, 27 Oct 2003 18:42:26 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Roy Badami <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Roy,

 >> Mail Internationalised Local-Part (MILP)

RB> Even though, given IDNA now exists as a proposed standard, the main
RB> issues relate to the local part, the issue under discussion is that of
RB> internationalized mail addresses, not just internationalized
RB> local-parts.

Really?  What work needs to be done, except for local part?  IDNA takes care
of the right-hand side.

So what is there to do about "internationalized mail addresses" other than the
local part?

RB> Restricting the disucssion to local-parts runs the risk of excluding
RB> other potentially relevent issues.  For instance, one of the issues
RB> that has been discussed on the IMAA list is whether full-width at
RB> should be recognized in an internationalized mail address.

full-width _where_?  somewhere other than local part?

if yes, then how can that be practical?  if no, then the charter does not
preclude their use.  (if you think otherwise, please explain.)

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

From: "Mark Davis" <[email-masked]>
To: "Mark Crispin" <[email-masked]>
Cc: "Keith Moore" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "IMAP Extensions WG" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Mon, 27 Oct 2003 17:39:32 -0800
Sender: [email-masked]

Ok, I understand more about the context.

Based on what I've seen, I think it quite likely that people will want email
addresses in their native script, even if that means that outsiders can't
(easily) use those email address. After all, it is quite easy to have multiple
email addresses. Mr. Tanaka can have one with Latin letters and one with
Japanese (e.g. [email-masked]).

We should remember that for a great many people in the world, Latin letters are
quite unnatural; it'd be a bit like if we had to use Greek letters in all email
addresses. And there are many projects underway in less-developed countries to
bring computers to masses of people that will even less familiarity with Latin
letters.

Mark
__________________________________
http://www.macchiato.com
► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- 
From: "Mark Crispin" <[email-masked]>
To: "Mark Davis" <[email-masked]>
Cc: "Keith Moore" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; "IMAP Extensions WG" <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Mon, 2003 Oct 27 17:15
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)

> On Mon, 27 Oct 2003, Mark Davis wrote:
> > I'm curious: why do you think that everyone would be satisfied with Latin
> > characters only, and no non-Latin characters?
>
> I didn't say that.  I stated my belief that, for reasons of practicality,
> most individuals in regions which do not use Latin script accept the use
> of Latin script for multinational exchange.
>
> It does not work well for an individual in Japan with surname Tanaka to
> expect the overwhelming majority of non-Japanese individuals worldwide to
> know his surname is written with the Han characters for "rice paddy" and
> "middle", or what those characters look like, or how to enter those
> characters on the computer.
>
> It does, however, work for him to expect that the overwhelming majority of
> individuals worldwide to know how to deal with the 6 Latin letters that
> form the romanization "Tanaka".
>
> Nor is it very likely that this situation will change in the future.  I
> doubt that many individuals in the world are literate in all the world's
> active scripts.  Literacy in one's native script and basic Latin script is
> something that most computer users possess today.
>
> For domestic exchange only, that pair of Han characters are probably
> alright.  Within Western Europe, it's probably alright to use Latin
> characters with diacriticals.
>
> Perhaps the main problem that needs to be decided in any IEA effort is if
> it is alright to have email addresses that are only usable in limited
> areas of the world; or if not, how to represent internationalized email
> addresses in a usable fashion when (not if) the email address needs to be
> represented for a person and/or computer is illiterate in that script.
>
> A likely side issue is whether it is "good enough" to promote Latin
> characters with diacriticals to the same status of "everybody must know
> how to do these" that is required for ASCII.
>
> -- Mark --
>
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
> Si vis pacem, para bellum.
>

Date: Mon, 27 Oct 2003 17:15:00 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Mark Davis <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 27 Oct 2003, Mark Davis wrote:
> I'm curious: why do you think that everyone would be satisfied with Latin
> characters only, and no non-Latin characters?

I didn't say that.  I stated my belief that, for reasons of practicality,
most individuals in regions which do not use Latin script accept the use
of Latin script for multinational exchange.

It does not work well for an individual in Japan with surname Tanaka to
expect the overwhelming majority of non-Japanese individuals worldwide to
know his surname is written with the Han characters for "rice paddy" and
"middle", or what those characters look like, or how to enter those
characters on the computer.

It does, however, work for him to expect that the overwhelming majority of
individuals worldwide to know how to deal with the 6 Latin letters that
form the romanization "Tanaka".

Nor is it very likely that this situation will change in the future.  I
doubt that many individuals in the world are literate in all the world's
active scripts.  Literacy in one's native script and basic Latin script is
something that most computer users possess today.

For domestic exchange only, that pair of Han characters are probably
alright.  Within Western Europe, it's probably alright to use Latin
characters with diacriticals.

Perhaps the main problem that needs to be decided in any IEA effort is if
it is alright to have email addresses that are only usable in limited
areas of the world; or if not, how to represent internationalized email
addresses in a usable fashion when (not if) the email address needs to be
represented for a person and/or computer is illiterate in that script.

A likely side issue is whether it is "good enough" to promote Latin
characters with diacriticals to the same status of "everybody must know
how to do these" that is required for ASCII.

-- Mark --

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

Date: Mon, 27 Oct 2003 20:08:25 -0500
From: Marc Blanchet <[email-masked]>
To: Dave Crocker <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

- good start!
- timeline seems pretty agressive... will see.
- would probably good to have a requirement document upfront. Might not the
same way that idn requirement ends up, but a narrow-implementable
requirement would help to have a concensus (hopefully) on what needs to be
done. 
- while the idn req went not that good, now that we have experience, I
think we should try to be better and have one.

I know I might start some debate with this, but still think it is the best
way to go...

- would be useful to have some reference to idn (idna) in the charter, as
background work. the developers and users will have to take care of "both"
(ie. idn and imail) in the email infrastructure.

Marc.

-- Monday, October 27, 2003 16:19:25 -0800 Dave Crocker <[email-masked]>
wrote/a ecrit:

> Folks,
> 
> On the theory that discussions go better when they have a concrete
> deliverable, here is a proposed charter for a proposed working group.
> 
> The following started with Mark Crispin's text, although it might not
> look it. Besides the usual goals for a charter, the following text
> attempts to specify the problem domain in the narrowest feasible form
> that is valid. If anyone thinks the scope is too narrow, they need to
> explain why.
> 
> 
> 
> DRAFT CHARTER
> 
> Mail Internationalised Local-Part (MILP)
> ---------------------------------
> 
> The <local-part> portion of RFC2822 and <Local-part> portion of RFC2821
> mail addresses are restricted to a subset of ASCII. This poses a
> fundamental barrier for users needing mail addresses to be expressed in a
> richer set of characters, such as Latin characters with diacriticals and
> the many Asian characters. The goal of the current work is to add
> local-part support for these additional characters, while preserving the
> large, installed base of ASCII usage.
> 
> The group will take:
> 
>    draft-hoffman-imaa-03.txt
>    draft-klensin-emailaddr-i18n-01.txt
>    draft-duerst-iri-04.txt
> 
> as input to discussions.
> 
> The group will pay particular attention to barriers to adoption and
> utility, as well as any impact the new scheme might have on the existing
> base of Internet mail usage.
> 
> 
> Milestones
> ----------
> 
> Nov, 03:  BOF
> 
> Dec, 03:  WG chartered
> 
> Feb, 03:  Initial draft of working group specifications.
> 
> Jun, 03:  Specifications submitted for IETF approval
> 
> 
> d/
> --
>  Dave Crocker <dcrocker-at-brandenburg-dot-com>
>  Brandenburg InternetWorking <www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>
> 

------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------

Date: Tue, 28 Oct 2003 00:50:53 +0000
To: Dave Crocker <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
From: Roy Badami <[email-masked]>
Sender: [email-masked]

 > Mail Internationalised Local-Part (MILP)

Even though, given IDNA now exists as a proposed standard, the main
issues relate to the local part, the issue under discussion is that of
internationalized mail addresses, not just internationalized
local-parts.

Restricting the disucssion to local-parts runs the risk of excluding
other potentially relevent issues.  For instance, one of the issues
that has been discussed on the IMAA list is whether full-width at
should be recognized in an internationalized mail address.  IMHO, the
charter shouldn't be framed in a way that is sufficiently narrow as to
render such questions out of scope.

	-roy

Date: Mon, 27 Oct 2003 16:19:25 -0800
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Folks,

On the theory that discussions go better when they have a concrete
deliverable, here is a proposed charter for a proposed working group.

The following started with Mark Crispin's text, although it might not look it.
Besides the usual goals for a charter, the following text attempts to specify
the problem domain in the narrowest feasible form that is valid. If anyone
thinks the scope is too narrow, they need to explain why.

DRAFT CHARTER

Mail Internationalised Local-Part (MILP)
---------------------------------

The <local-part> portion of RFC2822 and <Local-part> portion of RFC2821 mail
addresses are restricted to a subset of ASCII. This poses a fundamental
barrier for users needing mail addresses to be expressed in a richer set of
characters, such as Latin characters with diacriticals and the many Asian
characters. The goal of the current work is to add local-part support for
these additional characters, while preserving the large, installed base of
ASCII usage.

The group will take:

   draft-hoffman-imaa-03.txt
   draft-klensin-emailaddr-i18n-01.txt
   draft-duerst-iri-04.txt

as input to discussions.

The group will pay particular attention to barriers to adoption and utility,
as well as any impact the new scheme might have on the existing base of
Internet mail usage.

Milestones
----------

Nov, 03:  BOF

Dec, 03:  WG chartered

Feb, 03:  Initial draft of working group specifications.

Jun, 03:  Specifications submitted for IETF approval

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

From: "Mark Davis" <[email-masked]>
To: "Mark Crispin" <[email-masked]>, "Keith Moore" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Mon, 27 Oct 2003 16:16:20 -0800
Sender: [email-masked]

I'm curious: why do you think that everyone would be satisfied with Latin
characters only, and no non-Latin characters?

Mark
__________________________________
http://www.macchiato.com
► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- 
From: "Mark Crispin" <[email-masked]>
To: "Keith Moore" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Mon, 2003 Oct 27 11:10
Subject: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)

> On Mon, 27 Oct 2003, Keith Moore wrote:
>
>  >> Thanks for taking a stab at a problem statement.  I'd like to drill down
>  >> on this just a bit.
>  >> What is the source of the "growing need"?  Is it:
>  >> [snip]
>
>
> I agree that this needs to be stated, but someone other than me will have
> to do it.
>
> I believe that the primary push for this functionality comes from regions
> which use Latin alphabetics with diacriticals; and that most individuals
> in regions which do not use Latin script are accept the use of Latin
> script for multinational interchange.  In many regions where Latin
> diacriticals are used, there is no acceptable transform of a surname to a
> form that does not use diacriticals.  Simply omitting the diacritical
> causes (at least to the inhabitants of those regions) a misspelling.
>
> This set of beliefs naturally biases how I approach the problem.  The
> problem statement must be free of bias, including mine.
>
> -- Mark --
>
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
> Si vis pacem, para bellum.
>
>
>
>
>
>
>
>

Date: Mon, 27 Oct 2003 19:07:09 +0800
From: James Seng <[email-masked]>
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Pete Resnick <[email-masked]>, Ted Hardie <[email-masked]>, Ned Freed <[email-masked]>
Subject: Re: [idn] FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

I seen John and Paul proposal but I have not seen Michel. Is there a 
draft that I can read up?

ps: I wont be able to join the meeting but I am interested in the subject.

-James Seng

Patrik F�ltstr�m wrote:

> At the IETF in Minneapolis, there will be a BOF on Internationalized 
> Email Addresses (IEA).
> 
> It is *preliminary* on the agenda on Monday, November 10, 2003 at 
> 1530-1730.
> 
> Chairs:  Pete Resnick, Patrik F�ltstr�m
> Mailing list:[email-masked] (other salient lists include [email-masked])
> Agenda:
> 
> Agenda Bashing (Chairs)                5 min.
> Topic Introduction (Chairs)           10 min.
> Proposals
>   IDNA-Based (Paul Hoffman)           15 min.
>   Infrastructure-Based (John Klensin) 15 min.
>   IRI-Based (Michel Suignard)         15 min.
> 
> Discussion                            60 min.
> 
> Topics for discussion:
> 
>   Are there other solutions which have been specified?
> 
>   The solutions present the problem at different scopes;
> 
>      Where should the IETF tackle it?
> 
>      Are some short-term, and other long-term?
> 
>      Can the solutions be staged or co-exist?
> 
>      If staged, how to migrate from one to another?
> 
>   What are the next steps for the IETF?
> 
> 
> NB:  This BoF is exploratory in nature, and it is not intended that the 
> IETF will finalize a decision in this venue.  It was proposed to foster 
> a community discussion, not charter a working group or pick a winner. If 
> further work is required, step one would be identifying individuals 
> willing to carry that work forward.
> 
> Reading material:
>   draft-hoffman-imaa-03.txt
>   draft-klensin-emailaddr-i18n-01.txt
>   draft-duerst-iri-04.txt
> 
> Pete and myself hope people will come with a lot of constructive 
> comments and ideas.
> 
>         Patrik, co-chair of the bof
> 
> 
> 
> 
> 

Date: Mon, 27 Oct 2003 11:10:55 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Keith Moore <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

On Mon, 27 Oct 2003, Keith Moore wrote:
> Thanks for taking a stab at a problem statement.  I'd like to drill down
> on this just a bit.
> What is the source of the "growing need"?  Is it:
> [snip]

I agree that this needs to be stated, but someone other than me will have
to do it.

I believe that the primary push for this functionality comes from regions
which use Latin alphabetics with diacriticals; and that most individuals
in regions which do not use Latin script are accept the use of Latin
script for multinational interchange.  In many regions where Latin
diacriticals are used, there is no acceptable transform of a surname to a
form that does not use diacriticals.  Simply omitting the diacritical
causes (at least to the inhabitants of those regions) a misspelling.

This set of beliefs naturally biases how I approach the problem.  The
problem statement must be free of bias, including mine.

-- Mark --

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

Date: Mon, 27 Oct 2003 13:44:03 -0500
From: Keith Moore <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Mark,

Thanks for taking a stab at a problem statement.  I'd like to drill down
on this just a bit.

What is the source of the "growing need"?  Is it:

a. for users of many languages (particularly those not using Latin alphabets)
   email addresses are difficult to remember
b. for users of many languages (particularly those not using Latin alphabets)
   email addresses are difficult to transcribe or type
c. users want to use their names in email addresses
d. users are confused by apparently arbitrary restrictions on use of 
   characters in email addresses, and this leads to mistakes
e. on computer systems employing non-ASCII names for other purposes (e.g.
   login or account names) these do not map well to ASCII email addresses

or something else that I don't see?

> As presently constituted, email addresses are limited to the 26 Latin
> alphabetics, 10 digits, and a limited number of special characters in
> the ASCII character set.  There is a growing need to use additional
> characters, specifically Latin characters with diacriticals and
> non-Latin characters, in email addresses to better serve the needs of
> the multi-national Internet community.  However, the restrictions of
> ASCII email addresses have served as a "lingua franca" since everybody
> can enter ASCII email addresses, and there is an ongoing need for this
> as well.  The problem to be solved is the resolution of these two
> needs.

Date: Mon, 27 Oct 2003 12:49:31 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Arnt Gulbrandsen <[email-masked]>
CC: IMAP Interest List <[email-masked]>, Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Exchange server has a broken SASL implementation
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> Ken Murchison writes:
> 
>> Mark Crispin wrote:
>>
>>> Yet more proof that the SASL specifications as currently constituted 
>>> are too complex, and why IMAP should not add initial-response until 
>>> the SASL specifications are fixed.
>>
>>
>> Or its more proof that M$ doesn't care about specs and choose to 
>> [re]define then as they see fit.
> 
> 
> Do not attribute to malice that which can be adequately explained by 
> ignorance/release pressure/lack of time/blah/blah. So far, every 
> Microsoft programmer I've spoken to seemed to try hard. (I'm not saying 
> they succeed, but I _am_ saying they don't seem a malicious bunch.)

I didn't mean to imply that anything that doesn't meet the specs was 
done maliciously by the programmers (over frustration from replying to 
Outlook bug emails).  I have no knowledge that any mistakes are anything 
other than just simple mistakes.

However, if there is/was any question about the specs, there are mailing 
lists that can be contacted for clarification.  Interop testing could be 
done with non-MS products.  The CMU SASL library comes with test 
harnesses which can be used for testing.  There are at least 2 major 
MTAs (sendmail, postfix) which use CMU SASL that could have been 
consulted for comparison.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 27 Oct 2003 09:30:46 -0800
From: [email-masked] (WJCarpenter)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

mc> As presently constituted, email addresses are limited to the 26
mc> Latin alphabetics, 10 digits, and a limited number of special
mc> characters in the ASCII character set.  There is a growing need to

upper and lower case alphabetics
-- 
[email-masked] (WJCarpenter)    PGP 0x91865119
38 95 1B 69 C9 C6 3D 25    73 46 32 04 69 D6 ED F3

Date: Mon, 27 Oct 2003 09:17:54 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: Ken Murchison <[email-masked]>, IMAP Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Exchange server has a broken SASL implementation
Sender: [email-masked]

On Mon, 27 Oct 2003, Arnt Gulbrandsen wrote:
> Do not attribute to malice that which can be adequately explained by
> ignorance/release pressure/lack of time/blah/blah. So far, every
> Microsoft programmer I've spoken to seemed to try hard. (I'm not saying
> they succeed, but I _am_ saying they don't seem a malicious bunch.)

I agree with Arnt on all three of the above points.

> We're talking about a set of interrelated documents that are light on
> examples and free of a test suite. I'm not greatly surprised that
> people have trouble implementing them correctly.

We have seen this happen over and over again.  The documents are broken.

If Microsoft programmers don't care about specs and redefine them as they
see fit, then we can say the same thing about the programmers of almost
every other SASL server.

This is an *extremely* common blunder.

-- Mark --

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

Date: Mon, 27 Oct 2003 09:13:29 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Keith Moore <[email-masked]>
cc: Dave Crocker <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

On Mon, 27 Oct 2003, Keith Moore wrote:
> what problem are we trying to solve here?

I agree with Keith.  This isn't to say that I dispute that there is a
problem to be solved -- indeed, I think that the problem is apparent to
all -- but we must have a problem statement that we all agree upon before
we even think about solutions.

I don't think that references to drafts of proposed solutions suffice as a
problem statement.  Leaving aside questions of possible bias (= present a
problem in such a way that this is the obvious best solution), having the
problem statement in a draft (which by its nature is an ephemeral
document) muddies the issues.

The problem statement should consist of a single paragraph (and preferably
in one or two sentences), separate from any proposed solution, and stated
in a charter which is approved by everyone.

Here's a start at such a statement:

As presently constituted, email addresses are limited to the 26 Latin
alphabetics, 10 digits, and a limited number of special characters in the
ASCII character set.  There is a growing need to use additional
characters, specifically Latin characters with diacriticals and non-Latin
characters, in email addresses to better serve the needs of the
multi-national Internet community.  However, the restrictions of ASCII
email addresses have served as a "lingua franca" since everybody can enter
ASCII email addresses, and there is an ongoing need for this as well.  The
problem to be solved is the resolution of these two needs.

-- Mark --

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

From: Arnt Gulbrandsen <[email-masked]>
To: Ken Murchison <[email-masked]>
Subject: Re: Exchange server has a broken SASL implementation
Cc: IMAP Interest List <[email-masked]>, Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Mon, 27 Oct 2003 18:14:44 +0100
Sender: [email-masked]

Ken Murchison writes:
> Mark Crispin wrote:
>> Yet more proof that the SASL specifications as currently constituted 
>> are too complex, and why IMAP should not add initial-response until 
>> the SASL specifications are fixed.
>
> Or its more proof that M$ doesn't care about specs and choose to 
> [re]define then as they see fit.

Do not attribute to malice that which can be adequately explained by 
ignorance/release pressure/lack of time/blah/blah. So far, every 
Microsoft programmer I've spoken to seemed to try hard. (I'm not saying 
they succeed, but I _am_ saying they don't seem a malicious bunch.)

We're talking about a set of interrelated documents that are light on 
examples and free of a test suite. I'm not greatly surprised that 
people have trouble implementing them correctly.

(Larry: if there were a test suite for SMTP/SASL, would Microsoft have 
used it?)

--Arnt

Date: Mon, 27 Oct 2003 12:00:01 -0500
From: Marc Blanchet <[email-masked]>
To: Keith Moore <[email-masked]>, Dave Crocker <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

-- Monday, October 27, 2003 10:52:22 -0500 Keith Moore <[email-masked]>
wrote/a ecrit:

>> PF>    What are the next steps for the IETF?
>> 
>> Would it help to have a draft charter for the meeting?  
> 
> let's back up a step further.
> 
> what problem are we trying to solve here?

to me, that (problem we are trying to solve) would be part of the
introduction in the charter...

so I guess some initial proposal for:
- what are we trying to solve
- what would be the way to solve it

would be a good starting point together with the "state-of-the-art"
presentations.

Marc.

> 
> Keith

------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------

Date: Mon, 27 Oct 2003 10:37:21 -0600
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Cc: Dave Crocker <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On 10/27/03 at 10:52 AM -0500, Keith Moore wrote:

>>DC: Would it help to have a draft charter for the meeting?

As was mentioned in the draft agenda at 
<http://www.ietf.org/ietf/03nov/iea.txt>, we want to simply start the 
discussion, not immediately attempt to charter a working group.

>let's back up a step further.
>
>what problem are we trying to solve here?

Please have a look at draft-hoffman-imaa, 
draft-klensin-emailaddr-i18n, and draft-duerst-iri. Certainly the 
first two have very explicit descriptions of the problem.

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

Date: Mon, 27 Oct 2003 11:14:33 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Mark Crispin <[email-masked]>
CC: IMAP Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Exchange server has a broken SASL implementation
Sender: [email-masked]

Mark Crispin wrote:
> It looks like Microsoft finally implemented support for the GSSAPI SASL
> mechanism.
> 
> Unfortunately, they screwed it up.  In their SMTP server, they respond to
> the command "AUTH GSSAPI" with "334 gssapi supported".
> 
> Yet more proof that the SASL specifications as currently constituted are
> too complex, and why IMAP should not add initial-response until the SASL
> specifications are fixed.

Or its more proof that M$ doesn't care about specs and choose to 
[re]define then as they see fit.

Can you show me where the SASL specs or SMTP SASL profile gives them 
license to put garbage in the challenge?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 27 Oct 2003 10:52:22 -0500
From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

> PF>    What are the next steps for the IETF?
> 
> Would it help to have a draft charter for the meeting?  

let's back up a step further.

what problem are we trying to solve here?

Keith

Date: Mon, 27 Oct 2003 07:41:11 -0800
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: =?ISO-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?= <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, Pete Resnick <[email-masked]>, Ted Hardie <[email-masked]>, Ned Freed <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Patrik,

Thanks for putting this BOF together.

PF>       Where should the IETF tackle it?

I am not sure I understand this question.  Please clarify.

PF>    What are the next steps for the IETF?

Would it help to have a draft charter for the meeting?  (I realize that the
presence of such different specifications makes a charter at least a bit
challenging, but it seems to help to have a draft, to make things concrete.)

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

Date: Mon, 27 Oct 2003 07:35:22 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: IMAP Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Exchange server has a broken SASL implementation
Sender: [email-masked]

It looks like Microsoft finally implemented support for the GSSAPI SASL
mechanism.

Unfortunately, they screwed it up.  In their SMTP server, they respond to
the command "AUTH GSSAPI" with "334 gssapi supported".

Yet more proof that the SASL specifications as currently constituted are
too complex, and why IMAP should not add initial-response until the SASL
specifications are fixed.

-- 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]>, Ted Hardie <[email-masked]>, Ned Freed <[email-masked]>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Subject: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Sun, 26 Oct 2003 20:55:08 +0100
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At the IETF in Minneapolis, there will be a BOF on Internationalized 
Email Addresses (IEA).

It is *preliminary* on the agenda on Monday, November 10, 2003 at 
1530-1730.

Chairs:  Pete Resnick, Patrik F�ltstr�m
Mailing list:[email-masked] (other salient lists include [email-masked])
Agenda:

Agenda Bashing (Chairs)                5 min.
Topic Introduction (Chairs)           10 min.
Proposals
   IDNA-Based (Paul Hoffman)           15 min.
   Infrastructure-Based (John Klensin) 15 min.
   IRI-Based (Michel Suignard)         15 min.

Discussion                            60 min.

Topics for discussion:

   Are there other solutions which have been specified?

   The solutions present the problem at different scopes;

      Where should the IETF tackle it?

      Are some short-term, and other long-term?

      Can the solutions be staged or co-exist?

      If staged, how to migrate from one to another?

   What are the next steps for the IETF?

NB:  This BoF is exploratory in nature, and it is not intended that the 
IETF will finalize a decision in this venue.  It was proposed to foster 
a community discussion, not charter a working group or pick a winner. 
If further work is required, step one would be identifying individuals 
willing to carry that work forward.

Reading material:
   draft-hoffman-imaa-03.txt
   draft-klensin-emailaddr-i18n-01.txt
   draft-duerst-iri-04.txt

Pete and myself hope people will come with a lot of constructive 
comments and ideas.

         Patrik, co-chair of the bof

Date: Wed, 22 Oct 2003 12:24:05 -0400
From: Cyrus Daboo <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt
Sender: [email-masked]

Hi Rob,

--On Wednesday, October 22, 2003 12:14 -0400 Rob Siemborski 
<[email-masked]> wrote:

| I did just notice (in the GETANNOTATION text):
|
|     This command is only available in authenticated state [IMAP4].
|
| Shouldn't it also be available in the selected state?  AFAIK, they aren't
| the same.

OK - fixed in working copy.

-- 
Cyrus Daboo

Date: Wed, 22 Oct 2003 12:14:07 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt
Sender: [email-masked]

On Wed, 22 Oct 2003, Cyrus Daboo wrote:

> | I tend to agree that punting seems to be the safest option.
>
> Would you want to restrict GETANNOTATION in the same way?

Not offhand, GETANNOTATION can safely suffer partial failures,
e.g.:

* ANNOTATION
* ANNOTATION
x NO Couldn't contact some backend servers

I did just notice (in the GETANNOTATION text):

    This command is only available in authenticated state [IMAP4].

Shouldn't it also be available in the selected state?  AFAIK, they aren't
the same.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Wed, 22 Oct 2003 12:10:23 -0400
From: Cyrus Daboo <[email-masked]>
To: Rob Siemborski <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt
Sender: [email-masked]

Hi Rob,

--On Wednesday, October 22, 2003 12:05 -0400 Rob Siemborski 
<[email-masked]> wrote:

| On Wed, 22 Oct 2003, Arnt Gulbrandsen wrote:
|
|> Cyrus Daboo writes:
|> > There could be client applications that require an all-or-nothing
|> > change. That said having partial failure (or success) responses would
|> > be OK too. Either that or we punt the whole question by disallowing
|> > multi-mailbox operations in the first place.
|>
|> Punting seems like a good idea. If necessary, add language mentioning
|> that clients can send several store commands at the same time. (That
|> should be possible, as I remember the draft... right?)
|
| I tend to agree that punting seems to be the safest option.

Would you want to restrict GETANNOTATION in the same way?

-- 
Cyrus Daboo

Date: Wed, 22 Oct 2003 12:05:02 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt
Sender: [email-masked]

On Wed, 22 Oct 2003, Arnt Gulbrandsen wrote:

> Cyrus Daboo writes:
> > There could be client applications that require an all-or-nothing
> > change. That said having partial failure (or success) responses would
> > be OK too. Either that or we punt the whole question by disallowing
> > multi-mailbox operations in the first place.
>
> Punting seems like a good idea. If necessary, add language mentioning
> that clients can send several store commands at the same time. (That
> should be possible, as I remember the draft... right?)

I tend to agree that punting seems to be the safest option.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

From: Arnt Gulbrandsen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt
Cc: Rob Siemborski <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Date: Wed, 22 Oct 2003 17:19:37 +0200
Sender: [email-masked]

Cyrus Daboo writes:
> There could be client applications that require an all-or-nothing 
> change. That said having partial failure (or success) responses would 
> be OK too. Either that or we punt the whole question by disallowing 
> multi-mailbox operations in the first place.

Punting seems like a good idea. If necessary, add language mentioning 
that clients can send several store commands at the same time. (That 
should be possible, as I remember the draft... right?)

--Arnt

Date: Wed, 22 Oct 2003 10:40:34 -0400
From: Cyrus Daboo <[email-masked]>
To: Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt
Sender: [email-masked]

Hi Rob,

--On Wednesday, October 22, 2003 10:10 -0400 Rob Siemborski 
<[email-masked]> wrote:

|> >    If the server is unable to store the annotations for one or more
|> >    mailboxes matching the mailbox-name pattern, then the SETANNOTATION
|> >    command MUST fail and there MUST NOT be any changes to any of the
|> >    matching mailboxes, even those for which annotations could have been
|> >    changed successfully.
|>
|> So you want to limit ANNOTATEMORE to work only with servers using
|> transactional databases?
|
| This worries me, as it is a pretty severe implementation burden on IMAP
| proxies as well.
|
|> Maybe SETANNOTATION could rather just send untagged replies for
|> mailboxes it changes?
|
| Or perhaps untagged NO responses for those annotations it couldn't change.

There could be client applications that require an all-or-nothing change. 
That said having partial failure (or success) responses would be OK too. 
Either that or we punt the whole question by disallowing multi-mailbox 
operations in the first place.

-- 
Cyrus Daboo

Date: Wed, 22 Oct 2003 10:10:56 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt
Sender: [email-masked]

On Wed, 22 Oct 2003, Timo Sirainen wrote:

> >    If the server is unable to store the annotations for one or more
> >    mailboxes matching the mailbox-name pattern, then the SETANNOTATION
> >    command MUST fail and there MUST NOT be any changes to any of the
> >    matching mailboxes, even those for which annotations could have been
> >    changed successfully.
>
> So you want to limit ANNOTATEMORE to work only with servers using
> transactional databases?

This worries me, as it is a pretty severe implementation burden on IMAP
proxies as well.

> Maybe SETANNOTATION could rather just send untagged replies for
> mailboxes it changes?

Or perhaps untagged NO responses for those annotations it couldn't change.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Date: Wed, 22 Oct 2003 07:57:12 +0300
Sender: [email-masked]

>    If the server is unable to store the annotations for one or more
>    mailboxes matching the mailbox-name pattern, then the SETANNOTATION
>    command MUST fail and there MUST NOT be any changes to any of the
>    matching mailboxes, even those for which annotations could have been
>    changed successfully.

So you want to limit ANNOTATEMORE to work only with servers using
transactional databases?

Maybe SETANNOTATION could rather just send untagged replies for
mailboxes it changes?

To: IETF-Announce: ;
From: [email-masked]
Reply-to: [email-masked]
Date: Tue, 21 Oct 2003 15:58:32 -0400
Subject: I-D ACTION:draft-daboo-imap-annotatemore-04.txt
Sender: [email-masked]

--==========1DDCBDEFA700D5D5269E==========
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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

	Title		: IMAP ANNOTATEMORE Extension
	Author(s)	: C. Daboo
	Filename	: draft-daboo-imap-annotatemore-04.txt
	Pages		: 17
	Date		: 2003-10-21
	
The ANNOTATEMORE extension to the Internet Message Access Protocol
[IMAP4] permits clients and servers to maintain 'metadata' on IMAP4
servers.  It is possible to store data on a per-mailbox basis or on
the server as a whole.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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
	"get draft-daboo-imap-annotatemore-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-daboo-imap-annotatemore-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--==========1DDCBDEFA700D5D5269E==========
Content-Type: multipart/alternative;
 boundary="==========12F7B0FC35D353082042=========="

--==========12F7B0FC35D353082042==========
Content-Type: message/external-body; ACCESS-TYPE=mail-server;
 SERVER="[email-masked]"
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-daboo-imap-annotatemore-04.txt

--==========12F7B0FC35D353082042==========
Content-Type: message/external-body;
 name="draft-daboo-imap-annotatemore-04.txt"; SITE="ftp.ietf.org";
 ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID:	<[email-masked]>

--==========12F7B0FC35D353082042==========--

--==========1DDCBDEFA700D5D5269E==========--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-08.txt
Date: Tue, 21 Oct 2003 16:01:09 -0400
Sender: [email-masked]

--NextPart

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		: IMAP ANNOTATE Extension
	Author(s)	: R. Gellens, C. Daboo
	Filename	: draft-ietf-imapext-annotate-08.txt
	Pages		: 22
	Date		: 2003-10-21
	
The ANNOTATE extension to the Internet Message Access Protocol
[IMAP4] permits clients and servers to maintain 'metadata' for
messages stored in an IMAP4 mailbox.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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
	"get draft-ietf-imapext-annotate-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-annotate-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-annotate-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-annotate-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 20 Oct 2003 17:08:32 -0500
To: Lemonade <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: IMAP COMPOSE extension
Sender: [email-masked]

[Bcc'ed to IMAPEXT; please followup to LEMONADE]

I didn't have time last week to finish an I-D before the deadline, 
but I figured I should at least start the conversation on the list 
before Minneapolis.

When talking about IMAP Push vs. IMAP Pull for "forward without 
download" in Vienna, a lot of us thought that in either case, it 
would be handy to have an an IMAP COMPOSE command. The idea here 
would be COMPOSE would be pretty much like APPEND (with the mailbox 
in which to append, an optional flag list and optional date/time 
string), except that instead of a message literal, it would take as 
parameters any number of literals and "message part identifiers". All 
of the literals and the message parts would be appended together in 
the destination mailbox as one big message. The client would be 
responsible for providing the appropriate MIME boundaries in the 
literals.

Having a composed message on the IMAP server would work for either 
IMAP push or IMAP pull, and this would obviously be useful for more 
than just "forward without download".

However, I still have some issues with the exact nature of this 
command. Specifically, my big question is how to deal with the 
"message part identifiers". A message part identifier would clearly 
include a sequence number or UID followed by message data item names 
or a macro, just like FETCH. However, the downside to making it look 
exactly like the FETCH parameters is that you can only compose a 
message made up of parts that are contained in the currently selected 
mailbox. Maybe that is sufficient given the application for which 
LEMONADE wants this, but it's clearly a limitation.

The other choice is that the message part identifier would also 
include a mailbox name. We could come up with some syntax for that or 
just use a relative IMAP URL. Of course, the upside is that you'd be 
able to collect together messages in different parts of the IMAP 
store. But there are a couple of really big downsides:

1. It breaks the assumption that you only ever have one mailbox 
selected. In effect, you'd be required on the server to access 
multiple mailboxes in the course of a single command execution. Maybe 
that's OK to require for this extension; maybe not.

2. If it is allowed to be other than a relative URL to *this* IMAP 
server, suddenly you get into the business of doing all of the IMAP 
client work that folks were so worried about when this discussion 
started.

3. Allowing it to be a URL might start us down the slippery slope of 
allowing *any* kind of URL, not just IMAP. The results of that are 
left as an exercise to the reader.

Having the more general syntax (i.e., something that includes the 
mailbox) might be nice for folks who want to do fancier things in the 
future. We could allow any server to say "NO" if given something with 
another mailbox (or server, or scheme). Or maybe we don't want to do 
this at all.

Feedback desired. I'll float a straw-man proposal to the list (which 
obviously won't make it as an I-D for Minneapolis) as soon as I can.

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

From: "Madan Ganesh Velayudham" <[email-masked]>
To: "'Lyndon Nerenberg'" <[email-masked]>
Cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
Date: Sat, 18 Oct 2003 15:34:13 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Lyndon Nerenberg
> Sent: Saturday, October 18, 2003 12:41 AM
> To: Madan Ganesh Velayudham
> Cc: 'IMAP Extensions WG'
> Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
> 
> 
> 
> > 	I understand them clearly. My belif is that my solution
> > 	would have some performance benefits compared having them
> > 	externally.
> 
> Then do the math and prove it.

	Definitely.
> 
> > 	I will try to find some loop holes in sieve for	arugments :-)
> 
> Please stop wasting our time. We do engineering here. 
> Marketing is down 
> the hall.
	
	That was just a comment. Pls donot take it seriously.
> 
> --lyndon
> 

Date: Fri, 17 Oct 2003 13:10:51 -0600
From: Lyndon Nerenberg <[email-masked]>
To: Madan Ganesh Velayudham <[email-masked]>
cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
Sender: [email-masked]

--==========10C64BD7E4C20F34569B==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

> 	I understand them clearly. My belif is that my solution
> 	would have some performance benefits compared having them
> 	externally.

Then do the math and prove it.

> 	I will try to find some loop holes in sieve for	arugments :-)

Please stop wasting our time. We do engineering here. Marketing is down=20
the hall.

--lyndon
--==========10C64BD7E4C20F34569B==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==========10C64BD7E4C20F34569B==========--

Date: Fri, 17 Oct 2003 09:19:02 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Madan Ganesh Velayudham <[email-masked]>
cc: "'Mark Crispin'" <[email-masked]>, "'IMAP Extensions WG'" <[email-masked]>
Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
Sender: [email-masked]

On Fri, 17 Oct 2003, Madan Ganesh Velayudham wrote:

> 	Thanks for your recommendations. Could you please get
> 	me the wg that analyzes sieve.

There is currently no working group, however there are a bunch of people
who read the [email-masked] list.

http://www.imc.org/ietf-mta-filters/index.html

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

From: Arnt Gulbrandsen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: SASL Initial Response?
Cc: Ken Murchison <[email-masked]>, Rob Siemborski <[email-masked]>, Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Fri, 17 Oct 2003 14:51:16 +0200
Sender: [email-masked]

Cyrus Daboo writes:
> A summary of the profiles and mechanisms - not a full detailed 
> description of each. This could be as simple as a table listing which 
> options a particular protocol's profile provides. e.g.:

That table belongs on www.iana.org, doesn't it? Like the (hopelessly 
outdated) IMAP extensions page.

> | b) a document that points out common errors in SASL implementations
>
> Yes..

Like 2683? Good idea, but I can't even comment on it, far less suggest 
appropriate content.

--Arnt

From: "Madan Ganesh Velayudham" <[email-masked]>
To: "'Mark Crispin'" <[email-masked]>
Cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
Date: Fri, 17 Oct 2003 17:33:26 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

> 
> Capabilities are defined in RFC 3501 as atoms.  You can not 
> have multi-atom capabilities.  This is an ongoing design 
> issue which other capabilities have had to face (and has had 
> considerable discussion) but as yet there is no clear solution.
> 

	Thanks for the explanation.

> I need to reiterate that sieve already has this 
> functionality, and quite a bit more.  You should be looking 
> into sieve rather than trying to shoehorn an orthogonal (and 
> much less functional) capability into IMAP.

	Hmm.. That was an effort to embedd the logic in IMAP.
	I will analyze further on this.

> 
> In most environments, filters are done in the MTA and/or MDA, 
> especially when a filter is a defined set of rules which are 
> executed for all incoming mail.  Filters are generally not 
> done in the MUA (such as an IMAP
> server) because of the problem of executing a filter 
> repetitively on the same data; when it is done the MUA often 
> has to undertake heroic (and sometimes unsuccessful) efforts 
> to avoid this problem.
> 
> In most environments, IMAP servers are completely separate 
> from the MTA and MDA.  There would be a substantial 
> implementation burden to create an intercommunication of 
> filtering information between the IMAP server and a separate 
> MTA/MDA (perhaps from a different vendor).
> 
> It is not likely that you will have much success convincing 
> either IMAP or MTA/MDA server implementors to implement your 
> extension, especially since sieve already addresses these 
> needs and quite a bit more.
> 
> In general, IETF protocols avoid having multiple solutions 
> for the same problem.  When multiple solutions exist, there 
> is strong pressure to have one solution win and the others 

	I understand them clearly. My belif is that my solution
	would have some performance benefits compared having them
	externally. 

	I will try to find some loop holes in sieve for	arugments :-)

> pass into oblivion.  For many years, there was such pressure 
> between IMAP and POP since these two protocols seemingly did 
> the same thing.  And, to be honest, it is likely that IMAP 
> would not have happened had I known about POP.

	I like this point very much :-)

> 
> I strongly urge you to look into sieve, and become involved 
> in that development effort.  You will find many helpful 
> people working on sieve, and you'll achieve your goals much 
> faster.  Otherwise, you are likely to end up having wasted 
> your time (and other people's time) with no results to show for it.

	Thanks for your recommendations. Could you please get
	me the wg that analyzes sieve.

	+MG

> -----Original Message-----
> From: Mark Crispin [mailto:[email-masked]] 
> Sent: Friday, October 17, 2003 12:35 AM
> To: Madan Ganesh Velayudham
> Cc: 'IMAP Extensions WG'; [email-masked]
> Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
> 
> 
> On Fri, 17 Oct 2003, Madan Ganesh Velayudham wrote:
> > 	* CAPABILITY IMAP4rev1 AUTH=DIGEST-MD5ORGANIZE=ADD,UPDATE
> > 	[APPEND,DELETE,STORE],REMOVE,ENABLE,DISABLE,LIST
> >
> > 	I understand [APPEND, ... ] is the one which you are
> > 	mentioning. Pls correct me if I'm wrong. I shall correct it
> > 	while refining the draft.
> 
> Capabilities are defined in RFC 3501 as atoms.  You can not 
> have multi-atom capabilities.  This is an ongoing design 
> issue which other capabilities have had to face (and has had 
> considerable discussion) but as yet there is no clear solution.
> 
> > > As such, this functionality does not seem to be within 
> the scope of 
> > > IMAP; and instead belongs with Sieve.
> > 	+ Client need nt do extra operations.
> >
> > 	+ I'm trying to leverage already available IMAP commands
> > 	( APPEND, STORE, Search Criterias, etc., ) to implement
> > 	this organization of message for user. I feel there wont be
> > 	much implementation strain : code reusability.
> >
> > 	+ Many customers would be interested in single entity which
> > 	will do the required tasks instead of having two independent
> > 	entities.
> 
> I need to reiterate that sieve already has this 
> functionality, and quite a bit more.  You should be looking 
> into sieve rather than trying to shoehorn an orthogonal (and 
> much less functional) capability into IMAP.
> 
> In most environments, filters are done in the MTA and/or MDA, 
> especially when a filter is a defined set of rules which are 
> executed for all incoming mail.  Filters are generally not 
> done in the MUA (such as an IMAP
> server) because of the problem of executing a filter 
> repetitively on the same data; when it is done the MUA often 
> has to undertake heroic (and sometimes unsuccessful) efforts 
> to avoid this problem.
> 
> In most environments, IMAP servers are completely separate 
> from the MTA and MDA.  There would be a substantial 
> implementation burden to create an intercommunication of 
> filtering information between the IMAP server and a separate 
> MTA/MDA (perhaps from a different vendor).
> 
> It is not likely that you will have much success convincing 
> either IMAP or MTA/MDA server implementors to implement your 
> extension, especially since sieve already addresses these 
> needs and quite a bit more.
> 
> In general, IETF protocols avoid having multiple solutions 
> for the same problem.  When multiple solutions exist, there 
> is strong pressure to have one solution win and the others 
> pass into oblivion.  For many years, there was such pressure 
> between IMAP and POP since these two protocols seemingly did 
> the same thing.  And, to be honest, it is likely that IMAP 
> would not have happened had I known about POP.
> 
> I strongly urge you to look into sieve, and become involved 
> in that development effort.  You will find many helpful 
> people working on sieve, and you'll achieve your goals much 
> faster.  Otherwise, you are likely to end up having wasted 
> your time (and other people's time) with no results to show for it.
> 
> -- Mark --
> 
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Thu, 16 Oct 2003 15:24:43 -0600
From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: IMAP Organize Extension
Sender: [email-masked]

--==========C47C3D6041106DB99DBE==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The functionality of Organize already exists in SIEVE.

Pushing the configuration of MDA filters into multiple unrelated=20
protocols is just bad engineering.

Also, this document falsely claims to be a product of the WG, which it is =

not. It's not even within the scope of the WG charter.

This draft should be withdrawn immediately. We should instead focus on=20
getting ManageSieve onto the standards track.

--lyndon
--==========C47C3D6041106DB99DBE==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==========C47C3D6041106DB99DBE==========--

Date: Thu, 16 Oct 2003 16:23:55 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Madan Ganesh Velayudham <[email-masked]>
cc: "'Mark Crispin'" <[email-masked]>, "'IMAP Extensions WG'" <[email-masked]>, [email-masked]
Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
Sender: [email-masked]

On Fri, 17 Oct 2003, Madan Ganesh Velayudham wrote:

> > In fact, it seems to me that sieve is more flexible than this
> > extension ever could be, since it is embeddable without
> > protocol changes in any mail handling program (IMAP server,
> > LMTP/SMTP server, POP client, etc).
> >
> 	+ Many customers would be interested in single entity which
> 	will do the required tasks instead of having two independent
> 	entities.

What users may perceive as a single entity does not need to be a single
protocol on the wire.  In fact, a single server product can support
multiple protocols and provide this functionality and the administrators
can still see it as a single product.

For example, Cyrus implements mail filtering with Sieve scripts that can
be manage remotely without touching the IMAP protocol at all.  Users can
have a mail client that supports both IMAP and MANAGESIEVE and have it
maintain their filters *and* read their mail.  The client can even support
Sieve itself and provide a GUI to manipulate the filters.

This doesn't require an extension to IMAP, and Sieve is already more
flexible than the much more limited set of IMAP operations (In addition to
simple file/reject/discard type actions, there are currently extensions
for vacation messages, spam/virus scoring, regular expressions, relational
comparisons and so on).

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Thu, 16 Oct 2003 15:38:55 -0400
From: Tony Hansen <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

Alexey Melnikov wrote:
> As I am the guilty party I should probably comment on this. It is quite 
> common for base64 encoding/decoding to be implemented by utility 
> functions that you steal from your friend or just implemented in a 
> library written by somebody-who-no-longer-works-for-the-company ten 
> years ago. These functions may have assumptions quite different from 
> those of IMAP AUTHENTICATE, because they could have been written for a 
> different environment. For example they were originally used to handle 
> MIME base64, which allows for spaces and CRLFs.

Ditto. I was using a base64 library and it worked great, until I had a string 
that caused the base64 output to be >76 characters and it inserted a crlf.

Sigh.

	Tony Hansen
	[email-masked]

Date: Thu, 16 Oct 2003 12:04:51 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Madan Ganesh Velayudham <[email-masked]>
cc: "'IMAP Extensions WG'" <[email-masked]>, [email-masked]
Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
Sender: [email-masked]

On Fri, 17 Oct 2003, Madan Ganesh Velayudham wrote:
> 	* CAPABILITY IMAP4rev1 AUTH=DIGEST-MD5ORGANIZE=ADD,UPDATE
> 	[APPEND,DELETE,STORE],REMOVE,ENABLE,DISABLE,LIST
>
> 	I understand [APPEND, ... ] is the one which you are
> 	mentioning. Pls correct me if I'm wrong. I shall correct it
> 	while refining the draft.

Capabilities are defined in RFC 3501 as atoms.  You can not have
multi-atom capabilities.  This is an ongoing design issue which other
capabilities have had to face (and has had considerable discussion) but as
yet there is no clear solution.

> > As such, this functionality does not seem to be within the
> > scope of IMAP; and instead belongs with Sieve.
> 	+ Client need nt do extra operations.
>
> 	+ I'm trying to leverage already available IMAP commands
> 	( APPEND, STORE, Search Criterias, etc., ) to implement
> 	this organization of message for user. I feel there wont be
> 	much implementation strain : code reusability.
>
> 	+ Many customers would be interested in single entity which
> 	will do the required tasks instead of having two independent
> 	entities.

I need to reiterate that sieve already has this functionality, and quite a
bit more.  You should be looking into sieve rather than trying to shoehorn
an orthogonal (and much less functional) capability into IMAP.

In most environments, filters are done in the MTA and/or MDA, especially
when a filter is a defined set of rules which are executed for all
incoming mail.  Filters are generally not done in the MUA (such as an IMAP
server) because of the problem of executing a filter repetitively on the
same data; when it is done the MUA often has to undertake heroic (and
sometimes unsuccessful) efforts to avoid this problem.

In most environments, IMAP servers are completely separate from the MTA
and MDA.  There would be a substantial implementation burden to create an
intercommunication of filtering information between the IMAP server and a
separate MTA/MDA (perhaps from a different vendor).

It is not likely that you will have much success convincing either IMAP or
MTA/MDA server implementors to implement your extension, especially since
sieve already addresses these needs and quite a bit more.

In general, IETF protocols avoid having multiple solutions for the same
problem.  When multiple solutions exist, there is strong pressure to have
one solution win and the others pass into oblivion.  For many years, there
was such pressure between IMAP and POP since these two protocols seemingly
did the same thing.  And, to be honest, it is likely that IMAP would not
have happened had I known about POP.

I strongly urge you to look into sieve, and become involved in that
development effort.  You will find many helpful people working on sieve,
and you'll achieve your goals much faster.  Otherwise, you are likely to
end up having wasted your time (and other people's time) with no results
to show for it.

-- Mark --

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

From: "Madan Ganesh Velayudham" <[email-masked]>
To: "'Rob Siemborski'" <[email-masked]>, "'Mark Crispin'" <[email-masked]>
Cc: "'IMAP Extensions WG'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
Date: Fri, 17 Oct 2003 00:34:07 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

Hi Rob,

	Thanks for your comments.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rob Siemborski
> Sent: Thursday, October 16, 2003 2:21 AM
> To: Mark Crispin
> Cc: IMAP Extensions WG; [email-masked]
> Subject: Re: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
> 
> 
> 
> On Wed, 15 Oct 2003, Mark Crispin wrote:
> 
> > As such, this functionality does not seem to be within the scope of 
> > IMAP; and instead belongs with Sieve.  Not withstanding the 
> attractive 
> > nuisance of rendering IMAP into Exchange ("shove everything 
> remotely 
> > related to email into one protocol"), I don't see how ORGANIZE 
> > provides any added value over Sieve.
> 
> I agree with Mark's comments.  I don't see any win here over 
> sieve, except that the client can avoid making the additional 
> MANAGESIEVE connection to update its filtering rules, which 
> is not compelling enough to try to reimplement all of Sieve's 
> functionality inside of the IMAP protocol.

	As I mentioned in Mark's reply, I'm trying to leverage 
	existing IMAP commands feature to orgainze user mails.

> 
> (Which reminds me -- MANAGESIEVE has yet to be published as 
> an RFC, I should probably bother Tim again).

	I've just went through the abstract of it and understand that
	managing sieve script remotely.

> 
> In fact, it seems to me that sieve is more flexible than this 
> extension ever could be, since it is embeddable without 
> protocol changes in any mail handling program (IMAP server, 
> LMTP/SMTP server, POP client, etc).
> 
	+ Many customers would be interested in single entity which
	will do the required tasks instead of having two independent
	entities.

	Please let me know your comments.

	Thanks again,
	MG

> -Rob
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Rob Siemborski | Andrew Systems Group * Research Systems 
> Programmer PGP:0x5CE32FCC | Cyert Hall 207 * 
> [email-masked] * 412.268.7456 -----BEGIN GEEK CODE BLOCK----
> Version: 3.12
> GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ 
> N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ 
> DI+++ G e h r- y? ------END GEEK CODE BLOCK-----
> 
> 

From: "Madan Ganesh Velayudham" <[email-masked]>
To: "'Mark Crispin'" <[email-masked]>, "'IMAP Extensions WG'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
Date: Fri, 17 Oct 2003 00:06:53 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

Hi Mark,

	Thanks for your comments.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mark Crispin
> Sent: Thursday, October 16, 2003 1:41 AM
> To: IMAP Extensions WG
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
> 
> 
> 
> Leaving aside the bugs in this specification (for example, 
> the added capabilities violate RFC 3501, security 
> considerations are glossed over), it seems that the purpose 
> of this proposed extension is not to "organize", but rather 
> to define MDA filtering rules.

	* CAPABILITY IMAP4rev1 AUTH=DIGEST-MD5ORGANIZE=ADD,UPDATE 
	[APPEND,DELETE,STORE],REMOVE,ENABLE,DISABLE,LIST

	I understand [APPEND, ... ] is the one which you are 
	mentioning. Pls correct me if I'm wrong. I shall correct it 
	while refining the draft.

	Since the ORGANIZE command is in autenticated state, 
	only users with proper credentials can have access to
	PUOT.

	I will definitely elaborate 3.2 Section ... 
	[ When the IMAP server receives... It performs the specified 
	action.. ] to include more implementation issues. How IMAP 
	could behave for append, delete, store operations. In future,
	I would like expand these operations to include forwarding 
	messages, automatic response for messages, etc. I could 
	understand that the much emphasis is on define organizing 
	(filtering)	rules. I understand I should elaborate it.

> 
> As such, this functionality does not seem to be within the 
> scope of IMAP; and instead belongs with Sieve.  Not 
> withstanding the attractive nuisance of rendering IMAP into 
> Exchange ("shove everything remotely related to email into 
> one protocol"), I don't see how ORGANIZE provides any added 
> value over Sieve.

	+ Client need nt do extra operations.

	+ I'm trying to leverage already available IMAP commands
	( APPEND, STORE, Search Criterias, etc., ) to implement 
	this organization of message for user. I feel there wont be
	much implementation strain : code reusability.

	+ Many customers would be interested in single entity which
	will do the required tasks instead of having two independent
	entities.

> 
> The proposed SMTP extension for ORGANIZE is bizarre.  The 
> purpose seems to be to shoehorn manipulation of MDA filtering 
> rules into yet another orthogonal protocol (plus note the 
> syntax errors in the example).  The SMTP extensions people 
> can shoot that down.
> 

	I understand it and will definitely correct any errors.
Actually,
	the idea that I came to me, just thought capture them in the
draft
	merely I don't want to extent this part. This is just an idea.

	Thanks again,
	MG

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

Date: Thu, 16 Oct 2003 19:06:40 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Rob Siemborski <[email-masked]>, Cyrus Daboo <[email-masked]>, Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

Mark Crispin wrote:

>Another damning point.  Just recently, it was claimed that RFC 3501 does
>not enforce BASE64 syntax in the AUTHENTICATE command.  The Formal Syntax
>says otherwise; but that was countered with "nobody reads the formal
>syntax."  Or, as in the case with Courier server, the formal syntax is
>openly defied if it does not match how the implementor chooses to
>interpret the main text.
>
As I am the guilty party I should probably comment on this. It is quite 
common for base64 encoding/decoding to be implemented by utility 
functions that you steal from your friend or just implemented in a 
library written by somebody-who-no-longer-works-for-the-company ten 
years ago. These functions may have assumptions quite different from 
those of IMAP AUTHENTICATE, because they could have been written for a 
different environment. For example they were originally used to handle 
MIME base64, which allows for spaces and CRLFs.

(And I am actually talking from my own experience and I've ended up 
discovering certain side effects of a base64 decoder I has borrowed).

So, explicitly emphasizing some problems with existing base64 decoders 
will not hurt.

>Perhaps if we lived in a world in which it was a criminal offense to
>distribute non-compliant protocol implementations, we might see greater
>attention to specifications.  I don't see that happening; if anything I
>see an increasingly lackadasical approach to specifications.
>
>Thus, we need more pedagogical texts, separate from the specifications, if
>we hope to retain any interoperability at all.
>
Exactly.

Alexey

Date: Thu, 16 Oct 2003 10:37:43 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Thu, 16 Oct 2003, Rob Siemborski wrote:
> Do you mean:
> a) a document that includes SASL profiles for all of these protocols
> b) a document that points out common errors in SASL implementations
> c) a document akin to STD 1 that just points at the documents
> that define various SASL profiles.

What I would think would be a "SASL for Dummies"; that is, a document
which gives a "how to" overview of SASL along with real-life examples.

We live in a world full of implementors who do not read specifications.
This isn't just with hacker-wannabees in the open source community;
vendors are hiring such individuals.

There's also a matter of blunder; simply not understanding how seemingly
unrelated statements interact (or, for that matter, the significance of a
seemingly unimportant statement).  As I pointed out before, many POP and
SMTP server SASL implementations fail to handle properly the case when the
client does not provide an initial response for the PLAIN mechanism.

Rob's new set of I-Ds should help a lot.  But it should also tell us that
we can not depend upon specifications, especially syntax of the
specification, to get people to do the right thing.

Another damning point.  Just recently, it was claimed that RFC 3501 does
not enforce BASE64 syntax in the AUTHENTICATE command.  The Formal Syntax
says otherwise; but that was countered with "nobody reads the formal
syntax."  Or, as in the case with Courier server, the formal syntax is
openly defied if it does not match how the implementor chooses to
interpret the main text.

Perhaps if we lived in a world in which it was a criminal offense to
distribute non-compliant protocol implementations, we might see greater
attention to specifications.  I don't see that happening; if anything I
see an increasingly lackadasical approach to specifications.

Thus, we need more pedagogical texts, separate from the specifications, if
we hope to retain any interoperability at all.

-- Mark --

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

Date: Thu, 16 Oct 2003 13:36:17 -0400
From: Cyrus Daboo <[email-masked]>
To: Rob Siemborski <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: Mark Crispin <[email-masked]>, Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

Hi Rob,

--On Thursday, October 16, 2003 13:30 -0400 Rob Siemborski 
<[email-masked]> wrote:

| (c) seems likely to fall out of date.

It would have to be updated on a regular basis to account for new protocols 
and mechanisms, but the document will point to the definitive place to get 
the most up to date information (e.g. IANA for mechanisms).

-- 
Cyrus Daboo

Date: Thu, 16 Oct 2003 13:33:06 -0400
From: Cyrus Daboo <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Mark Crispin <[email-masked]>, Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

Hi Rob,

--On Thursday, October 16, 2003 12:55 -0400 Rob Siemborski 
<[email-masked]> wrote:

| I'm somewhat confused by what you're proposing here Cyrus...
|
| Do you mean:
|
| a) a document that includes SASL profiles for all of these protocols

A summary of the profiles and mechanisms - not a full detailed description 
of each. This could be as simple as a table listing which options a 
particular protocol's profile provides. e.g.:

Protocol        Initial Response        Base64 Encoding  Relevant RFCs
                Supported

IMAP            No                      Yes              3501
ACAP            Yes                     Yes              2244
SMTP            Yes                     Yes              2821, 2554
etc

Mechanism       Initial Response        Supports Security  RFCs
                Allowed                 Layer

CRAM-MD5        No                      No                 2195
DIGEST-MD5      Sometimes (see rfc)     Yes                2831
GSSAPI          Yes                     Yes                2222
etc

| b) a document that points out common errors in SASL implementations

Yes..

| c) a document akin to STD 1 that just points at the documents
| that define various SASL profiles.

The table should list the references.

-- 
Cyrus Daboo

Date: Thu, 16 Oct 2003 13:30:40 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Mark Crispin <[email-masked]>, Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Thu, 16 Oct 2003, Alexey Melnikov wrote:

> >I'm somewhat confused by what you're proposing here Cyrus...
> >
> >Do you mean:
> >
> >a) a document that includes SASL profiles for all of these protocols
> >b) a document that points out common errors in SASL implementations
> >c) a document akin to STD 1 that just points at the documents
> >that define various SASL profiles.
> >
> I think Cyrus was talking about b) with some pieces of c).
>
> After writing HTTP SASL spec and reviewing XMPP/BEEP/SMTP/etc. I am
> willing to invest effort in this.

Ok.  (b) seems worthwhile but I wonder if there is enough there to justify
a document separate from RFC2222bis.

(c) seems likely to fall out of date.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Thu, 16 Oct 2003 18:23:52 +0100
From: Alexey Melnikov <[email-masked]>
To: Rob Siemborski <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, Mark Crispin <[email-masked]>, Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

Rob Siemborski wrote:

>On Thu, 16 Oct 2003, Cyrus Daboo wrote:
>  
>
>>I think what would be handy is to have a single informational RFC, that
>>could be continually updated, that summarizes all the SASL profiles for
>>standard protocols that use it. i.e. the document would describe how IMAP,
>>ACAP, SMTP, POP3, LDAP, BEEP etc all use SASL paying particular attention
>>to implementation differences (the initial response has been shown to be
>>one problem). This document could list the relevant RFCs to read to get the
>>specifics for implementing each profile. i.e. it would be the something
>>akin t the IMAP implementer's guide but for SASL.
>>    
>>
>
>I'm somewhat confused by what you're proposing here Cyrus...
>
>Do you mean:
>
>a) a document that includes SASL profiles for all of these protocols
>b) a document that points out common errors in SASL implementations
>c) a document akin to STD 1 that just points at the documents
>that define various SASL profiles.
>
I think Cyrus was talking about b) with some pieces of c).

After writing HTTP SASL spec and reviewing XMPP/BEEP/SMTP/etc. I am 
willing to invest effort in this.

Alexey

Date: Thu, 16 Oct 2003 12:55:40 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Mark Crispin <[email-masked]>, Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Thu, 16 Oct 2003, Cyrus Daboo wrote:

> I think what would be handy is to have a single informational RFC, that
> could be continually updated, that summarizes all the SASL profiles for
> standard protocols that use it. i.e. the document would describe how IMAP,
> ACAP, SMTP, POP3, LDAP, BEEP etc all use SASL paying particular attention
> to implementation differences (the initial response has been shown to be
> one problem). This document could list the relevant RFCs to read to get the
> specifics for implementing each profile. i.e. it would be the something
> akin t the IMAP implementer's guide but for SASL.

I'm somewhat confused by what you're proposing here Cyrus...

Do you mean:

a) a document that includes SASL profiles for all of these protocols
b) a document that points out common errors in SASL implementations
c) a document akin to STD 1 that just points at the documents
that define various SASL profiles.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Thu, 16 Oct 2003 08:43:12 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Thu, 16 Oct 2003, Cyrus Daboo wrote:
> I think what would be handy is to have a single informational RFC, that
> could be continually updated, that summarizes all the SASL profiles for
> standard protocols that use it. i.e. the document would describe how IMAP,
> ACAP, SMTP, POP3, LDAP, BEEP etc all use SASL paying particular attention
> to implementation differences (the initial response has been shown to be
> one problem). This document could list the relevant RFCs to read to get the
> specifics for implementing each profile. i.e. it would be the something
> akin t the IMAP implementer's guide but for SASL.

This is an excellent idea.

-- Mark --

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

Date: Thu, 16 Oct 2003 11:39:45 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Ken Murchison <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

Hi Mark,

{Coming into this debate late since I've been on vacation...]

--On Tuesday, October 7, 2003 18:33 -0700 Mark Crispin 
<[email-masked]> wrote:

|> At the very least, shouldn't the IMAP initial response doc and revised
|> SMTP AUTH and POP3 AUTH docs be able to proceed in parallel, especially
|> if they all use similar language for the initial client response issue?
|
| The question is if the SMTP and POP3 documents are going to advance or
| not.  This also depends upon the SASL document.  I'd like to hear IESG
| feedback on this.

Clearly implementing SASL across multiple protocols is problematic because 
you have to read multiple documents to fully understand what optional 
features are supported etc.

I think what would be handy is to have a single informational RFC, that 
could be continually updated, that summarizes all the SASL profiles for 
standard protocols that use it. i.e. the document would describe how IMAP, 
ACAP, SMTP, POP3, LDAP, BEEP etc all use SASL paying particular attention 
to implementation differences (the initial response has been shown to be 
one problem). This document could list the relevant RFCs to read to get the 
specifics for implementing each profile. i.e. it would be the something 
akin t the IMAP implementer's guide but for SASL.

-- 
Cyrus Daboo

Date: Wed, 15 Oct 2003 16:50:35 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
Sender: [email-masked]

On Wed, 15 Oct 2003, Mark Crispin wrote:

> As such, this functionality does not seem to be within the scope of IMAP;
> and instead belongs with Sieve.  Not withstanding the attractive nuisance
> of rendering IMAP into Exchange ("shove everything remotely related to
> email into one protocol"), I don't see how ORGANIZE provides any added
> value over Sieve.

I agree with Mark's comments.  I don't see any win here over sieve, except
that the client can avoid making the additional MANAGESIEVE connection to
update its filtering rules, which is not compelling enough to try to
reimplement all of Sieve's functionality inside of the IMAP protocol.

(Which reminds me -- MANAGESIEVE has yet to be published as an RFC, I
should probably bother Tim again).

In fact, it seems to me that sieve is more flexible than this extension
ever could be, since it is embeddable without protocol changes in any mail
handling program (IMAP server, LMTP/SMTP server, POP client, etc).

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Wed, 15 Oct 2003 13:11:21 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
Sender: [email-masked]

Leaving aside the bugs in this specification (for example, the added
capabilities violate RFC 3501, security considerations are glossed over),
it seems that the purpose of this proposed extension is not to "organize",
but rather to define MDA filtering rules.

As such, this functionality does not seem to be within the scope of IMAP;
and instead belongs with Sieve.  Not withstanding the attractive nuisance
of rendering IMAP into Exchange ("shove everything remotely related to
email into one protocol"), I don't see how ORGANIZE provides any added
value over Sieve.

The proposed SMTP extension for ORGANIZE is bizarre.  The purpose seems to
be to shoehorn manipulation of MDA filtering rules into yet another
orthogonal protocol (plus note the syntax errors in the example).  The
SMTP extensions people can shoot that down.

-- Mark --

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

From: Arnt Gulbrandsen <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Cc: Alexey Melnikov <[email-masked]>, Rob Siemborski <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Date: Wed, 15 Oct 2003 10:43:55 +0200
Sender: [email-masked]

Mark Crispin writes:
> On Tue, 14 Oct 2003, Rob Siemborski wrote:
>>  I have replaced that paragraph with:
>>
>>  When decoding the [BASE64] data in the initial client response, 
>>  decoding errors MUST be treated as [IMAP4] would handle them in any 
>>  normal SASL client response. In particular, the server should check 
>>  for any characters not explicitly allowed by the BASE64 alphabet, 
>>  as well as any sequence of BASE64 characters that contains the pad 
>>  character ('=') anywhere other than the end of the string (e.g. 
>>  "=AAA" and "AAA=BBB" are not allowed).
>
> Excellent. Thanks!

I like it.

--Arnt

Date: Tue, 14 Oct 2003 11:32:54 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, IMAP extensions Mailing List <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 14 Oct 2003, Rob Siemborski wrote:
> I have replaced that paragraph with:
>
> When decoding the [BASE64] data in the initial client response, decoding
> errors MUST be treated as [IMAP4] would handle them in any normal SASL
> client response.  In particular, the server should check for
> any characters not explicitly allowed by the BASE64 alphabet, as well as
> any sequence of BASE64 characters that contains the pad character ('=')
> anywhere other than the end of the string (e.g. "=AAA" and "AAA=BBB" are
> not allowed).

Excellent.  Thanks!

-- Mark --

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

Date: Tue, 14 Oct 2003 14:25:59 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, IMAP extensions Mailing List <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

On Tue, 14 Oct 2003, Mark Crispin wrote:

> > replacing it with something like "When base64 decoding the initial
> > response argument, it MUST be treated as [IMAP4] would treat any
> > other SASL client response.")
>
> It wouldn't hurt to add expository text with something like the original
> wording, just for emphasis.

I have replaced that paragraph with:

When decoding the [BASE64] data in the initial client response, decoding
errors MUST be treated as [IMAP4] would handle them in any normal SASL
client response.  In particular, the server should check for
any characters not explicitly allowed by the BASE64 alphabet, as well as
any sequence of BASE64 characters that contains the pad character ('=')
anywhere other than the end of the string (e.g. "=AAA" and "AAA=BBB" are
not allowed).

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Tue, 14 Oct 2003 11:10:08 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, IMAP extensions Mailing List <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 14 Oct 2003, Rob Siemborski wrote:
> In that case, I am inclined to drop the paragraph from this draft (perhaps
> replacing it with something like "When base64 decoding the initial
> response argument, it MUST be treated as [IMAP4] would treat any
> other SASL client response.")

It wouldn't hurt to add expository text with something like the original
wording, just for emphasis.

-- Mark --

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

Date: Tue, 14 Oct 2003 13:58:17 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, IMAP extensions Mailing List <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

On Tue, 14 Oct 2003, Mark Crispin wrote:

> > > This stuff is over and above the restrictions imposed by RFC 3501
> > > section 6.2.2.
> > Since Alexey was the one who wanted me to add this, I'll ask him to
> > comment here.
>
> I'm not Alexey, but I'll comment anyway.
>
> RFC 3501 fully supports the proposed restrictions in the Formal Syntax.
> Characters that are not in the BASE64 alphabet and non-terminal = are
> specifically prohibited in the formal syntax, violation of which leads to
> a BAD.
>
> Just because something isn't explicitly mentioned in expository text (such
> as 6.2.2) does not mean that it isn't there.

In that case, I am inclined to drop the paragraph from this draft (perhaps
replacing it with something like "When base64 decoding the initial
response argument, it MUST be treated as [IMAP4] would treat any
other SASL client response.")

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Tue, 14 Oct 2003 18:12:12 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Arnt Gulbrandsen <[email-masked]>, Rob Siemborski <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

Mark Crispin wrote:

>On Tue, 14 Oct 2003, Alexey Melnikov wrote:
>  
>
>>>This stuff is over and above the restrictions imposed by RFC 3501
>>>section 6.2.2.
>>>      
>>>
>>Yes. The base IMAP spec should be updated as well.
>>    
>>
>
>As noted in my previous message, this is unnecessary except as an
>explanatory note.  The Formal Syntax is already clear on this point.
>
Yes, but nobody reads ABNF anyway ;-).

You are right, "this is not a bug", but I suggest you add some text, as 
this is a known issue that causes problems already.

Alexey

Date: Tue, 14 Oct 2003 10:00:43 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, Rob Siemborski <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 14 Oct 2003, Alexey Melnikov wrote:
> > This stuff is over and above the restrictions imposed by RFC 3501
> > section 6.2.2.
> Yes. The base IMAP spec should be updated as well.

As noted in my previous message, this is unnecessary except as an
explanatory note.  The Formal Syntax is already clear on this point.

-- Mark --

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

Date: Tue, 14 Oct 2003 09:59:12 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, IMAP extensions Mailing List <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 14 Oct 2003, Rob Siemborski wrote:
> >      If the server cannot decode the [BASE64] data
> >      transmitted by the client, the server MUST fail the authentication
> >      with a tagged BAD response.  In particular, the server MUST reject
> >      (and not ignore) any characters not explicitly allowed by the BASE64
> >      alphabet, and should reject any sequence of BASE64 characters that
> >      contains the pad character ('=') anywhere other than the end of the
> >      string (e.g. "=AAA" and "AAA=BBB" are not allowed).
> > This stuff is over and above the restrictions imposed by RFC 3501
> > section 6.2.2.
> Since Alexey was the one who wanted me to add this, I'll ask him to
> comment here.

I'm not Alexey, but I'll comment anyway.

RFC 3501 fully supports the proposed restrictions in the Formal Syntax.
Characters that are not in the BASE64 alphabet and non-terminal = are
specifically prohibited in the formal syntax, violation of which leads to
a BAD.

Just because something isn't explicitly mentioned in expository text (such
as 6.2.2) does not mean that it isn't there.

-- Mark --

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

Date: Tue, 14 Oct 2003 17:42:12 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: Rob Siemborski <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

Arnt Gulbrandsen wrote:

>     If the server cannot decode the [BASE64] data
>     transmitted by the client, the server MUST fail the authentication
>     with a tagged BAD response.  In particular, the server MUST reject
>     (and not ignore) any characters not explicitly allowed by the BASE64
>     alphabet, and should reject any sequence of BASE64 characters that
>     contains the pad character ('=') anywhere other than the end of the
>     string (e.g. "=AAA" and "AAA=BBB" are not allowed).
>
> This stuff is over and above the restrictions imposed by RFC 3501 
> section 6.2.2.

Yes. The base IMAP spec should be updated as well.

> I don't feel pedantic enough to look up the original base64 RFC and 
> see if there's equivalent text there.

Unfortunately the base64 RFC was published before the issue was raised. 
There are problems in real world that different implementations treat 
invalid (as shown in the text above) base64 text in different ways. Some 
implementations just ignore invalid characters. Others truncate data at 
the first '='. And other reject the value (the right think). base64 is 
silent on this and this causes problems.

> Either there is, and the text is superfluous, or there isn't, and the 
> quoted text is a syntax difference of the kind I don't want.

Cheers,
Alexey
__________________________________________
Isode Limited, http://www.isode.com

Cell: +44 7753759732

IETF standard related pages:
http://orthanc.ab.ca/mel/devel/Links.html

Personal Home Page: http://orthanc.ab.ca/mel
__________________________________________

From: Arnt Gulbrandsen <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Cc: Rob Siemborski <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Date: Tue, 14 Oct 2003 18:32:25 +0200
Sender: [email-masked]

Mark Crispin writes:
> On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote:
>>  With SMTP, the server can know that the client supports initial responses.
>
> Say WHAT?????
>
> Where did you get THAT???

Too tired. I mixed "mandatory for SMTP servers" up with "mandatory in 
SMTP". Sorry.

--Arnt

Date: Tue, 14 Oct 2003 12:28:31 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote:

> Good. They aren't the same as the document stands now. There are 2-3
> extra restrictions, both/all small.
>
>      If the client needs to transmit an
>      initial response which is a zero-length string, it MUST transmit a
>      single equals sign ("=").  This indicates that the response is
>      present, but is a zero-length string.
>
> There's a MUST here, although I'm not sure whether it represents an
> additional requirement over and above RFC 3501.
>
> Let me suggest a rewording. "To send a zero-length initial response, the
> client can send a single pad character ("="). When decoded, this will
> result in a zero-length string on the server." Or perhaps use "AUTH
> EXTERNAL =" as an example. Either way, it's the same meaning, no
> additional restrictions.

I think this needs to be "the client MUST" for interoperability purposes.
But I am willing to rework this and add the EXTERNAL example (which is
good).

Note that this only refers to the SASL initial response (as it is included
with the AUTHENTICATE command), not to any part of the negotiation that
proceeds later.  Do you perhaps want text to that effect?

>      If the server cannot decode the [BASE64] data
>      transmitted by the client, the server MUST fail the authentication
>      with a tagged BAD response.  In particular, the server MUST reject
>      (and not ignore) any characters not explicitly allowed by the BASE64
>      alphabet, and should reject any sequence of BASE64 characters that
>      contains the pad character ('=') anywhere other than the end of the
>      string (e.g. "=AAA" and "AAA=BBB" are not allowed).
>
> This stuff is over and above the restrictions imposed by RFC 3501
> section 6.2.2. I don't feel pedantic enough to look up the original
> base64 RFC and see if there's equivalent text there. Either there is,
> and the text is superfluous, or there isn't, and the quoted text is a
> syntax difference of the kind I don't want.

Since Alexey was the one who wanted me to add this, I'll ask him to
comment here.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

From: Arnt Gulbrandsen <[email-masked]>
To: Rob Siemborski <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Cc: IMAP extensions Mailing List <[email-masked]>
Date: Tue, 14 Oct 2003 18:27:40 +0200
Sender: [email-masked]

Rob Siemborski writes:
> On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote:
>> I'm proposing that whether or not the server supports your extension, 
>> the rules that govern the client's first response should be the 
>> same.
>
> I agree.

Good. They aren't the same as the document stands now. There are 2-3 
extra restrictions, both/all small.

     If the client needs to transmit an
     initial response which is a zero-length string, it MUST transmit a
     single equals sign ("=").  This indicates that the response is
     present, but is a zero-length string.

There's a MUST here, although I'm not sure whether it represents an 
additional requirement over and above RFC 3501.

Let me suggest a rewording. "To send a zero-length initial response, the 
client can send a single pad character ("="). When decoded, this will 
result in a zero-length string on the server." Or perhaps use "AUTH 
EXTERNAL =" as an example. Either way, it's the same meaning, no 
additional restrictions.

     If the server cannot decode the [BASE64] data
     transmitted by the client, the server MUST fail the authentication
     with a tagged BAD response.  In particular, the server MUST reject
     (and not ignore) any characters not explicitly allowed by the BASE64
     alphabet, and should reject any sequence of BASE64 characters that
     contains the pad character ('=') anywhere other than the end of the
     string (e.g. "=AAA" and "AAA=BBB" are not allowed).

This stuff is over and above the restrictions imposed by RFC 3501 
section 6.2.2. I don't feel pedantic enough to look up the original 
base64 RFC and see if there's equivalent text there. Either there is, 
and the text is superfluous, or there isn't, and the quoted text is a 
syntax difference of the kind I don't want.

Thanks for taking the trouble to write the spec.

--Arnt

Date: Tue, 14 Oct 2003 12:07:58 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

On Tue, 14 Oct 2003, Mark Crispin wrote:

> On Tue, 14 Oct 2003, Rob Siemborski wrote:
> > > Mandatory to implement. With SMTP, the server can know that the client
> > > supports initial responses.
> > Sure, it knows that it supports it, but that doesn't change the fact that
> > the server still must deal with the client leaving off the initial
> > response.  That's part of the sasl specification.
>
> Huh???
>
> The server must implement initial responses in POP3 and SMTP, but there is
> no requirement that the client do so since the client can always omit it.

Yes, this is correct.  I misspoke.

FWIW, I hope that draft-siemborski-rfc2554bis-00.txt clarifies this
situation.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Tue, 14 Oct 2003 09:06:32 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

On Tue, 14 Oct 2003, Rob Siemborski wrote:
> > Mandatory to implement. With SMTP, the server can know that the client
> > supports initial responses.
> Sure, it knows that it supports it, but that doesn't change the fact that
> the server still must deal with the client leaving off the initial
> response.  That's part of the sasl specification.

Huh???

The server must implement initial responses in POP3 and SMTP, but there is
no requirement that the client do so since the client can always omit it.

-- Mark --

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

Date: Tue, 14 Oct 2003 09:05:15 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: Rob Siemborski <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote:
> With SMTP, the server can know that the client
> supports initial responses.

Say WHAT?????

Where did you get THAT???

-- Mark --

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

Date: Tue, 14 Oct 2003 12:03:01 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote:

> Rob Siemborski writes:
> > So you're proposing a situation where an extension that has an empty
> > string as an initial response is penalized a round trip:
>
> Not at all.
>
> I'm proposing that whether or not the server supports your extension,
> the rules that govern the client's first response should be the same.

I agree.

> >> SMTP is different - initial responses are m-t-i there.
> >
> > I'm sorry, What is m-t-i?
>
> Mandatory to implement. With SMTP, the server can know that the client
> supports initial responses.

Sure, it knows that it supports it, but that doesn't change the fact that
the server still must deal with the client leaving off the initial
response.  That's part of the sasl specification.

> With IMAP that's not the case. With IMAP,
> the first response may be an initial response, or it may be a response
> to an empty challenge. Either way, the syntax should be the same.

Either way, the syntax is the same.  The sever doesn't care if the client
supports initial response or not.  At the application level, it's not even
allowed to care!

If the client doesn't support an initial response, *or* the client doesn't
choose to send an initial response, then the negotiation proceeds the same
way: there was no initial response.

For example, in the DIGEST-MD5 case, where there *is* a difference (fast
reauth or not)  in both of the above cases, you proceed without fast
reauth.  The server doesn't care about the reason.

FWIW, EXTERNAL is likely to send an empty initial response.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

From: Arnt Gulbrandsen <[email-masked]>
To: Rob Siemborski <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Cc: IMAP extensions Mailing List <[email-masked]>
Date: Tue, 14 Oct 2003 18:00:14 +0200
Sender: [email-masked]

Rob Siemborski writes:
> So you're proposing a situation where an extension that has an empty 
> string as an initial response is penalized a round trip:

Not at all.

I'm proposing that whether or not the server supports your extension, 
the rules that govern the client's first response should be the same.

>> SMTP is different - initial responses are m-t-i there.
>
> I'm sorry, What is m-t-i?

Mandatory to implement. With SMTP, the server can know that the client 
supports initial responses. With IMAP that's not the case. With IMAP, 
the first response may be an initial response, or it may be a response 
to an empty challenge. Either way, the syntax should be the same.

--Arnt

Date: Tue, 14 Oct 2003 11:54:18 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

On Tue, 14 Oct 2003, Rob Siemborski wrote:

> clearly says "there is an initial response here, but it is the empty
> string"
>
> vs
>
> AUTHENTICATE MUMBLE
>
> which is required to mean "no initial response"
>
> Without the "=", you're required to fall back to the old behavior.

I suppose you could also do

"AUTHENTICATE MUMBLE "

to indicate an empty response.

Is that what you were proposing instead?

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Tue, 14 Oct 2003 11:46:21 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote:

> I can see that empty responses may one day be meaningful. However, I
> cannot see what's special about the combination of empty responses and
> this extension.
>
> Suppose AUTH=MUMBLE has some feature whereby an empty response makes
> sense. Shouldn't it work basically the same way whether this extension
> is present or not?
>
> C: a AUTHENTICATE MUMBLE
> S: +
> C: =
> ...

No, in this case you'd use the normal SASL negotiation, you wouldn't have
an =.

> or
>
> C: a AUTHENTICATE MUMBLE =
> ...
>
> IMO, the "=" should be governed by the same syntax in both cases, so the
> extension should avoid specifying new rules. Now that I think about it,
> I suppose that argument covers my base64 queasiness too - the argument
> should use the same rules as the same response would follow in the
> absence of the extension.

So you're proposing a situation where an extension that has an empty
string as an initial response is penalized a round trip:

AUTHENTICATE MUMBLE =

clearly says "there is an initial response here, but it is the empty
string"

vs

AUTHENTICATE MUMBLE

which is required to mean "no initial response"

Without the "=", you're required to fall back to the old behavior.

> > FWIW, SMTP does this.
>
> SMTP is different - initial responses are m-t-i there.

I'm sorry, What is m-t-i?

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

From: Arnt Gulbrandsen <[email-masked]>
To: Rob Siemborski <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Cc: IMAP extensions Mailing List <[email-masked]>
Date: Tue, 14 Oct 2003 17:44:32 +0200
Sender: [email-masked]

Rob Siemborski writes:
> On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote:
>> 2. The extension's capability name sounds a little inappropriate. 
>> This extension isn't "the SASL extension". I suggest SASL-IR 
>> instead.
>
> I was originally using SASLINITIAL, but it was suggested that I use 
> "SASL" instead because IMAP now "fully supports SASL" (well, as much 
> as it can without a client-side-capability extension, which would be 
> needed for server-last-sends).

"PRACTICALLYSASL"? Please not ;)

> Frankly, I don't really care what capability name is used, but I'd 
> like this to not be a continual point of argument.

I'd rather see your initial name than the current, but either way I've 
had my say about it.

> Whaile it is true that no current mechanisms have a situation where 
> they can send an empty initial response, a mechanism might be 
> developed where there may be something distinguising about the client 
> sending an empty initial send and the client omiting the initial send 
> (think of behavior like DIGEST-MD5 fast reauth). We need to handle 
> the two cases separately.

I can see that empty responses may one day be meaningful. However, I 
cannot see what's special about the combination of empty responses and 
this extension.

Suppose AUTH=MUMBLE has some feature whereby an empty response makes 
sense. Shouldn't it work basically the same way whether this extension 
is present or not?

C: a AUTHENTICATE MUMBLE
S: +
C: =
...

or

C: a AUTHENTICATE MUMBLE =
...

IMO, the "=" should be governed by the same syntax in both cases, so the 
extension should avoid specifying new rules. Now that I think about it, 
I suppose that argument covers my base64 queasiness too - the argument 
should use the same rules as the same response would follow in the 
absence of the extension.

> FWIW, SMTP does this.

SMTP is different - initial responses are m-t-i there.

--Arnt

Date: Tue, 14 Oct 2003 11:12:30 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote:

> 1. The server must reject, not ignore, any characters outside the base64
> alphabet. Ditto = before the end.
>
> Why that? I can see it makes sense, but I'm tired of minor differences.
> Won't stock base64 do?

This was Alexey's suggestion due to bugs in base64 parsers.

> 2. The extension's capability name sounds a little inappropriate. This
> extension isn't "the SASL extension". I suggest SASL-IR instead.

I was originally using SASLINITIAL, but it was suggested that I use "SASL"
instead because IMAP now "fully supports SASL" (well, as much as it can
without a client-side-capability extension, which would be needed for
server-last-sends).

Frankly, I don't really care what capability name is used, but I'd like
this to not be a continual point of argument.

> 3. The draft makes mandates specific syntax for empty initial responses.
> I don't lik that. For one thing, under what circumstances would a
> client _need_ to send an empty initial response? That is, as opposed to
> sending no initial response at all? For another, why shouldn't the same
> rules as for other empty responses apply? (I confess I didn't look
> those up.)

There is a difference between "" and NULL, as there is a difference
between omiting the initial response and encoding an empty string.

Whaile it is true that no current mechanisms have a situation where they
can send an empty initial response, a mechanism might be developed
where there may be something distinguising about the client sending an
empty initial send and the client omiting the initial send (think of
behavior like DIGEST-MD5 fast reauth).  We need to handle the two cases
separately.

FWIW, SMTP does this.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

From: Arnt Gulbrandsen <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Date: Tue, 14 Oct 2003 14:08:54 +0200
Sender: [email-masked]

[email-masked] writes:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>         Title         : IMAP Extension for SASL Initial Client Response
>         Author(s)       : R. Siemborski
>         Filename        : draft-siemborski-imap-sasl-initial-response-00.txt

I'll skip the big issue and comment on some small ones.

1. The server must reject, not ignore, any characters outside the base64 
alphabet. Ditto = before the end.

Why that? I can see it makes sense, but I'm tired of minor differences. 
Won't stock base64 do?

2. The extension's capability name sounds a little inappropriate. This 
extension isn't "the SASL extension". I suggest SASL-IR instead.

3. The draft makes mandates specific syntax for empty initial responses. 
I don't lik that. For one thing, under what circumstances would a 
client _need_ to send an empty initial response? That is, as opposed to 
sending no initial response at all? For another, why shouldn't the same 
rules as for other empty responses apply? (I confess I didn't look 
those up.)

--Arnt

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Date: Mon, 13 Oct 2003 11:15:25 -0400
Sender: [email-masked]

--NextPart

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

	Title		: IMAP Extension for SASL Initial Client Response
	Author(s)	: R. Siemborski
	Filename	: draft-siemborski-imap-sasl-initial-response-00.txt
	Pages		: 7
	Date		: 2003-10-10
	
To date, the Internet Message Access Protocol (IMAP) has used a
Simple Authentication and Security Layer (SASL) profile which always
required at least one complete round trip for an authentication, as
it did not support an initial client response argument.  This
additional round trip at the beginning of the session is
undesirable, especially when round trip costs are high.

This document defines an extension to IMAP which allows clients and
servers to avoid this round trip by allowing an initial client
response argument to the IMAP AUTHENTICATE command.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-siemborski-imap-sasl-initial-response-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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
	"get draft-siemborski-imap-sasl-initial-response-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-siemborski-imap-sasl-initial-response-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-siemborski-imap-sasl-initial-response-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-siemborski-imap-sasl-initial-response-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 7 Oct 2003 18:33:51 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Tue, 7 Oct 2003, Ken Murchison wrote:
> I don't see why implementations which are clearly broken and in
> violation of the specs (regardless of how poorly written those specs may
> or may not be), should prevent the IMAP initial client response
> extension from proceeding as long as it avoids/corrects the problems
> with the SMTP AUTH and POP3 AUTH specs.

Ken, I believe that you are are thinking about a specification whereas I
am thinking more about human nature.  We have to allow for Murphy's Law.

The IMAP spec will be much more complicated than the SMTP or POP3 specs,
because IMAP is server-optional on initial response.  That is four support
states, whereas SMTP and POP3 only have two

> At the very least, shouldn't the IMAP initial response doc and revised
> SMTP AUTH and POP3 AUTH docs be able to proceed in parallel, especially
> if they all use similar language for the initial client response issue?

The question is if the SMTP and POP3 documents are going to advance or
not.  This also depends upon the SASL document.  I'd like to hear IESG
feedback on this.

Without some surety that the SMTP/POP3 situation is fixed, I feel like I
am being asked to leap from a tall building, based upon unproven claims
that the building is on fire and with equally unproven assurances that by
the time I reach the ground, you will have contrived to have erected a
net.

I don't see any urgency for initial response in IMAP; it is cosmetic or a
minor RTT savings at best.  We can afford to take the time to do it right.

-- Mark --

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

From: Steve Hole <[email-masked]>
Date: Tue, 7 Oct 2003 14:43:35 -0600
To: Mark Crispin <[email-masked]>
Subject: Re: SASL Initial Response?
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Tue, 7 Oct 2003 10:52:59 -0700 (Pacific Daylight Time) Mark Crispin 
<[email-masked]> wrote:

> Hi Steve -
> 
> I'm afraid that you misunderstood the issue.  The problem is not broken
> server interoperability with clients that send initial responses to SMTP
> and POP3 servers; rather, it is broken server interoperability with
> clients that do NOT send the initial responses.

Ah!   Sorry about that.

---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Tue, 07 Oct 2003 14:28:15 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

Mark Crispin wrote:

> It is for this reason that I think that the proponents of an initial
> response on the command line should back off until the specifications are
> clarified such that these broken SMTP and POP3 servers stop happening.

I don't see why implementations which are clearly broken and in 
violation of the specs (regardless of how poorly written those specs may 
or may not be), should prevent the IMAP initial client response 
extension from proceeding as long as it avoids/corrects the problems 
with the SMTP AUTH and POP3 AUTH specs.

At the very least, shouldn't the IMAP initial response doc and revised 
SMTP AUTH and POP3 AUTH docs be able to proceed in parallel, especially 
if they all use similar language for the initial client response issue?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Tue, 7 Oct 2003 14:00:20 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Steve Hole <[email-masked]>
cc: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Tue, 7 Oct 2003, Steve Hole wrote:

> Perhaps the larger surprise is why people suddenly feel this important.
> Cutting a round trip is nice if you're connecting/reconnecting a lot, but
> I'm not sure why you would want to do that.   In general, the cost of
> select/examine is pretty high and part of the channel setup.  It more or
> less mandates efficient use of connection pooling and maintenance. Over
> highly latent connections, anything that reduces roundtrips is useful
> though.

Personally, I don't think its "suddenly important."  I just think that the
lack of initial response here is unfortunate given that it violates a
SASL SHOULD.  Of course, the reason for this is because IMAP AUTHENTICATE
came before SASL, but that doesn't preclude it being fixed by an
extension.

> Personally I'd be thinking about synchronization optimizations
> first.   Let's see ... which set of message had flags that have changed
> since this time??

Doesn't CONDSTORE (which is in IETF Last Call) handle this?

e.g.
              C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345)
              S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen))
              S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted))
              S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk $MDNSent))
              S: s100 OK FETCH completed

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Tue, 7 Oct 2003 10:52:59 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Steve Hole <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Organization: Networks & Distributed Computing
Sender: [email-masked]

Hi Steve -

I'm afraid that you misunderstood the issue.  The problem is not broken
server interoperability with clients that send initial responses to SMTP
and POP3 servers; rather, it is broken server interoperability with
clients that do NOT send the initial responses.

There are multiple SMTP and POP3 servers, some running at large ISPs,
which do NOT respond correctly when a client does not provide an initial
response to the PLAIN authenticator.  The most common offenses are
	334 ok, go on
from an SMTP server and
	+ ok, go on
from a POP3 server.

Another common offense is to respond with something like:
	334 VXNlciBOYW1lAA==
(that is, treating AUTH PLAIN with no initial response as if it was AUTH
LOGIN).  Yet another variation does this, but has an extra CRLF.

These problems occur both with open source and vendor servers.

Once again, we hear the old tired story of "our server works with Netscape
[or Outlook], so your client must be broken."

As for "why is this important" for IMAP; I agree with you in thinking that
AUTHENTICATE command line initial response is not all that important for
IMAP, since IMAP sessions generally are much longer-lived than POP3 or
SMTP sessions.

It is for this reason that I think that the proponents of an initial
response on the command line should back off until the specifications are
clarified such that these broken SMTP and POP3 servers stop happening.

*AFTER* the specifications are fixed, I promise in return that I will not
only stop opposing initial response on the AUTHENTICATE command line, but
will also promptly implement support for it in UW imapd.

-- Mark --

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

From: Steve Hole <[email-masked]>
Date: Tue, 7 Oct 2003 11:25:49 -0600
To: Mark Crispin <[email-masked]>
Subject: Re: SASL Initial Response?
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Mon, 6 Oct 2003 15:55:30 -0700 (Pacific Daylight Time) Mark Crispin 
<[email-masked]> wrote:

> > > The second most common offense is "334 ok, go on" or "+ ok, go on".
> > > Somtimes you also find extra CRLFs in the responses.
> > This might be an ambiguous/incomplete specification for SMTP AUTH.  I'll
> > take a look.
> 
> It's not ambiguous, but you have to read three separate documents (RFCs
> 2222, 2554, and 2595) to work out how to handle an AUTH PLAIN command in
> SMTP.  For POP3, you just need to read 2222 and 2595.
> 
> There is no single document, and *NO* examples, that explains this.  RFC
> 2554 is a bit better in talking about empty challenges than 2595 (see
> first paragraph of page 3, RFC 2554) but without the context of RFC 2222
> it makes no sense.

Yes, you do have to look at more than one document, and I think that this 
did cause some problems in the beginning.

I have to admit to being a bit surprised though Mark.   We have been 
sending out initial responses to SMTP and POP3 servers for a number of 
years without too much in the way of interoperability problems.  There 
were some in the beginning, but most of those sorted out during the first 
IMC interop testing.  Many implementations use the Cyrus SASL library 
which provides good examples for usage and clearly supports initial 
response for those mechanisms that support it.

Perhaps the larger surprise is why people suddenly feel this important.  
Cutting a round trip is nice if you're connecting/reconnecting a lot, but 
I'm not sure why you would want to do that.   In general, the cost of 
select/examine is pretty high and part of the channel setup.  It more or 
less mandates efficient use of connection pooling and maintenance. Over
highly latent connections, anything that reduces roundtrips is useful 
though.   

Personally I'd be thinking about synchronization optimizations 
first.   Let's see ... which set of message had flags that have changed 
since this time??

Cheers.
---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Mon, 6 Oct 2003 16:12:58 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: "RL 'Bob' Morgan" <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 6 Oct 2003, Rob Siemborski wrote:
> I agree.  I also suspect an example or two could help the appropriate
> sections of 2222bis.  But further discussion of this should probably move
> to the ietf-sasl list.

I'm not on the ietf-sasl list, so would appreciate this being passed on.
I guess that I should be at the SASL session in Minneapolis (assuming I go
there which seems likely).

Examples are always helpful.  Section 6.1 of 2222bis should give examples
of AUTH PLAIN in SMTP both with and without initial client data.

Similar examples should appear in the specification for the PLAIN
mechanism (which currently is hidden in the IMAP/POP3/ACAP TLS spec!)
*and* in the specifications for POP3 SASL and SMTP SASL.

> Obviously.  But currently it seems that the primary reason that we don't
> have an initial SASL response in IMAP is concerns over clarity of the
> SASL specification.

Actually, the primary reason was compatibility with the past; IMAP SASL is
older than SASL.  I'm willing to go along with it as a server-optional
extension *IF* the problems with the current client-optional
server-mandatory initial client data POP3/SMTP SASL are fixed.

Since implementation of initial client data will be server-optional in
IMAP, it will be more complex than in POP3/SMTP.  This is because it's
mandatory to implement in POP3/SMTP servers.

> If fixing *that* specification still isn't good enough, I'm totally
> willing to supply text in the draft for the IMAP extention to the effect
> of "pay careful attention to the fact that initial responses are
> *optional*," even to the point of making it a Security Consideration.

We will need that text, and much more.

> And indeed, any IMAP server that didn't get this right would immediately
> have a large number of old-style clients fail to work against it anyway,
> since it is an extention and not part of the base protocol.

It's not just IMAP servers we have to worry about.  It's also IMAP
clients.

We already have clients which fail to interoperate with a server that does
not have a particular extension and/or declare such servers to be
"broken."  The offenders know who they are.

We have to concern ourselves about the possibility of clients that think
that initial data is mandatory to implement in the server (since it is
mandatory in POP3 and SMTP).

Thus, the situation is *worse* with IMAP than with POP3 or SMTP.

-- Mark --

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

Date: Mon, 6 Oct 2003 15:55:30 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: Rob Siemborski <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 6 Oct 2003, Ken Murchison wrote:
> Was there a broken Sendmail patch?  For all mechs, or just one in
> particular?

I don't know.  I know that sendmail at UW works correctly for GSSAPI and
PLAIN.

> > The most common offense is to implement PLAIN and LOGIN as the same thing,
> > thus giving LOGIN challenges to PLAIN with no initial response.
> That's inexcusable, since they are clearly NOT the same thing, and PLAIN
> has always had a standardized SPEC.  Obviously we can't make people read
> the specs correctly, all we can do is make them clear and unambiguous.

Agreed completely.  However, multiple commercial implementations have done
this blunder.

> > The second most common offense is "334 ok, go on" or "+ ok, go on".
> > Somtimes you also find extra CRLFs in the responses.
> This might be an ambiguous/incomplete specification for SMTP AUTH.  I'll
> take a look.

It's not ambiguous, but you have to read three separate documents (RFCs
2222, 2554, and 2595) to work out how to handle an AUTH PLAIN command in
SMTP.  For POP3, you just need to read 2222 and 2595.

There is no single document, and *NO* examples, that explains this.  RFC
2554 is a bit better in talking about empty challenges than 2595 (see
first paragraph of page 3, RFC 2554) but without the context of RFC 2222
it makes no sense.

> > Over and over again, I get told "just make Pine send the initial
> > challenge"; in other words, that the initial challenge is mandatory.  But
> > the SASL specification does not say that; and the idea of inflicting the
> > non-interoperable brokenness of POP/SMTP on IMAP repels me.
> So, you would like to see section 6.1 of RFC 2222bis use a MUST instead
> of SHOULD?  For some mechs (e.g. DIGEST-MD5) this could become
> problematic because the initial response truely is optional.

Actually, I would like the SHOULD to become a MAY, and it be emphasized
that servers MUST implement the correct empty challenge behavior.

However, a MUST is preferable to the status quo, which is a de jure SHOULD
but (at least according to certain individuals) a de facto MUST.

> I will do this.  Just to be clear, we are only talking about
> client-first mechanisms in which the client chooses to not send an
> initial response, correct?

Correct.  SMTP is the worst case, since you have to read three RFCs to
work out how to implement PLAIN in SMTP.

Note that there are no examples.

-- Mark --

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

Date: Mon, 06 Oct 2003 14:28:46 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Mark Crispin <[email-masked]>
CC: Rob Siemborski <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

Mark Crispin wrote:

> On Mon, 6 Oct 2003, Ken Murchison wrote:
> 
>>Can you list the broken implementations?  Are there any current versions
>>of servers which are broken, or just old/deprecated/unsupported code?
> 
> 
> It's easier to list the non-broken implementations: UW, Cyrus, and one of
> the SASL patches to sendmail.

Was there a broken Sendmail patch?  For all mechs, or just one in 
particular?

> The most common offense is to implement PLAIN and LOGIN as the same thing,
> thus giving LOGIN challenges to PLAIN with no initial response.

That's inexcusable, since they are clearly NOT the same thing, and PLAIN 
has always had a standardized SPEC.  Obviously we can't make people read 
the specs correctly, all we can do is make them clear and unambiguous.

> The second most common offense is "334 ok, go on" or "+ ok, go on".
> Somtimes you also find extra CRLFs in the responses.

This might be an ambiguous/incomplete specification for SMTP AUTH.  I'll 
take a look.

> Over and over again, I get told "just make Pine send the initial
> challenge"; in other words, that the initial challenge is mandatory.  But
> the SASL specification does not say that; and the idea of inflicting the
> non-interoperable brokenness of POP/SMTP on IMAP repels me.

So, you would like to see section 6.1 of RFC 2222bis use a MUST instead 
of SHOULD?  For some mechs (e.g. DIGEST-MD5) this could become 
problematic because the initial response truely is optional.

> The text is NOT clear as to how a non-specified client response is to be
> handled.  You have to go through multiple documents to work it out.
> 
> The best way to understand the problem is to go through the exercise
> yourself.  Pretend that you don't know how SASL works.  The client gives
> an "AUTH PLAIN" command to an SMTP server without the initial response.
> Now, go through the steps of going through the RFCs to interpret that
> command, and determine the proper response.

I will do this.  Just to be clear, we are only talking about 
client-first mechanisms in which the client chooses to not send an 
initial response, correct?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 6 Oct 2003 14:00:10 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: "RL 'Bob' Morgan" <[email-masked]>
cc: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Mon, 6 Oct 2003, RL 'Bob' Morgan wrote:

> On Mon, 6 Oct 2003, Mark Crispin wrote:
>
> > > If there is a problem, it should
> > > probably be raised in the SASL WG.  (Of course, that document's WG last
> > > call allegedly finished on Sep 30, but it looks like comments are still
> > > being made).
> >
> > Well, there's a problem right there; it's probably too late to raise it
> > in the SASL WG.  I agree that that is where it should have been raised.
>
> WG Last Call is only the first of many hurdles, including IETF-wide Last
> Call.  There is still lots of time to comment on
> draft-ietf-sasl-rfc2222bis-02.txt.

I agree.  I also suspect an example or two could help the appropriate
sections of 2222bis.  But further discussion of this should probably move
to the ietf-sasl list.

> > So it becomes an IMAP question again.
>
> Any change to the IMAP protocol is of course an IMAP(ext) WG question,
> even if the SASL text is perfect.

Obviously.  But currently it seems that the primary reason that we don't
have an initial SASL response in IMAP is concerns over clarity of the
SASL specification.

If fixing *that* specification still isn't good enough, I'm totally
willing to supply text in the draft for the IMAP extention to the effect
of "pay careful attention to the fact that initial responses are
*optional*," even to the point of making it a Security Consideration.

And indeed, any IMAP server that didn't get this right would immediately
have a large number of old-style clients fail to work against it anyway,
since it is an extention and not part of the base protocol.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Mon, 6 Oct 2003 10:31:07 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: Rob Siemborski <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Mon, 6 Oct 2003, Ken Murchison wrote:
> Can you list the broken implementations?  Are there any current versions
> of servers which are broken, or just old/deprecated/unsupported code?

It's easier to list the non-broken implementations: UW, Cyrus, and one of
the SASL patches to sendmail.

I'm encountering broken server implementations all the time, and big
providers run them.  I've seen little progress in getting it fixed.  It's
pretty high on my FAQ list, second only to the PC Pine crashes caused by
Microsoft's persistant failure to fix the bug in SSPI that they've known
about for years (they fixed it in Win2K but not WinXP).

The most common offense is to implement PLAIN and LOGIN as the same thing,
thus giving LOGIN challenges to PLAIN with no initial response.

The second most common offense is "334 ok, go on" or "+ ok, go on".
Somtimes you also find extra CRLFs in the responses.

Over and over again, I get told "just make Pine send the initial
challenge"; in other words, that the initial challenge is mandatory.  But
the SASL specification does not say that; and the idea of inflicting the
non-interoperable brokenness of POP/SMTP on IMAP repels me.

IMAP currently forces a correct implementation of null server challenges.
Before this protection is removed, something must be done to fix the
broken situation in those protocols which lack this protection.

> Based on RFC 2222(bis), RFC 1734/2449 and RFC 2554, do you have any
> insight?  I think the text is pretty clear, but maybe others don't.

The text is NOT clear as to how a non-specified client response is to be
handled.  You have to go through multiple documents to work it out.

The best way to understand the problem is to go through the exercise
yourself.  Pretend that you don't know how SASL works.  The client gives
an "AUTH PLAIN" command to an SMTP server without the initial response.
Now, go through the steps of going through the RFCs to interpret that
command, and determine the proper response.

I've done this tedious exercise multiple times with server implementors
who simply refuse to believe that I know what I am talking about.  It
would be helpful if you (Ken and Rob) went through it yourselves.

I agree that the specification is complete and precise.  The problem is
that too many implementors fail to understand it.

Incidentally, it would be an acceptable answer to me to declare "on
January 1, 2004, the initial challenge becomes mandatory in all
protocols."  I would not *like* it, but it would be better than the status
quo with POP3/SMTP.

-- Mark --

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

Date: Mon, 06 Oct 2003 18:28:52 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Rob Siemborski <[email-masked]>, Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

Cyrus mentioned this extension during a private talk at least 6 month ago.

Unless there is a compeling reason not to add this, I am in full support 
for this extension.

Mark Crispin wrote:

>On Mon, 6 Oct 2003, Rob Siemborski wrote:
>  
>
>>I agree -- this sounds like an issue with initial responses in general,
>>not with a specific use of them in IMAP.
>>    
>>
>I agree.  However, the question at hand is whether to reverse an earlier
>decision NOT to add this facility to IMAP.
>
Mark, coould you remind me when this has taken place?

>  Thus, it is an IMAP question.
>  
>
>>If there is a problem, it should
>>probably be raised in the SASL WG.  (Of course, that document's WG last
>>call allegedly finished on Sep 30, but it looks like comments are still
>>being made).
>>    
>>
>
>Well, there's a problem right there; it's probably too late to raise it in
>the SASL WG.  I agree that that is where it should have been raised.
>
As the editor of RFC2222bis, I can say that it is not too late.

>So it becomes an IMAP question again.
>
Alexey

Date: Mon, 6 Oct 2003 10:12:32 -0700 (PDT)
From: "RL 'Bob' Morgan" <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Mon, 6 Oct 2003, Mark Crispin wrote:

> > If there is a problem, it should
> > probably be raised in the SASL WG.  (Of course, that document's WG last
> > call allegedly finished on Sep 30, but it looks like comments are still
> > being made).
>
> Well, there's a problem right there; it's probably too late to raise it
> in the SASL WG.  I agree that that is where it should have been raised.

WG Last Call is only the first of many hurdles, including IETF-wide Last
Call.  There is still lots of time to comment on
draft-ietf-sasl-rfc2222bis-02.txt.

> So it becomes an IMAP question again.

Any change to the IMAP protocol is of course an IMAP(ext) WG question,
even if the SASL text is perfect.

 - RL "Bob"

Date: Mon, 6 Oct 2003 10:03:25 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Mon, 6 Oct 2003, Rob Siemborski wrote:
> I agree -- this sounds like an issue with initial responses in general,
> not with a specific use of them in IMAP.

I agree.  However, the question at hand is whether to reverse an earlier
decision NOT to add this facility to IMAP.  Thus, it is an IMAP question.

> If there is a problem, it should
> probably be raised in the SASL WG.  (Of course, that document's WG last
> call allegedly finished on Sep 30, but it looks like comments are still
> being made).

Well, there's a problem right there; it's probably too late to raise it in
the SASL WG.  I agree that that is where it should have been raised.

So it becomes an IMAP question again.

-- Mark --

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

Date: Mon, 6 Oct 2003 12:30:17 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Mon, 6 Oct 2003, Ken Murchison wrote:

> > 4) Would a change of wording in the specification help?
>
> Based on RFC 2222(bis), RFC 1734/2449 and RFC 2554, do you have any
> insight?  I think the text is pretty clear, but maybe others don't.

I agree -- this sounds like an issue with initial responses in general,
not with a specific use of them in IMAP.  If there is a problem, it should
probably be raised in the SASL WG.  (Of course, that document's WG last
call allegedly finished on Sep 30, but it looks like comments are still
being made).

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Mon, 06 Oct 2003 12:30:26 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Mark Crispin <[email-masked]>
CC: Rob Siemborski <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

Mark Crispin wrote:

> On Mon, 6 Oct 2003, Ken Murchison wrote:
> 
>>This might be true, but it doesn't seem like a compelling technical
>>argument against allowing this in IMAP.  Existing or future poor
>>implementations should not stand in the way of progress, unless the
>>specification is so complex that it is part of the implementation problem.
> 
> 
> Well, I think that the example of POP and SMTP suggests that it may well
> be too complex.  Before proceeding, I think that the POP/SMTP experience
> needs to be carefully reviewed.
> 
> 
>>Are you saying that you would oppose such an extension, or just saying
>>that based on past experience it might cause some heartburn?
> 
> 
> It will cause some heartburn.  The proof is out there.

Can you list the broken implementations?  Are there any current versions 
of servers which are broken, or just old/deprecated/unsupported code?

> 
> As for support or opposition, I haven't taken a position; but if it is
> proposed without any attempt to study or learn from the POP/SMTP
> experience I probably will oppose it.
> 
> Suggested topics for study:
> 
> 1) Why is it difficult to understand that the initial response is
> optional?
> 
> 2) Why do server implementors have trouble in generating appropriate
> initial challenges ("ok, go ahead" in plaintext is not appropriate)?
> 
> 3) Why are incorrect implementations so widespread in the POP/SMTP world?
> 
> 4) Would a change of wording in the specification help?

Based on RFC 2222(bis), RFC 1734/2449 and RFC 2554, do you have any 
insight?  I think the text is pretty clear, but maybe others don't.

> If these questions are answered in a reasonable way, I will either support
> or be neutral on the proposal.

Glad to hear it.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 6 Oct 2003 09:18:07 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: Rob Siemborski <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Mon, 6 Oct 2003, Ken Murchison wrote:
> This might be true, but it doesn't seem like a compelling technical
> argument against allowing this in IMAP.  Existing or future poor
> implementations should not stand in the way of progress, unless the
> specification is so complex that it is part of the implementation problem.

Well, I think that the example of POP and SMTP suggests that it may well
be too complex.  Before proceeding, I think that the POP/SMTP experience
needs to be carefully reviewed.

> Are you saying that you would oppose such an extension, or just saying
> that based on past experience it might cause some heartburn?

It will cause some heartburn.  The proof is out there.

As for support or opposition, I haven't taken a position; but if it is
proposed without any attempt to study or learn from the POP/SMTP
experience I probably will oppose it.

Suggested topics for study:

1) Why is it difficult to understand that the initial response is
optional?

2) Why do server implementors have trouble in generating appropriate
initial challenges ("ok, go ahead" in plaintext is not appropriate)?

3) Why are incorrect implementations so widespread in the POP/SMTP world?

4) Would a change of wording in the specification help?

If these questions are answered in a reasonable way, I will either support
or be neutral on the proposal.

-- Mark --

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

Date: Mon, 06 Oct 2003 11:55:57 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Mark Crispin <[email-masked]>
CC: Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: SASL Initial Response?
Sender: [email-masked]

Mark Crispin wrote:

> On Mon, 6 Oct 2003, Rob Siemborski wrote:
> 
>>Is there any reason no one has ever proposed an IMAP extention to support
>>SASL initial client responses?
> 
> 
> Experience with POP and SMTP suggests that if the protcol supports initial
> client responses, server implementors will never correctly implement the
> case when the client does not supply one.
> 
> This has been an ongoing problem which, to date, IMAP has had blissful
> immunity.

This might be true, but it doesn't seem like a compelling technical 
argument against allowing this in IMAP.  Existing or future poor 
implementations should not stand in the way of progress, unless the 
specification is so complex that it is part of the implementation problem.

Are you saying that you would oppose such an extension, or just saying 
that based on past experience it might cause some heartburn?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 6 Oct 2003 08:27:46 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: [email-masked]
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Mon, 6 Oct 2003, Rob Siemborski wrote:
> Is there any reason no one has ever proposed an IMAP extention to support
> SASL initial client responses?

Experience with POP and SMTP suggests that if the protcol supports initial
client responses, server implementors will never correctly implement the
case when the client does not supply one.

This has been an ongoing problem which, to date, IMAP has had blissful
immunity.

-- Mark --

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

Date: Mon, 6 Oct 2003 10:50:37 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: SASL Initial Response?
Sender: [email-masked]

Is there any reason no one has ever proposed an IMAP extention to support
SASL initial client responses?

My basic idea would be that the server would advertise another (sigh)
capability, and would then accept a second argument to the AUTHENTICATE
command which would contain the initial SASL blob (if applicable).

Can anyone offhand see why this would be an outright bad idea?
Certainly, I can understand not being able to do this for
server-last-sends currently (since that seems to require a client-side
capability mechanism of some sort), but it seems like initial client
responses would be both easy to add, and beneficial (in terms of the
number of round trips required at startup).

If there aren't significant initial objections, I'm willing to put
together an individual ID for this.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

From: Arnt Gulbrandsen <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: two ACL2 points
Cc: IMAP extensions Mailing List <[email-masked]>
Date: Sat, 4 Oct 2003 21:57:58 +0200
Sender: [email-masked]

Mark Crispin writes:
> On Sat, 4 Oct 2003, Arnt Gulbrandsen wrote:
>> What I'd like is a requirement that the server MAY send unsolicited 
>> LIST (ACL) responses for any mailbox for which the client has issued 
>> an ACL command, and that the client MUST handle such responses.
>
> That is already a requirement of IMAP, and always has been.

Yes, I've seen the half-sentence in 2.2.2. But I don't see much about 
"client MUST handle", except specific requirements such as that in 
7.2.6.

A nudge and a wink doesn't seem out of place in the ACL2 document. 
Perhaps in the form of a stated "client MUST handle", or perhaps in the 
form of an example that draws attention to rules that are in the base 
RFC.

(I ran into this while fooling with an ACL dialog and thinking, what if 
this is run by two IMAP clients at the same time, e.g. two people 
responding to the same e-mailed request?)

--Arnt

Date: Sat, 4 Oct 2003 22:06:36 +0300
Subject: Re: two ACL2 points
Cc: IMAP extensions Mailing List <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
From: Timo Sirainen <[email-masked]>
Sender: [email-masked]

On Saturday, Oct 4, 2003, at 20:41 Europe/Helsinki, Arnt Gulbrandsen 
wrote:

> 1. The SELECT command looks at ACL, says the draft, but as soon as a 
> client has selected a mailbox that's it. The security considerations 
> should probably note that if an ACL is restricted, any client that 
> already has selected the mailbox keeps its access indefinitely.
>
> Perhaps the server should be explicitly allowed to kick the client out 
> in this case.

This is mail store dependent. If you drop access to maildir in 
filesystem level, you can't open mails anymore.

Date: Sat, 4 Oct 2003 11:42:20 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: two ACL2 points
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Sat, 4 Oct 2003, Arnt Gulbrandsen wrote:
> 1. The SELECT command looks at ACL, says the draft, but as soon as a
> client has selected a mailbox that's it. The security considerations
> should probably note that if an ACL is restricted, any client that
> already has selected the mailbox keeps its access indefinitely.

I agree.

> 2. A client that has run LIST ACL isn't told about later changes.

Similarly, a client that does a LIST isn't told when mailboxes are created
or deleted.

> What I'd like is a requirement that the server MAY send unsolicited LIST
> (ACL) responses for any mailbox for which the client has issued an ACL
> command, and that the client MUST handle such responses.

That is already a requirement of IMAP, and always has been.  For example,
a server can send an untagged SEARCH even if the client never issued a
SEARCH command.  However, there is no reason to believe that any client
will do anything with such responses.

The unsolicited data model only requires that clients keep track of
state changes in the selected mailbox, and is silent about other data.  It
neither mandates nor forbids it.

-- Mark --

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

From: Arnt Gulbrandsen <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: two ACL2 points
Date: Sat, 4 Oct 2003 19:41:21 +0200
Sender: [email-masked]

[ As I write this mail I have a deja vu feeling. Have I already noted 
these things? I don't see anything in my mail archive. ]

Both points relate to changes in ACLs done by one client that affect another.

1. The SELECT command looks at ACL, says the draft, but as soon as a 
client has selected a mailbox that's it. The security considerations 
should probably note that if an ACL is restricted, any client that 
already has selected the mailbox keeps its access indefinitely.

Perhaps the server should be explicitly allowed to kick the client out 
in this case.

2. A client that has run LIST ACL isn't told about later changes.

IMO, the server has the right to send any and all unsolicited responses 
during IDLE mode, and also as side effects for most commands. But I 
suspect many clients don't handle that very well...

What I'd like is a requirement that the server MAY send unsolicited LIST 
(ACL) responses for any mailbox for which the client has issued an ACL 
command, and that the client MUST handle such responses.

--Arnt

To: IETF-Announce :;
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: Last Call: 'IMAP Extension for Conditional STORE operation' to  Proposed Standard 
Reply-to: [email-masked]
Date: Fri, 03 Oct 2003 10:16:55 -0400
Sender: [email-masked]

The IESG has received a request from the Internet Message Access Protocol 
Extension WG to consider the following document:

- 'IMAP Extension for Conditional STORE operation '
   <draft-ietf-imapext-condstore-04.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 any comments to the
[email-masked] or [email-masked] mailing lists by 2003-10-17.
                                                                                       
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-04.txt

Date: Thu, 02 Oct 2003 09:55:35 -0700 (PDT)
From: [email-masked]
Subject: Re: AD review comments on draft-ietf-imapext-condstore
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked], Pete Resnick <[email-masked]>, [email-masked], Ned Freed <[email-masked]>, [email-masked]
Sender: [email-masked]

> > The production:
> >
> >    fetch               = "FETCH" SP sequence-set SP ("ALL" / "FULL" /
> >                          "FAST" / fetch-att /
> >                          "(" fetch-att *(SP fetch-att) ")")
> > [SPfetch-modifiers]
> >
> > should read:
> >
> >    fetch               = "FETCH" SP sequence-set SP ("ALL" / "FULL" /
> >                          "FAST" / fetch-att /
> >                          "(" fetch-att *(SP fetch-att) ")") [SP
> > fetch-modifiers]

> Actually, this production is correct (there is a space between SP and
> fetch-modifiers.

Some sort of wierd cut and paste error on my part then. Sorry about that.

> I've updated the document.

Yes, thanks, and now that the revision has hit the repository I'll ask for
a last call.

				Ned 

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-condstore-04.txt
Date: Thu, 02 Oct 2003 10:50:27 -0400
Sender: [email-masked]

--NextPart

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		: IMAP Extension for Conditional STORE operation
	Author(s)	: A. Melnikov, S. Hole
	Filename	: draft-ietf-imapext-condstore-04.txt
	Pages		: 16
	Date		: 2003-10-2
	
Often, multiple IMAP clients need to coordinate changes to a common
IMAP mailbox.  Examples include different clients for the same user,
and multiple users accessing shared mailboxes. These clients
need a mechanism to synchronize state changes for messages within the
mailbox. They must be able to guarantee that only one client can change
message state (e.g., message flags or annotations) at any time.  An
example of such an application is use of an IMAP mailbox as a message
queue with multiple dequeueing clients.
The Conditional Store facility provides a protected update mechanism for
message state information that can detect and resolve conflicts between
multiple writing mail clients.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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
	"get draft-ietf-imapext-condstore-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-condstore-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-condstore-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-condstore-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Thu, 02 Oct 2003 10:01:45 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: Pete Resnick <[email-masked]>, [email-masked], Ned Freed <[email-masked]>, [email-masked]
Subject: Re: AD review comments on draft-ietf-imapext-condstore
Sender: [email-masked]

[email-masked] wrote:

>
> Pete asked me to last call this document. However, my AD review turned up
> a number of errors, mostly editorial in nature. There are enough of these
> that I think they need to be corrected in a revised I-D before 
> proceeding.
>
> - - - - - -
>
> Section 2, fifth paragraph: A reference to [ANNOTATE] should be added.
>
> Section 2, seventh paragraph: extention -> extension
>
> Section 4, second paragraph: "[IMAP4]" -> "[IMAP4] or [ANNOTATE]"
>
> There are lots of ABNF errors. The production:
>
> entry-name          = entry-name-flag / entry-annotate-name
>    should be:
>
> entry-name          = entry-flag-name / entry-annotate-name
>    (There is no entry-name-flag production.) The production:
>
>    entry-flag-name     = '"' "/flags/" attr-flag '"'
>
> isn't syntactically valid and needs to be changed to:
>
>    entry-flag-name     = DQUOTE "/flags/" attr-flag DQUOTE
>
> (The DQUOTE production is used in RFC 3501, whose ABNF is available to
> this document.) The production:
>
>    entry-type-resp     = "priv" | "shared"
>
> should be:
>
>    entry-type-resp     = "priv" / "shared"
>
> The production:
>
>    entry-type-req      = entry-type-resp | "all"
>
> should be:
>
>    entry-type-req      = entry-type-resp / "all"
>
> The production:
>
>    store               = "STORE" SP set store-modifiers SP 
> store-att-flags
>
> should read:
>
>    store               = "STORE" SP sequence-set store-modifiers
>                          SP store-att-flags 

> The production:
>
>    fetch               = "FETCH" SP sequence-set SP ("ALL" / "FULL" /
>                          "FAST" / fetch-att /
>                          "(" fetch-att *(SP fetch-att) ")") 
> [SPfetch-modifiers]
>
> should read:
>
>    fetch               = "FETCH" SP sequence-set SP ("ALL" / "FULL" /
>                          "FAST" / fetch-att /
>                          "(" fetch-att *(SP fetch-att) ")") [SP 
> fetch-modifiers] 

Actually, this production is correct (there is a space between SP and 
fetch-modifiers.

> The production:
>
>    mod-sequence-valzer = "0" | mod-sequence-value
>
> should be:
>
>    mod-sequence-valzer = "0" / mod-sequence-value
>
> The production name "search_sort_mod_seq" needs to be changed to
> "search-sort-mod-seq" everywhere. (Underscors aren't allowed in 
> production
> names.)
>
> Security considerations:
>
> The statement "It is believed that the Conditional STORE extension
> doesn't raise any new security concerns that are not already discussed
> in [IMAP4]" is correct as far as it goes. However, this extension
> provides a means by which an IMAP store can be used for potentially
> criticial applications involving multiple clients that could not be
> supported before. This may have the effect of making correct IMAP
> server behavior more important. Accordingly, I suggest amending the
> section to read:
>
> It is believed that the Conditional STORE extension doesn't raise
> any new security concerns that are not already discussed in [IMAP4].
> However, the availability of this extension may make it possible
> for IMAP4 to be used in critical applications it could not be used
> for previously, making correct IMAP server implementation and
> operation in even more important.
>
> Section 7: The wording here is awkward. I suggest changing it to read:
> "This document defines  the CONDSTORE and SORT=MODSEQ IMAP capabilities.
> IANA should add them to the registry accordingly."
>
> Acknowledgements, third paragraph:  "Authors" -> "The authors"
>
> That's it!
>
>                 Ned

Thank you Ned.
I've updated the document.

Alexey

Date: Wed, 01 Oct 2003 23:15:36 -0700 (PDT)
From: [email-masked]
Subject: AD review comments on draft-ietf-imapext-condstore
To: Pete Resnick <[email-masked]>, [email-masked]
Cc: Ned Freed <[email-masked]>, [email-masked]
Sender: [email-masked]

Pete asked me to last call this document. However, my AD review turned up
a number of errors, mostly editorial in nature. There are enough of these
that I think they need to be corrected in a revised I-D before proceeding.

- - - - - -

Section 2, fifth paragraph: A reference to [ANNOTATE] should be added.

Section 2, seventh paragraph: extention -> extension

Section 4, second paragraph: "[IMAP4]" -> "[IMAP4] or [ANNOTATE]"

There are lots of ABNF errors. The production:

 entry-name          = entry-name-flag / entry-annotate-name
    
should be:

 entry-name          = entry-flag-name / entry-annotate-name
    
(There is no entry-name-flag production.) The production:

    entry-flag-name     = '"' "/flags/" attr-flag '"'

isn't syntactically valid and needs to be changed to:

    entry-flag-name     = DQUOTE "/flags/" attr-flag DQUOTE

(The DQUOTE production is used in RFC 3501, whose ABNF is available to
this document.) The production:

    entry-type-resp     = "priv" | "shared"

should be:

    entry-type-resp     = "priv" / "shared"

The production:

    entry-type-req      = entry-type-resp | "all"

should be:

    entry-type-req      = entry-type-resp / "all"

The production:

    store               = "STORE" SP set store-modifiers SP store-att-flags

should read:

    store               = "STORE" SP sequence-set store-modifiers
                          SP store-att-flags

The production:

    fetch               = "FETCH" SP sequence-set SP ("ALL" / "FULL" /
                          "FAST" / fetch-att /
                          "(" fetch-att *(SP fetch-att) ")") [SPfetch-modifiers]

should read:

    fetch               = "FETCH" SP sequence-set SP ("ALL" / "FULL" /
                          "FAST" / fetch-att /
                          "(" fetch-att *(SP fetch-att) ")") [SP fetch-modifiers]

The production:

    mod-sequence-valzer = "0" | mod-sequence-value

should be:

    mod-sequence-valzer = "0" / mod-sequence-value

The production name "search_sort_mod_seq" needs to be changed to
"search-sort-mod-seq" everywhere. (Underscors aren't allowed in production
names.)

Security considerations:

The statement "It is believed that the Conditional STORE extension
doesn't raise any new security concerns that are not already discussed
in [IMAP4]" is correct as far as it goes. However, this extension
provides a means by which an IMAP store can be used for potentially
criticial applications involving multiple clients that could not be
supported before. This may have the effect of making correct IMAP
server behavior more important. Accordingly, I suggest amending the
section to read:

 It is believed that the Conditional STORE extension doesn't raise
 any new security concerns that are not already discussed in [IMAP4].
 However, the availability of this extension may make it possible
 for IMAP4 to be used in critical applications it could not be used
 for previously, making correct IMAP server implementation and
 operation in even more important.

Section 7: The wording here is awkward. I suggest changing it to read:
"This document defines  the CONDSTORE and SORT=MODSEQ IMAP capabilities.
IANA should add them to the registry accordingly."

Acknowledgements, third paragraph:  "Authors" -> "The authors"

That's it!

				Ned

Date: Fri, 31 Oct 2003 13:13:41 -0800 (PST)
From: [email-masked]
Subject: Re: Jabbering - [email-masked]
To: Lyndon Nerenberg <[email-masked]>
Cc: Pete Resnick <[email-masked]>, [email-masked]
Sender: [email-masked]

> > Did you have tool
> > problems, or was the jabber scribe simply not saying anything
> > comprehensible enough for you?

> The problem with Jabber is that the scribe cannot keep up with the
> discussion in real time.

Well, it pretty much depends on how fast a typist you are. I've done this a
couple of times, including one very busy ASRG meeting, and I think I've managed
to keep up and cover the relevant points, but then again I'm a very fast
typist. And if you do this you most certainly aren't going to be able to do
much in the way of contributing to the discussion. It is also hard work by any
measure, and not something I'd be willing to do for more than a couple of
sessions at any given IETF.

> And neither can the remote correspondents.

Speaking as someone who has tried to participate remotely on a couple of
occasions, the problem is usually not having enough information to keep up with
rather than having too much.

> And it
> is impossible to transcribe the nuances of the conversation on the fly, and
> without that context it's very easy to misinterpret what's really being
> said. (I used to work for a court reporting company. There is a reason
> those people get paid as much as they do.)

Indeed. Transcription is in all its various forms is clearly an art, and it is
silly to believe that any random person will be able to do it well. (Not even
when we're talking about random IETF attendees.) Clearly this is no real
substitute for actually being there.

> > > The mailing lists are not broken -- let's not try to fix them.

> > And this has what to do with the existence of the jabber room?

> Everything. We're talking about communication within the WG. I am making
> the claim that the mailing list is a useful and appropriate tool for the WG
> members to communicate -- accurately -- their thoughts. I am also making
> the claim that Jabber does not allow for accurate communication, and is the
> wrong tool to solve this problem (if indeed there really is a problem here
> that needs solving).

Hmm. Well, I think I see your point, but on the other hand, the ability to talk
to the chair right away when issues come up is an intriguing one that may have
some real advantages. I think it is worth trying at least. If it helps,
great, and if it sucks we'll at least have learned something.

				Ned

Date: Fri, 31 Oct 2003 13:47:06 -0700
From: Lyndon Nerenberg <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: [email-masked]
Subject: Re: Jabbering - [email-masked]
Sender: [email-masked]

> Did you have tool
> problems, or was the jabber scribe simply not saying anything
> comprehensible enough for you?

The problem with Jabber is that the scribe cannot keep up with the 
discussion in real time. And neither can the remote correspondents. And it 
is impossible to transcribe the nuances of the conversation on the fly, and 
without that context it's very easy to misinterpret what's really being 
said. (I used to work for a court reporting company. There is a reason 
those people get paid as much as they do.)

>> The mailing lists are not broken -- let's not try to fix them.
>
> And this has what to do with the existence of the jabber room?

Everything. We're talking about communication within the WG. I am making 
the claim that the mailing list is a useful and appropriate tool for the WG 
members to communicate -- accurately -- their thoughts. I am also making 
the claim that Jabber does not allow for accurate communication, and is the 
wrong tool to solve this problem (if indeed there really is a problem here 
that needs solving).

--lyndon

Date: Fri, 31 Oct 2003 11:33:42 -0600
To: Lyndon Nerenberg <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Jabbering - [email-masked]
Cc: [email-masked]
Sender: [email-masked]

On 10/31/03 at 9:53 AM -0700, Lyndon Nerenberg wrote:

>My experience with jabber over the last few IETFs is that it's 
>nothing more than a pain in the a**.

I've successfully used jabber during the face-to-face, both for 
watching side commentary while in a large session (to ask questions 
for simple things while the session is going on) as well as watching 
what was going on in a session I couldn't be at while in another 
room. Did you have tool problems, or was the jabber scribe simply not 
saying anything comprehensible enough for you?

>The mailing lists are not broken -- let's not try to fix them.

And this has what to do with the existence of the jabber room?

Again, the jabber room is NOT trying to fix anything about the 
mailing list, and it's CERTAINLY NOT trying to replace it for 
official business. It's another channel of communication (just like 
private e-mail between members of a working group) where people can 
work minor things out without wasting the time of the entire working 
group. Is there some problem with that?

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

Date: Fri, 31 Oct 2003 09:53:48 -0700
From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
Subject: Re: Jabbering - [email-masked]
Sender: [email-masked]

> Absolutely, though my feeling is that serious discussions should *not*
> take place in jabber at this point.

My experience with jabber over the last few IETFs is that it's nothing more 
than a pain in the a**. The mailing lists are not broken -- let's not try 
to fix them.

--lyndon

Date: Fri, 31 Oct 2003 09:50:15 -0600
To: Cyrus Daboo <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Jabbering - [email-masked]
Cc: [email-masked]
Sender: [email-masked]

On 10/31/03 at 10:45 AM -0500, Cyrus Daboo wrote:

>If serious discussions are going to take place on the jabber list, 
>is it possible to have some summary of those posted to the email list

Absolutely, though my feeling is that serious discussions should 
*not* take place in jabber at this point. Jabber might be a nice way, 
if someone happens to be around, to ask a quick "Hey, what's the 
status of my draft?" or "I don't understand a piece of this draft. 
Can someone explain what I'm missing, or should I bring this to the 
author as a problem?" kind of question. I expect serious issue 
discussions to always be on the list.

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

Date: Fri, 31 Oct 2003 10:45:24 -0500
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Jabbering - [email-masked]
Sender: [email-masked]

Hi Pete,

- --On Thursday, October 30, 2003 23:21 -0600 Pete Resnick 
<[email-masked]> wrote:

| Just to let folks know: I plan to "hang out" in the IMAPEXT room on the
| new jabber server that Marshall recently announced. Everyone should feel
| free to "hang out" or drop in for group related questions.

Frankly, right now I have enough trouble keeping up with email, let alone 
anything that's more 'real-time' than that. If serious discussions are 
going to take place on the jabber list, is it possible to have some summary 
of those posted to the email list (I'm not talking about a URL to jabber 
archive but a real email message with any jabber discussions from the last 
week, say).

- -- 
Cyrus Daboo

Date: Thu, 30 Oct 2003 23:21:14 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Jabbering - [email-masked]
Sender: [email-masked]

Just to let folks know: I plan to "hang out" in the IMAPEXT room on 
the new jabber server that Marshall recently announced. Everyone 
should feel free to "hang out" or drop in for group related questions.
-- 
Pete Resnick <http://wwww.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Thu, 30 Oct 2003 09:28:58 -0800 (PST)
From: [email-masked]
Subject: IESG review of draft-ietf-imapext-condstore-04.txt
To: IMAP extensions Mailing List <[email-masked]>
Sender: [email-masked]

The IESG reviewed this document today, and Ted Hardie has recorded the
following discuss comments:

----

Section 3.2 says:

Note: A client trying to make an atomic change to the state of a particular
      metadata item (or a set of metadata items) should be prepared
      to deal with the case when the server returns MODIFIED response code
      if the state of the metadata item being watched hasn't changed (but
      the state of some other metadata item has). This is necessary, because
      some servers don't store separate mod-sequences for different metadata
      items. However, a server implementation SHOULD avoid generating
      spurious MODIFIED responses for +FLAGS/-FLAGS STORE operations,
      even when the server stores a single mod-sequence per message.

      Upon the receipt of MODIFIED response code the client SHOULD try to
      figure out if the required metadata items have indeed changed. If they
      haven't the client SHOULD retry the command.

First, this is a classic case of IMAP being so server focused as to make a
client's life hell.  In order to avoid keeping per-metadatum state, the
protocol now forces client round trips to check that what it wants to change
isn't the bit that has already been changed.  While I won't challenge that
design choice based on my own preference, I'm not sure that I believe "SHOULD
try to figure out" is a realistic piece of protocol specification, and seeing
it in a document about conditional storage makes my head hurt.  Cleaning up the
language so it is clear exactly what the client has to do would be useful.

I also think the sentence "a server implementation SHOULD avoid generating
spurious MODIFIED responses for +FLAGS/-FLAGS STORE operations, even when the
server stores a single mod-sequence per message" doesn't make any sense.  What
is the server supposed to do here?  Not send a modified response even though it
knows something changed and doesn't know what, based on some extra-protocol
knowledge?  This doesn't seem like a win for interoperability.  If it doesn't
know what changed (because it is using a single mod-sequence) it's not
spurious, just lame.

I believe we normally have documents that update other RFCs mention that in
the abstract, and since this does, it probably ought to.

----

					Ned

Date: Thu, 30 Oct 2003 07:32:46 +0800
From: James Seng <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Abhijit Menon-Sen <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

> I do not believe that this is true for Chinese.  AFAIK, Chinese primary
> school kids use Latin script with hanyu-pinyin as a stopgap prior to their
> mastery of Han script (which takes many years).

Nope. Hanyu Pinyin was designed to replace the Han ideograph but it 
never did.

> Note that when I say "recognize Latin script", I mean the ability to
> determine that "dog" is a three-letter word that has the letters "d", "o",
> and "g", each of which the individual recognizes and can name.  This does
> not include the ability to recognize that this refers to a domesticated
> canine.

Based on your reasonings, I think we should all reverted back to 
numbers, because that is the only universal recongizable set of symbols 
we have.

We have this argument in IDN before and we certainly dont need this 
again. If you feel we should all stick to Latin, yes, you are entitled 
to your opinion but please do so in other place, and not here. The group 
is suppose to work on Internationalization of Email address 
(identifiers), not debate whether we need it or not.

-James Seng

Date: Thu, 30 Oct 2003 07:26:28 +0800
From: James Seng <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Mark Davis <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Crispin,

You need to get out of US (or Wsshington) more often.

-James Seng

> I am not convinced that it is possible to use a computer on the Internet
> anywhere in the world without at least a basic acquaintance with Latin
> script.
> 
> I do not believe many individuals (other than primary school children) are
> literate in their native language but are completely illiterate in Latin
> script.  This does not mean "being able to read or write the English
> language"; rather, this simply means knowing the Latin script alphabet.
> 
> Put another way, individuals who are completely illiterate in Latin script
> are also likely to be illiterate in their native language script as well.
> 
> No other script on the planet has such international recognition.
> 
> There is undoubtably a *preference* for one's native script; and that
> preference should be respected as much as possible.
> 
> -- Mark --
> 
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
> Si vis pacem, para bellum.
> 
> 
> 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: [idn] FYI: BOF on Internationalized Email Addresses (IEA)
Date: Wed, 29 Oct 2003 15:18:45 -0800
From: "Michel Suignard" <[email-masked]>
To: "James Seng" <[email-masked]>, =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Pete Resnick" <[email-masked]>, "Ted Hardie" <[email-masked]>, "Ned Freed" <[email-masked]>
Sender: [email-masked]

JS>I seen John and Paul proposal but I have not seen Michel. Is there a draft that I can read
JS>up? 

I don't have a proposal. I am listed there as a co-editor of the IRI spec which has a peripheral impact on the IEA (such as extending the URI mailto scheme). Like many I am listening with interest to the points made for or against the two proposals.

Michel Suignard

Date: Wed, 29 Oct 2003 16:18:35 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

On Wed, 29 Oct 2003, Cyrus Daboo wrote:

> | This version includes the change in the capability name as well as the
> | revised base64 text.
>
> Minor point from the protocol police: the examples are all missing the
> tagged OK for the CAPABILITY command.

Oh! How embarrassing.

Thanks, this will be fixed.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----

Date: Wed, 29 Oct 2003 16:17:01 -0500
From: Cyrus Daboo <[email-masked]>
To: Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

Hi Rob,

--On Wednesday, October 29, 2003 16:02 -0500 Rob Siemborski 
<[email-masked]> wrote:

| Since the ID editor apparently ate the update I tried to post to this
| document, I have posted an updated version of it here:
|
| http://www.contrib.andrew.cmu.edu/~rjs3/ietf/draft-siemborski-imap-sasl-i
| nitial-response-01b.txt
|
| This version includes the change in the capability name as well as the
| revised base64 text.

Minor point from the protocol police: the examples are all missing the 
tagged OK for the CAPABILITY command.

-- 
Cyrus Daboo

Date: Wed, 29 Oct 2003 16:02:30 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

On Mon, 13 Oct 2003 [email-masked] wrote:

> 	Title		: IMAP Extension for SASL Initial Client Response
> 	Author(s)	: R. Siemborski
> 	Filename	: draft-siemborski-imap-sasl-initial-response-00.txt
> 	Pages		: 7
> 	Date		: 2003-10-10

Since the ID editor apparently ate the update I tried to post to this
document, I have posted an updated version of it here:

http://www.contrib.andrew.cmu.edu/~rjs3/ietf/draft-siemborski-imap-sasl-initial-response-01b.txt

This version includes the change in the capability name as well as the
revised base64 text.

So, who's coming to IETF-58?

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----

Date: Wed, 29 Oct 2003 16:50:39 +0100
To: Zefram <[email-masked]>
From: "J-F C. (Jefsey)  Morfin" <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Cc: Dave Crocker <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On 10:31 28/10/03, Zefram said:
>I think the first task in this area should be to investigate the nature 
>and degree of desire for non-ASCII local parts.  This desire needs to be 
>weighed against the benefits we derive from writing all local parts in a 
>small, fixed alphabet (ASCII printables).

May I ask which part of the world you come from?

This being said only Americans want/are satisfied with "internationalized" 
(sic) names (the artificial extension of the American character set with 
most of the American foreign scripting, within an ascii frame). No one 
really wants multilingual names (a totally internationalized (sic) frame 
supporting languages and therefore some language oriented rules - at least 
ni management and user support). The users need vernacular support, that is 
to be able to freely do in the mail what they use to do elsewhere.

I note that for non-American writers "international names" means names that 
everyone from every nation will understand. It happens to be the ascii 
character set limited to the DNS used names (they were selected for that 
reason).
jfc

Date: Tue, 28 Oct 2003 17:41:55 -0800
To: [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Location of the IMAA list (was: RE: FYI: BOF on Internationalized Email Addresses (IEA))
Sender: [email-masked]

At 11:54 AM -0500 10/28/03, [email-masked] wrote:
>The BOF description lists [email-masked] as the
>discussion list, but this discussion is being
>cc:ed to [email-masked].  I'd suggest that you
>move this discussion to whichever of those lists
>is actually correct.

It is [email-masked], although because Patrik sent out the wrong 
address, I have made sure that both addresses work. An archive of the 
list, and links to the current versions of the drafts, can be found 
at <http://www.imc.org/ietf-imaa/>.

No more messages to all lists: that's what the IMAA list is for.

--Paul Hoffman, Director
--Internet Mail Consortium

From: [email-masked]
To: Mark Davis <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) 
Date: Tue, 28 Oct 2003 15:07:19 -0500
Sender: [email-masked]

--==_Exmh_-1503687178P
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, 27 Oct 2003 17:39:32 PST, Mark Davis said:

> email addresses. Mr. Tanaka can have one with Latin letters and one wit=
h
> Japanese (e.g. =E3=83=A0=E3=83=AB=E3=82=AF@=E3=82=AB=E3=82=AF.=E3=83=AF=
=E3=82=B7=E3=83=B3=E3=82=B0=E3=83=88=E3=83=B3.=E3=82=A8=E3=83=87=E3=82=A5=
).

This gets interesting in the context of a "reply all".

Apologies for breaking the UTF-8 in the quote, but it's illustrative - if=
 the
breakage had been in the To/Cc lines, things would have broken even worse=

unless whatever scheme we end up using is ASCII-transparent.

--==_Exmh_-1503687178P
Content-Type: application/pgp-signature

--==_Exmh_-1503687178P--

Date: Tue, 28 Oct 2003 12:36:07 -0500
From: John C Klensin <[email-masked]>
To: Marc Blanchet <[email-masked]>, Mark Davis <[email-masked]>, Mark Crispin <[email-masked]>, Abhijit Menon-Sen <[email-masked]>
cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

--On Tuesday, October 28, 2003 11:12 -0500 Marc Blanchet
<[email-masked]> wrote:

> it appears to me that this thread is not very different from
> the idn considerations on usage of idn in the world. So what
> is really new in this discussion?

See the draft.

Quick answer: DNS interfaces really exist at the protocol level,
and a large part of the hypothesis behind IDNA was that it would
be possible, after we had enough implementations, to prevent an
end-user from ever seeing an encoded domain name.  That story
just doesn't hold for a special encoding-based (aka MUA-only)
email local part implementation, and maybe not for email
generally.  For example, under current rules, an MTA is required
to stuff the name it actually sees in HELO/EHLO and the MAIL
command into various headers.  If it is expected to notice that
they have special encodings and decodes them, we've gone rather
far into "the infrastructure is involved", even if the actual
on-the-wire transport is not impacted.  If it doesn't do that,
the encodings --both the IDNA domain parts and the special mail
encoding-- are going to be in the user's face, in the most
literal sense of that term.  

The similarity of that situation to the early IDN discussions is
the importance of the "what problem are you solving" question.
And it is very clear to me that, for email addresses, the answer
has got to "user sees their own characters in their email
addresses and the email addresses of those whose languages they
speak/ recognize.  Users typically don't actually see envelopes.
But seeing, e.g., different forms/codings of an address in the
header "From:" field than appears in "Return-path:" or than
appears in a signature line in the message body, is going to
create real unhappiness.  Similarly as has been pointed out in
another context, seeing an address in different from when it
appears in a header than when it (and that header) are
encapsulated in a message/?? body part is just not going to
amuse any user to whom we've said "ok, now you have i18n
strings, enjoy your new found local language capabilities".  And
I guess that tells you what I think the problem is that we need
to solve.  YMMD.

     john

To: Mark Davis <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) 
From: [email-masked]
Date: Tue, 28 Oct 2003 15:07:19 -0500
Sender: [email-masked]

--==_Exmh_-1503687178P
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, 27 Oct 2003 17:39:32 PST, Mark Davis said:

> email addresses. Mr. Tanaka can have one with Latin letters and one wit=
h
> Japanese (e.g. =E3=83=A0=E3=83=AB=E3=82=AF@=E3=82=AB=E3=82=AF.=E3=83=AF=
=E3=82=B7=E3=83=B3=E3=82=B0=E3=83=88=E3=83=B3.=E3=82=A8=E3=83=87=E3=82=A5=
).

This gets interesting in the context of a "reply all".

Apologies for breaking the UTF-8 in the quote, but it's illustrative - if=
 the
breakage had been in the To/Cc lines, things would have broken even worse=

unless whatever scheme we end up using is ASCII-transparent.

--==_Exmh_-1503687178P
Content-Type: application/pgp-signature

--==_Exmh_-1503687178P--

Content-class: urn:content-classes:message
Subject: RE: Exchange server has a broken SASL implementation
Date: Tue, 28 Oct 2003 11:00:01 -0800
From: "Jeff Stephenson" <[email-masked]>
To: "IMAP Interest List" <[email-masked]>, "IMAP Extensions WG" <[email-masked]>
Sender: [email-masked]

Actually, Exchange didn't get around to implementing this recently -
it's been in Windows 2000 SMTP (which is what Exchange uses) since the
release of Windows 2K.  I'm dredging my memory here, but I believe that
the code for this was locked down during the ID stage of RFC 2554,
before the RFC was released.  As I recall, it was interop-tested at the
time, but there wasn't a lot to test against and I don't recall the
results.  I've passed this along to the Exchange folks, who say it's a
known issue that wasn't fixed when discovered out of fear of breaking
anything that might have relied on this behavior.  If this behavior is
breaking other apps, that would increase the impetus to fix it.

-- jeff

Jeff Stephenson
Software Developer
Microsoft Outlook

> -----Original Message-----
> From: Ken Murchison <[email-masked]>
> Subject: Re: Exchange server has a broken SASL implementation

...

> However, if there is/was any question about the specs, there 
> are mailing lists that can be contacted for clarification.  
> Interop testing could be done with non-MS products.  The CMU 
> SASL library comes with test harnesses which can be used for 
> testing.  There are at least 2 major MTAs (sendmail, postfix) 
> which use CMU SASL that could have been consulted for comparison.

Date: Tue, 28 Oct 2003 12:36:07 -0500
From: John C Klensin <[email-masked]>
To: Marc Blanchet <[email-masked]>, Mark Davis <[email-masked]>, Mark Crispin <[email-masked]>, Abhijit Menon-Sen <[email-masked]>
cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

--On Tuesday, October 28, 2003 11:12 -0500 Marc Blanchet
<[email-masked]> wrote:

> it appears to me that this thread is not very different from
> the idn considerations on usage of idn in the world. So what
> is really new in this discussion?

See the draft.

Quick answer: DNS interfaces really exist at the protocol level,
and a large part of the hypothesis behind IDNA was that it would
be possible, after we had enough implementations, to prevent an
end-user from ever seeing an encoded domain name.  That story
just doesn't hold for a special encoding-based (aka MUA-only)
email local part implementation, and maybe not for email
generally.  For example, under current rules, an MTA is required
to stuff the name it actually sees in HELO/EHLO and the MAIL
command into various headers.  If it is expected to notice that
they have special encodings and decodes them, we've gone rather
far into "the infrastructure is involved", even if the actual
on-the-wire transport is not impacted.  If it doesn't do that,
the encodings --both the IDNA domain parts and the special mail
encoding-- are going to be in the user's face, in the most
literal sense of that term.  

The similarity of that situation to the early IDN discussions is
the importance of the "what problem are you solving" question.
And it is very clear to me that, for email addresses, the answer
has got to "user sees their own characters in their email
addresses and the email addresses of those whose languages they
speak/ recognize.  Users typically don't actually see envelopes.
But seeing, e.g., different forms/codings of an address in the
header "From:" field than appears in "Return-path:" or than
appears in a signature line in the message body, is going to
create real unhappiness.  Similarly as has been pointed out in
another context, seeing an address in different from when it
appears in a header than when it (and that header) are
encapsulated in a message/?? body part is just not going to
amuse any user to whom we've said "ok, now you have i18n
strings, enjoy your new found local language capabilities".  And
I guess that tells you what I think the problem is that we need
to solve.  YMMD.

     john

From: "Mark Davis" <[email-masked]>
To: "Marc Blanchet" <[email-masked]>, "Mark Crispin" <[email-masked]>, "Abhijit Menon-Sen" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Tue, 28 Oct 2003 08:22:37 -0800
Sender: [email-masked]

I wouldn't have thought so either, but at least some people questioned the need
for non-Latin characters, and went so far as to exclude them from a proposed
problem statement:

> ... There is a growing need to use additional
> characters, specifically Latin characters with diacriticals and non-Latin
> characters, in email addresses to better serve the needs of the
> multi-national Internet community...

Mark
__________________________________
http://www.macchiato.com
► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- 
From: "Marc Blanchet" <[email-masked]>
To: "Mark Davis" <[email-masked]>; "Mark Crispin"
<[email-masked]>; "Abhijit Menon-Sen" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tue, 2003 Oct 28 08:12
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)

>
> it appears to me that this thread is not very different from the idn
> considerations on usage of idn in the world. So what is really new in this
> discussion?
>
> Marc.
>
> -- Tuesday, October 28, 2003 07:10:59 -0800 Mark Davis
> <[email-masked]> wrote/a ecrit:
>
> >> > (I agree that it's currently nearly impossible to use computers if one
> >> > isn't familiar with the Latin script, of course.)
> >>
> >> Which probably makes the rest of this discussion academic, unless we're
> >> going to undertake solving *that* problem for Microsoft and the various
> >> UNIX/Linux vendors...
> >
> > It is currently impossible to use the Internet without knowing the Latin
> > script. However, the goal of most well-designed client software and
> > operating systems is to permit the user to work entirely within their
> > native language, with a fully localized system. This is reaching to India
> > and other countries; Microsoft has introduced fully localized versions of
> > Indic Windows just recently, and Linux vendors are hard at work to
> > produce fully localized versions of their software.
> >
> > Email and Web addresses are the big remaining holdouts for most people.
> > People should not be forced to use a script that they are unfamiliar
> > with, just to use email addresses and sites in their own countries. Even
> > if they are familiar with the Latin script, it is very often a very bad
> > match for their languages, making it very difficult to figure out how
> > native words would be spelled in it.
> >
> > Mark
> >
>
>
>
> ------------------------------------------
> Marc Blanchet
> Hexago
> tel: +1-418-266-5533x225
> ------------------------------------------
> http://www.freenet6.net: IPv6 connectivity
> ------------------------------------------
>

Date: Tue, 28 Oct 2003 11:12:54 -0500
From: Marc Blanchet <[email-masked]>
To: Mark Davis <[email-masked]>, Mark Crispin <[email-masked]>, Abhijit Menon-Sen <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

it appears to me that this thread is not very different from the idn
considerations on usage of idn in the world. So what is really new in this
discussion?

Marc.

-- Tuesday, October 28, 2003 07:10:59 -0800 Mark Davis
<[email-masked]> wrote/a ecrit:

>> > (I agree that it's currently nearly impossible to use computers if one
>> > isn't familiar with the Latin script, of course.)
>> 
>> Which probably makes the rest of this discussion academic, unless we're
>> going to undertake solving *that* problem for Microsoft and the various
>> UNIX/Linux vendors...
> 
> It is currently impossible to use the Internet without knowing the Latin
> script. However, the goal of most well-designed client software and
> operating systems is to permit the user to work entirely within their
> native language, with a fully localized system. This is reaching to India
> and other countries; Microsoft has introduced fully localized versions of
> Indic Windows just recently, and Linux vendors are hard at work to
> produce fully localized versions of their software.
> 
> Email and Web addresses are the big remaining holdouts for most people.
> People should not be forced to use a script that they are unfamiliar
> with, just to use email addresses and sites in their own countries. Even
> if they are familiar with the Latin script, it is very often a very bad
> match for their languages, making it very difficult to figure out how
> native words would be spelled in it.
> 
> Mark
> 

------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------

From: "Mark Davis" <[email-masked]>
To: "Mark Crispin" <[email-masked]>, "Abhijit Menon-Sen" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Tue, 28 Oct 2003 07:10:59 -0800
Sender: [email-masked]

> > (I agree that it's currently nearly impossible to use computers if one
> > isn't familiar with the Latin script, of course.)
>
> Which probably makes the rest of this discussion academic, unless we're
> going to undertake solving *that* problem for Microsoft and the various
> UNIX/Linux vendors...

It is currently impossible to use the Internet without knowing the Latin script.
However, the goal of most well-designed client software and operating systems is
to permit the user to work entirely within their native language, with a fully
localized system. This is reaching to India and other countries; Microsoft has
introduced fully localized versions of Indic Windows just recently, and Linux
vendors are hard at work to produce fully localized versions of their software.

Email and Web addresses are the big remaining holdouts for most people. People
should not be forced to use a script that they are unfamiliar with, just to use
email addresses and sites in their own countries. Even if they are familiar with
the Latin script, it is very often a very bad match for their languages, making
it very difficult to figure out how native words would be spelled in it.

Mark

From: "Mark Davis" <[email-masked]>
To: "Stephane Bortzmeyer" <[email-masked]>
Cc: "Mark Crispin" <[email-masked]>, "Keith Moore" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "IMAP Extensions WG" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Tue, 28 Oct 2003 06:54:45 -0800
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0068_01C39D20.5EDF9090
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Sigh. I used "Greek" in an analogy because I was hoping that some of the =
Latin-only folks out there would at least recognize the name of one =
other script. But how comforable would you really be, if =
=D9=8A=D9=8F=D9=8F =D9=88=D9=90=D8=B1=D9=90 =
=D9=81=D9=8F=D8=B1=D8=B3=D9=90=D8=AF =D8=AA=D9=8F =
=D8=B1=D9=8E=D9=90=D8=AF =D9=8E=D9=86 =
=D9=90=D9=86=D8=AA=D9=90=D8=B1=D9=90=D9=84=D9=8A =
=D8=AF=D9=90=D9=81=D9=81=D9=90=D8=B1=D9=90=D9=86=D8=AA =
=D8=B3=D9=83=D8=B1=D9=90=D9=BE=D8=AA=D8=8C =
=D8=B3=D9=90=D9=85=D9=BE=D9=84=D9=8A =D8=AA=D9=8F =
=D9=8F=D9=86=D8=AF=D9=90=D8=B1=D8=B3=D8=AA=D9=8E=D9=86=D8=AF =
=D9=90=D9=85=D9=8E=D9=90=D9=84 =
=D9=8E=D8=AF=D8=AF=D8=B1=D9=90=D8=B3=D8=B3=D9=90=D8=B3=D8=8C =
=D9=8E=D9=86=D8=AF =D9=8E =D8=B3=D9=83=D8=B1=D9=90=D9=BE=D8=AA =
=D8=AA=D9=87=D9=8E=D8=AA =D9=83=D9=8F=D9=8F=D9=84=D8=AF =
=D9=8F=D9=86=D9=84=D9=8A =
=D9=BE=D9=8E=D8=B1=D8=AA=D9=8E=D9=90=D9=84=D9=84=D9=8A =
=D8=B1=D9=90=D9=81=D9=84=D9=90=D9=83=D8=AA =D8=AA=D9=87=D9=90 =
=D8=B1=D9=8E=D9=90=D9=84 =
=D8=B3=D9=BE=D9=90=D9=84=D9=84=D9=90=D9=86=DA=AF =D9=8F=D9=81 =
=D9=8A=D9=8F=D9=8F=D8=B1 =D9=88=D9=8F=D8=B1=D8=AF=D8=B3?

Mark
__________________________________

=20
----- Original Message -----=20
From: "Stephane Bortzmeyer" <[email-masked]>
To: "Mark Davis" <[email-masked]>
Cc: "Mark Crispin" <[email-masked]>; "Keith Moore" =
<[email-masked]>; <[email-masked]>; <[email-masked]>; =
<[email-masked]>; <[email-masked]>; <[email-masked]>; =
<[email-masked]>; <[email-masked]>; <[email-masked]>; =
<[email-masked]>; "IMAP Extensions WG" <[email-masked]>; =
<[email-masked]>; <[email-masked]>; <[email-masked]>; =
<[email-masked]>
Sent: Tue, 2003 Oct 28 00:50
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses =
(IEA)

> On Mon, Oct 27, 2003 at 05:39:32PM -0800,
>  Mark Davis <[email-masked]> wrote=20
>  a message of 76 lines which said:
>=20
> > We should remember that for a great many people in the world, Latin =
letters are
> > quite unnatural; it'd be a bit like if we had to use Greek letters =
in all email
> > addresses.=20
>=20
> It would be a bit like if we had to use Greek letters in mathematics
> :-)
>=20
> 
------=_NextPart_000_0068_01C39D20.5EDF9090
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
<META content=3D"MSHTML 6.00.2800.1264" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3D"Times New Roman">Sigh. I used "Greek" in an analogy =
because I=20
was hoping that some of the Latin-only folks out there would at least=20
recognize&nbsp;the name of one&nbsp;other script. But how comforable =
would you=20
really be, if =D9=8A=D9=8F=D9=8F =D9=88=D9=90=D8=B1=D9=90 =
=D9=81=D9=8F=D8=B1=D8=B3=D9=90=D8=AF =D8=AA=D9=8F =
=D8=B1=D9=8E=D9=90=D8=AF =D9=8E=D9=86 =
=D9=90=D9=86=D8=AA=D9=90=D8=B1=D9=90=D9=84=D9=8A =
=D8=AF=D9=90=D9=81=D9=81=D9=90=D8=B1=D9=90=D9=86=D8=AA =
=D8=B3=D9=83=D8=B1=D9=90=D9=BE=D8=AA=D8=8C =
=D8=B3=D9=90=D9=85=D9=BE=D9=84=D9=8A =D8=AA=D9=8F=20
=D9=8F=D9=86=D8=AF=D9=90=D8=B1=D8=B3=D8=AA=D9=8E=D9=86=D8=AF =
=D9=90=D9=85=D9=8E=D9=90=D9=84 =
=D9=8E=D8=AF=D8=AF=D8=B1=D9=90=D8=B3=D8=B3=D9=90=D8=B3=D8=8C =
=D9=8E=D9=86=D8=AF =D9=8E =D8=B3=D9=83=D8=B1=D9=90=D9=BE=D8=AA =
=D8=AA=D9=87=D9=8E=D8=AA =D9=83=D9=8F=D9=8F=D9=84=D8=AF =
=D9=8F=D9=86=D9=84=D9=8A =
=D9=BE=D9=8E=D8=B1=D8=AA=D9=8E=D9=90=D9=84=D9=84=D9=8A =
=D8=B1=D9=90=D9=81=D9=84=D9=90=D9=83=D8=AA =D8=AA=D9=87=D9=90=20
=D8=B1=D9=8E=D9=90=D9=84 =
=D8=B3=D9=BE=D9=90=D9=84=D9=84=D9=90=D9=86=DA=AF =D9=8F=D9=81 =
=D9=8A=D9=8F=D9=8F=D8=B1 =D9=88=D9=8F=D8=B1=D8=AF=D8=B3?</FONT></DIV>
<DIV><BR><FONT=20
size=3D2>Mark<BR>__________________________________<BR><BR>&nbsp;</FONT><=
/DIV>
<DIV><FONT size=3D2>----- Original Message ----- </FONT>
<DIV><FONT size=3D2>From: "Stephane Bortzmeyer" &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT =
size=3D2>[email-masked]</FONT></A><FONT=20
size=3D2>&gt;</FONT></DIV>
<DIV><FONT size=3D2>To: "Mark Davis" &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;</FONT></DIV>
<DIV><FONT size=3D2>Cc: "Mark Crispin" &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; "Keith =
Moore"=20
&lt;</FONT><A href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; =
&lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT =
size=3D2>[email-masked]</FONT></A><FONT=20
size=3D2>&gt;; &lt;</FONT><A href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT =
size=3D2>[email-masked]</FONT></A><FONT=20
size=3D2>&gt;; &lt;</FONT><A href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT =
size=3D2>[email-masked]</FONT></A><FONT=20
size=3D2>&gt;; &lt;</FONT><A href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; =
&lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT =
size=3D2>[email-masked]</FONT></A><FONT=20
size=3D2>&gt;; &lt;</FONT><A href=3D"mailto:[email-masked]"><FONT =

size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; "IMAP =
Extensions WG"=20
&lt;</FONT><A href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; =
&lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT =
size=3D2>[email-masked]</FONT></A><FONT=20
size=3D2>&gt;; &lt;</FONT><A href=3D"mailto:[email-masked]"><FONT =

size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; =
&lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; =
&lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT =
size=3D2>&gt;</FONT></DIV>
<DIV><FONT size=3D2>Sent: Tue, 2003 Oct 28 00:50</FONT></DIV>
<DIV><FONT size=3D2>Subject: Re: [idn] Re: FYI: BOF on Internationalized =
Email=20
Addresses (IEA)</FONT></DIV></DIV>
<DIV><FONT size=3D2><BR></FONT></DIV><FONT size=3D2>&gt; On Mon, Oct 27, =
2003 at=20
05:39:32PM -0800,<BR>&gt; &nbsp;Mark Davis &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt; wrote =
<BR>&gt; &nbsp;a=20
message of 76 lines which said:<BR>&gt; <BR>&gt; &gt; We should remember =
that=20
for a great many people in the world, Latin letters are<BR>&gt; &gt; =
quite=20
unnatural; it'd be a bit like if we had to use Greek letters in all=20
email<BR>&gt; &gt; addresses. <BR>&gt; <BR>&gt; It would be a bit like =
if we had=20
to use Greek letters in mathematics<BR>&gt; :-)<BR>&gt; <BR>&gt;=20
</FONT></BODY></HTML>

------=_NextPart_000_0068_01C39D20.5EDF9090--

From: Arnt Gulbrandsen <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Cc: [email-masked], [email-masked], IETF RFC-822 list <[email-masked]>, IMAA list <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked], Abhijit Menon-Sen <[email-masked]>, [email-masked], IETF/IDN WG <[email-masked]>
Date: Tue, 28 Oct 2003 11:15:17 +0100
Sender: [email-masked]

Mark Crispin writes:
> On Tue, 28 Oct 2003, Abhijit Menon-Sen wrote:
>> (I agree that it's currently nearly impossible to use computers if 
>> one isn't familiar with the Latin script, of course.)
>
> Which probably makes the rest of this discussion academic, unless 
> we're going to undertake solving *that* problem for Microsoft and the 
> various UNIX/Linux vendors...

You're not appreciating the full complexity of the problem. ;)

Not only should the email standards permit MUAs and MTAs of the year 
2020 to solve the problem Abhijit mentions, but they should even permit 
such future programs to interoperate with latinate ones of the present 
and near future. And if it's too hard for latinate MUAs to implement 
the IEA standard, that won't happen.

--Arnt

Date: Tue, 28 Oct 2003 01:13:50 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Pete Resnick <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, Dave Crocker <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Pete,

>>RB> Restricting the disucssion to local-parts runs the risk of excluding
>>RB> other potentially relevent issues.
PR> I agree. Limiting discussion at this point to local-part does not
PR> take into account some of the possibilities.

That was exactly the intent of the text.

We have already seen how nicely the text served to bring into pretty stark
relief one bit of expectation from one of the proposals. It is only fitting to
have it serve the same purpose for another one.

IETF BOF time is pretty lousy for an open-ended chat.  Having specifications
to chat about is only marginally better than not having them.

What makes the real difference is having serious focus to the meeting. If we
go into this meeting without even having a clear sense of the scope of the
problem to be tackled, then the chance of having a productive meeting is
pretty small.

At the moment, it appears that the focus of the meeting is likely to be:
Shall we break existing Internet mail or shall we lay an enhancement on top of
it that preserves the installed base.  (I'm sure that everyone else who was
present at the pre-MIME/ESMTP discussions is really looking forward to
repeating the experience.)

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

Date: Tue, 28 Oct 2003 09:50:23 +0100
From: Stephane Bortzmeyer <[email-masked]>
To: Mark Davis <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Organization: NIC France
Sender: [email-masked]

On Mon, Oct 27, 2003 at 05:39:32PM -0800,
 Mark Davis <[email-masked]> wrote 
 a message of 76 lines which said:

> We should remember that for a great many people in the world, Latin letters are
> quite unnatural; it'd be a bit like if we had to use Greek letters in all email
> addresses. 

It would be a bit like if we had to use Greek letters in mathematics
:-)

Date: Tue, 28 Oct 2003 01:20:58 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Cc: Roy Badami <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, Dave Crocker <[email-masked]>
Sender: [email-masked]

On 10/27/03 at 6:42 PM -0800, Dave Crocker wrote:

>RB> Even though, given IDNA now exists as a proposed standard, the main
>RB> issues relate to the local part, the issue under discussion is that of
>RB> internationalized mail addresses, not just internationalized
>RB> local-parts.
>
>Really?  What work needs to be done, except for local part?  IDNA takes care
>of the right-hand side.

Please review John Klensin's draft before making these kinds of assumptions.

>RB> Restricting the disucssion to local-parts runs the risk of excluding
>RB> other potentially relevent issues.

I agree. Limiting discussion at this point to local-part does not 
take into account some of the possibilities.

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

Date: Mon, 27 Oct 2003 20:42:19 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Abhijit Menon-Sen <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 28 Oct 2003, Abhijit Menon-Sen wrote:
> The number of people in India who can read and write only their native
> language, but have no usable knowledge of Latin script, is much larger
> than the tiny number who are familiar with both. I'm told that this is
> true for many native speakers of Chinese and Arabic as well.

I defer to your superior knowledge about India.

I do not believe that this is true for Chinese.  AFAIK, Chinese primary
school kids use Latin script with hanyu-pinyin as a stopgap prior to their
mastery of Han script (which takes many years).

> The use of local scripts is much more than just a "preference" for the
> numerous localisation efforts in India which focus on making computing
> more accessible to poor farmers and people in villages.

A poor farmer or villager in China is more likely to be totally illiterate
than to be literate in Han script but unable to recognize Latin script.

Note that when I say "recognize Latin script", I mean the ability to
determine that "dog" is a three-letter word that has the letters "d", "o",
and "g", each of which the individual recognizes and can name.  This does
not include the ability to recognize that this refers to a domesticated
canine.

> (I agree that it's currently nearly impossible to use computers if one
> isn't familiar with the Latin script, of course.)

Which probably makes the rest of this discussion academic, unless we're
going to undertake solving *that* problem for Microsoft and the various
UNIX/Linux vendors...

-- Mark --

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

Date: Tue, 28 Oct 2003 09:52:43 +0530
From: Abhijit Menon-Sen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

At 2003-10-27 19:37:37 -0800, [email-masked] wrote:
>
> I do not believe many individuals (other than primary school children) are
> literate in their native language but are completely illiterate in Latin
> script.  This does not mean "being able to read or write the English
> language"; rather, this simply means knowing the Latin script alphabet.

Mark,

The number of people in India who can read and write only their native
language, but have no usable knowledge of Latin script, is much larger
than the tiny number who are familiar with both. I'm told that this is
true for many native speakers of Chinese and Arabic as well.

The use of local scripts is much more than just a "preference" for the
numerous localisation efforts in India which focus on making computing
more accessible to poor farmers and people in villages.

(I agree that it's currently nearly impossible to use computers if one
isn't familiar with the Latin script, of course.)

-- ams

Date: Mon, 27 Oct 2003 19:37:37 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Mark Davis <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 27 Oct 2003, Mark Davis wrote:
> Based on what I've seen, I think it quite likely that people will want email
> addresses in their native script, even if that means that outsiders can't
> (easily) use those email address.

That may well be the case.

> We should remember that for a great many people in the world, Latin
> letters are quite unnatural; it'd be a bit like if we had to use Greek
> letters in all email addresses. And there are many projects underway in
> less-developed countries to bring computers to masses of people that
> will even less familiarity with Latin letters.

I am not convinced that it is possible to use a computer on the Internet
anywhere in the world without at least a basic acquaintance with Latin
script.

I do not believe many individuals (other than primary school children) are
literate in their native language but are completely illiterate in Latin
script.  This does not mean "being able to read or write the English
language"; rather, this simply means knowing the Latin script alphabet.

Put another way, individuals who are completely illiterate in Latin script
are also likely to be illiterate in their native language script as well.

No other script on the planet has such international recognition.

There is undoubtably a *preference* for one's native script; and that
preference should be respected as much as possible.

-- Mark --

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

Date: Mon, 27 Oct 2003 18:42:26 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Roy Badami <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Roy,

 >> Mail Internationalised Local-Part (MILP)

RB> Even though, given IDNA now exists as a proposed standard, the main
RB> issues relate to the local part, the issue under discussion is that of
RB> internationalized mail addresses, not just internationalized
RB> local-parts.

Really?  What work needs to be done, except for local part?  IDNA takes care
of the right-hand side.

So what is there to do about "internationalized mail addresses" other than the
local part?

RB> Restricting the disucssion to local-parts runs the risk of excluding
RB> other potentially relevent issues.  For instance, one of the issues
RB> that has been discussed on the IMAA list is whether full-width at
RB> should be recognized in an internationalized mail address.

full-width _where_?  somewhere other than local part?

if yes, then how can that be practical?  if no, then the charter does not
preclude their use.  (if you think otherwise, please explain.)

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

From: "Mark Davis" <[email-masked]>
To: "Mark Crispin" <[email-masked]>
Cc: "Keith Moore" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "IMAP Extensions WG" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Mon, 27 Oct 2003 17:39:32 -0800
Sender: [email-masked]

Ok, I understand more about the context.

Based on what I've seen, I think it quite likely that people will want email
addresses in their native script, even if that means that outsiders can't
(easily) use those email address. After all, it is quite easy to have multiple
email addresses. Mr. Tanaka can have one with Latin letters and one with
Japanese (e.g. [email-masked]).

We should remember that for a great many people in the world, Latin letters are
quite unnatural; it'd be a bit like if we had to use Greek letters in all email
addresses. And there are many projects underway in less-developed countries to
bring computers to masses of people that will even less familiarity with Latin
letters.

Mark
__________________________________
http://www.macchiato.com
► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- 
From: "Mark Crispin" <[email-masked]>
To: "Mark Davis" <[email-masked]>
Cc: "Keith Moore" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; "IMAP Extensions WG" <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Mon, 2003 Oct 27 17:15
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)

> On Mon, 27 Oct 2003, Mark Davis wrote:
> > I'm curious: why do you think that everyone would be satisfied with Latin
> > characters only, and no non-Latin characters?
>
> I didn't say that.  I stated my belief that, for reasons of practicality,
> most individuals in regions which do not use Latin script accept the use
> of Latin script for multinational exchange.
>
> It does not work well for an individual in Japan with surname Tanaka to
> expect the overwhelming majority of non-Japanese individuals worldwide to
> know his surname is written with the Han characters for "rice paddy" and
> "middle", or what those characters look like, or how to enter those
> characters on the computer.
>
> It does, however, work for him to expect that the overwhelming majority of
> individuals worldwide to know how to deal with the 6 Latin letters that
> form the romanization "Tanaka".
>
> Nor is it very likely that this situation will change in the future.  I
> doubt that many individuals in the world are literate in all the world's
> active scripts.  Literacy in one's native script and basic Latin script is
> something that most computer users possess today.
>
> For domestic exchange only, that pair of Han characters are probably
> alright.  Within Western Europe, it's probably alright to use Latin
> characters with diacriticals.
>
> Perhaps the main problem that needs to be decided in any IEA effort is if
> it is alright to have email addresses that are only usable in limited
> areas of the world; or if not, how to represent internationalized email
> addresses in a usable fashion when (not if) the email address needs to be
> represented for a person and/or computer is illiterate in that script.
>
> A likely side issue is whether it is "good enough" to promote Latin
> characters with diacriticals to the same status of "everybody must know
> how to do these" that is required for ASCII.
>
> -- Mark --
>
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
> Si vis pacem, para bellum.
>

Date: Mon, 27 Oct 2003 17:15:00 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Mark Davis <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 27 Oct 2003, Mark Davis wrote:
> I'm curious: why do you think that everyone would be satisfied with Latin
> characters only, and no non-Latin characters?

I didn't say that.  I stated my belief that, for reasons of practicality,
most individuals in regions which do not use Latin script accept the use
of Latin script for multinational exchange.

It does not work well for an individual in Japan with surname Tanaka to
expect the overwhelming majority of non-Japanese individuals worldwide to
know his surname is written with the Han characters for "rice paddy" and
"middle", or what those characters look like, or how to enter those
characters on the computer.

It does, however, work for him to expect that the overwhelming majority of
individuals worldwide to know how to deal with the 6 Latin letters that
form the romanization "Tanaka".

Nor is it very likely that this situation will change in the future.  I
doubt that many individuals in the world are literate in all the world's
active scripts.  Literacy in one's native script and basic Latin script is
something that most computer users possess today.

For domestic exchange only, that pair of Han characters are probably
alright.  Within Western Europe, it's probably alright to use Latin
characters with diacriticals.

Perhaps the main problem that needs to be decided in any IEA effort is if
it is alright to have email addresses that are only usable in limited
areas of the world; or if not, how to represent internationalized email
addresses in a usable fashion when (not if) the email address needs to be
represented for a person and/or computer is illiterate in that script.

A likely side issue is whether it is "good enough" to promote Latin
characters with diacriticals to the same status of "everybody must know
how to do these" that is required for ASCII.

-- Mark --

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

Date: Mon, 27 Oct 2003 20:08:25 -0500
From: Marc Blanchet <[email-masked]>
To: Dave Crocker <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

- good start!
- timeline seems pretty agressive... will see.
- would probably good to have a requirement document upfront. Might not the
same way that idn requirement ends up, but a narrow-implementable
requirement would help to have a concensus (hopefully) on what needs to be
done. 
- while the idn req went not that good, now that we have experience, I
think we should try to be better and have one.

I know I might start some debate with this, but still think it is the best
way to go...

- would be useful to have some reference to idn (idna) in the charter, as
background work. the developers and users will have to take care of "both"
(ie. idn and imail) in the email infrastructure.

Marc.

-- Monday, October 27, 2003 16:19:25 -0800 Dave Crocker <[email-masked]>
wrote/a ecrit:

> Folks,
> 
> On the theory that discussions go better when they have a concrete
> deliverable, here is a proposed charter for a proposed working group.
> 
> The following started with Mark Crispin's text, although it might not
> look it. Besides the usual goals for a charter, the following text
> attempts to specify the problem domain in the narrowest feasible form
> that is valid. If anyone thinks the scope is too narrow, they need to
> explain why.
> 
> 
> 
> DRAFT CHARTER
> 
> Mail Internationalised Local-Part (MILP)
> ---------------------------------
> 
> The <local-part> portion of RFC2822 and <Local-part> portion of RFC2821
> mail addresses are restricted to a subset of ASCII. This poses a
> fundamental barrier for users needing mail addresses to be expressed in a
> richer set of characters, such as Latin characters with diacriticals and
> the many Asian characters. The goal of the current work is to add
> local-part support for these additional characters, while preserving the
> large, installed base of ASCII usage.
> 
> The group will take:
> 
>    draft-hoffman-imaa-03.txt
>    draft-klensin-emailaddr-i18n-01.txt
>    draft-duerst-iri-04.txt
> 
> as input to discussions.
> 
> The group will pay particular attention to barriers to adoption and
> utility, as well as any impact the new scheme might have on the existing
> base of Internet mail usage.
> 
> 
> Milestones
> ----------
> 
> Nov, 03:  BOF
> 
> Dec, 03:  WG chartered
> 
> Feb, 03:  Initial draft of working group specifications.
> 
> Jun, 03:  Specifications submitted for IETF approval
> 
> 
> d/
> --
>  Dave Crocker <dcrocker-at-brandenburg-dot-com>
>  Brandenburg InternetWorking <www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>
> 

------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------

Date: Tue, 28 Oct 2003 00:50:53 +0000
To: Dave Crocker <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
From: Roy Badami <[email-masked]>
Sender: [email-masked]

 > Mail Internationalised Local-Part (MILP)

Even though, given IDNA now exists as a proposed standard, the main
issues relate to the local part, the issue under discussion is that of
internationalized mail addresses, not just internationalized
local-parts.

Restricting the disucssion to local-parts runs the risk of excluding
other potentially relevent issues.  For instance, one of the issues
that has been discussed on the IMAA list is whether full-width at
should be recognized in an internationalized mail address.  IMHO, the
charter shouldn't be framed in a way that is sufficiently narrow as to
render such questions out of scope.

	-roy

Date: Mon, 27 Oct 2003 16:19:25 -0800
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Folks,

On the theory that discussions go better when they have a concrete
deliverable, here is a proposed charter for a proposed working group.

The following started with Mark Crispin's text, although it might not look it.
Besides the usual goals for a charter, the following text attempts to specify
the problem domain in the narrowest feasible form that is valid. If anyone
thinks the scope is too narrow, they need to explain why.

DRAFT CHARTER

Mail Internationalised Local-Part (MILP)
---------------------------------

The <local-part> portion of RFC2822 and <Local-part> portion of RFC2821 mail
addresses are restricted to a subset of ASCII. This poses a fundamental
barrier for users needing mail addresses to be expressed in a richer set of
characters, such as Latin characters with diacriticals and the many Asian
characters. The goal of the current work is to add local-part support for
these additional characters, while preserving the large, installed base of
ASCII usage.

The group will take:

   draft-hoffman-imaa-03.txt
   draft-klensin-emailaddr-i18n-01.txt
   draft-duerst-iri-04.txt

as input to discussions.

The group will pay particular attention to barriers to adoption and utility,
as well as any impact the new scheme might have on the existing base of
Internet mail usage.

Milestones
----------

Nov, 03:  BOF

Dec, 03:  WG chartered

Feb, 03:  Initial draft of working group specifications.

Jun, 03:  Specifications submitted for IETF approval

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

From: "Mark Davis" <[email-masked]>
To: "Mark Crispin" <[email-masked]>, "Keith Moore" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Mon, 27 Oct 2003 16:16:20 -0800
Sender: [email-masked]

I'm curious: why do you think that everyone would be satisfied with Latin
characters only, and no non-Latin characters?

Mark
__________________________________
http://www.macchiato.com
► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- 
From: "Mark Crispin" <[email-masked]>
To: "Keith Moore" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Mon, 2003 Oct 27 11:10
Subject: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)

> On Mon, 27 Oct 2003, Keith Moore wrote:
>
>  >> Thanks for taking a stab at a problem statement.  I'd like to drill down
>  >> on this just a bit.
>  >> What is the source of the "growing need"?  Is it:
>  >> [snip]
>
>
> I agree that this needs to be stated, but someone other than me will have
> to do it.
>
> I believe that the primary push for this functionality comes from regions
> which use Latin alphabetics with diacriticals; and that most individuals
> in regions which do not use Latin script are accept the use of Latin
> script for multinational interchange.  In many regions where Latin
> diacriticals are used, there is no acceptable transform of a surname to a
> form that does not use diacriticals.  Simply omitting the diacritical
> causes (at least to the inhabitants of those regions) a misspelling.
>
> This set of beliefs naturally biases how I approach the problem.  The
> problem statement must be free of bias, including mine.
>
> -- Mark --
>
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
> Si vis pacem, para bellum.
>
>
>
>
>
>
>
>

Date: Mon, 27 Oct 2003 19:07:09 +0800
From: James Seng <[email-masked]>
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Pete Resnick <[email-masked]>, Ted Hardie <[email-masked]>, Ned Freed <[email-masked]>
Subject: Re: [idn] FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

I seen John and Paul proposal but I have not seen Michel. Is there a 
draft that I can read up?

ps: I wont be able to join the meeting but I am interested in the subject.

-James Seng

Patrik F�ltstr�m wrote:

> At the IETF in Minneapolis, there will be a BOF on Internationalized 
> Email Addresses (IEA).
> 
> It is *preliminary* on the agenda on Monday, November 10, 2003 at 
> 1530-1730.
> 
> Chairs:  Pete Resnick, Patrik F�ltstr�m
> Mailing list:[email-masked] (other salient lists include [email-masked])
> Agenda:
> 
> Agenda Bashing (Chairs)                5 min.
> Topic Introduction (Chairs)           10 min.
> Proposals
>   IDNA-Based (Paul Hoffman)           15 min.
>   Infrastructure-Based (John Klensin) 15 min.
>   IRI-Based (Michel Suignard)         15 min.
> 
> Discussion                            60 min.
> 
> Topics for discussion:
> 
>   Are there other solutions which have been specified?
> 
>   The solutions present the problem at different scopes;
> 
>      Where should the IETF tackle it?
> 
>      Are some short-term, and other long-term?
> 
>      Can the solutions be staged or co-exist?
> 
>      If staged, how to migrate from one to another?
> 
>   What are the next steps for the IETF?
> 
> 
> NB:  This BoF is exploratory in nature, and it is not intended that the 
> IETF will finalize a decision in this venue.  It was proposed to foster 
> a community discussion, not charter a working group or pick a winner. If 
> further work is required, step one would be identifying individuals 
> willing to carry that work forward.
> 
> Reading material:
>   draft-hoffman-imaa-03.txt
>   draft-klensin-emailaddr-i18n-01.txt
>   draft-duerst-iri-04.txt
> 
> Pete and myself hope people will come with a lot of constructive 
> comments and ideas.
> 
>         Patrik, co-chair of the bof
> 
> 
> 
> 
> 

Date: Mon, 27 Oct 2003 11:10:55 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Keith Moore <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

On Mon, 27 Oct 2003, Keith Moore wrote:
> Thanks for taking a stab at a problem statement.  I'd like to drill down
> on this just a bit.
> What is the source of the "growing need"?  Is it:
> [snip]

I agree that this needs to be stated, but someone other than me will have
to do it.

I believe that the primary push for this functionality comes from regions
which use Latin alphabetics with diacriticals; and that most individuals
in regions which do not use Latin script are accept the use of Latin
script for multinational interchange.  In many regions where Latin
diacriticals are used, there is no acceptable transform of a surname to a
form that does not use diacriticals.  Simply omitting the diacritical
causes (at least to the inhabitants of those regions) a misspelling.

This set of beliefs naturally biases how I approach the problem.  The
problem statement must be free of bias, including mine.

-- Mark --

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

Date: Mon, 27 Oct 2003 13:44:03 -0500
From: Keith Moore <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Mark,

Thanks for taking a stab at a problem statement.  I'd like to drill down
on this just a bit.

What is the source of the "growing need"?  Is it:

a. for users of many languages (particularly those not using Latin alphabets)
   email addresses are difficult to remember
b. for users of many languages (particularly those not using Latin alphabets)
   email addresses are difficult to transcribe or type
c. users want to use their names in email addresses
d. users are confused by apparently arbitrary restrictions on use of 
   characters in email addresses, and this leads to mistakes
e. on computer systems employing non-ASCII names for other purposes (e.g.
   login or account names) these do not map well to ASCII email addresses

or something else that I don't see?

> As presently constituted, email addresses are limited to the 26 Latin
> alphabetics, 10 digits, and a limited number of special characters in
> the ASCII character set.  There is a growing need to use additional
> characters, specifically Latin characters with diacriticals and
> non-Latin characters, in email addresses to better serve the needs of
> the multi-national Internet community.  However, the restrictions of
> ASCII email addresses have served as a "lingua franca" since everybody
> can enter ASCII email addresses, and there is an ongoing need for this
> as well.  The problem to be solved is the resolution of these two
> needs.

Date: Mon, 27 Oct 2003 12:49:31 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Arnt Gulbrandsen <[email-masked]>
CC: IMAP Interest List <[email-masked]>, Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Exchange server has a broken SASL implementation
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> Ken Murchison writes:
> 
>> Mark Crispin wrote:
>>
>>> Yet more proof that the SASL specifications as currently constituted 
>>> are too complex, and why IMAP should not add initial-response until 
>>> the SASL specifications are fixed.
>>
>>
>> Or its more proof that M$ doesn't care about specs and choose to 
>> [re]define then as they see fit.
> 
> 
> Do not attribute to malice that which can be adequately explained by 
> ignorance/release pressure/lack of time/blah/blah. So far, every 
> Microsoft programmer I've spoken to seemed to try hard. (I'm not saying 
> they succeed, but I _am_ saying they don't seem a malicious bunch.)

I didn't mean to imply that anything that doesn't meet the specs was 
done maliciously by the programmers (over frustration from replying to 
Outlook bug emails).  I have no knowledge that any mistakes are anything 
other than just simple mistakes.

However, if there is/was any question about the specs, there are mailing 
lists that can be contacted for clarification.  Interop testing could be 
done with non-MS products.  The CMU SASL library comes with test 
harnesses which can be used for testing.  There are at least 2 major 
MTAs (sendmail, postfix) which use CMU SASL that could have been 
consulted for comparison.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 27 Oct 2003 09:30:46 -0800
From: [email-masked] (WJCarpenter)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

mc> As presently constituted, email addresses are limited to the 26
mc> Latin alphabetics, 10 digits, and a limited number of special
mc> characters in the ASCII character set.  There is a growing need to

upper and lower case alphabetics
-- 
[email-masked] (WJCarpenter)    PGP 0x91865119
38 95 1B 69 C9 C6 3D 25    73 46 32 04 69 D6 ED F3

Date: Mon, 27 Oct 2003 09:17:54 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: Ken Murchison <[email-masked]>, IMAP Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Exchange server has a broken SASL implementation
Sender: [email-masked]

On Mon, 27 Oct 2003, Arnt Gulbrandsen wrote:
> Do not attribute to malice that which can be adequately explained by
> ignorance/release pressure/lack of time/blah/blah. So far, every
> Microsoft programmer I've spoken to seemed to try hard. (I'm not saying
> they succeed, but I _am_ saying they don't seem a malicious bunch.)

I agree with Arnt on all three of the above points.

> We're talking about a set of interrelated documents that are light on
> examples and free of a test suite. I'm not greatly surprised that
> people have trouble implementing them correctly.

We have seen this happen over and over again.  The documents are broken.

If Microsoft programmers don't care about specs and redefine them as they
see fit, then we can say the same thing about the programmers of almost
every other SASL server.

This is an *extremely* common blunder.

-- Mark --

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

Date: Mon, 27 Oct 2003 09:13:29 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Keith Moore <[email-masked]>
cc: Dave Crocker <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

On Mon, 27 Oct 2003, Keith Moore wrote:
> what problem are we trying to solve here?

I agree with Keith.  This isn't to say that I dispute that there is a
problem to be solved -- indeed, I think that the problem is apparent to
all -- but we must have a problem statement that we all agree upon before
we even think about solutions.

I don't think that references to drafts of proposed solutions suffice as a
problem statement.  Leaving aside questions of possible bias (= present a
problem in such a way that this is the obvious best solution), having the
problem statement in a draft (which by its nature is an ephemeral
document) muddies the issues.

The problem statement should consist of a single paragraph (and preferably
in one or two sentences), separate from any proposed solution, and stated
in a charter which is approved by everyone.

Here's a start at such a statement:

As presently constituted, email addresses are limited to the 26 Latin
alphabetics, 10 digits, and a limited number of special characters in the
ASCII character set.  There is a growing need to use additional
characters, specifically Latin characters with diacriticals and non-Latin
characters, in email addresses to better serve the needs of the
multi-national Internet community.  However, the restrictions of ASCII
email addresses have served as a "lingua franca" since everybody can enter
ASCII email addresses, and there is an ongoing need for this as well.  The
problem to be solved is the resolution of these two needs.

-- Mark --

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

From: Arnt Gulbrandsen <[email-masked]>
To: Ken Murchison <[email-masked]>
Subject: Re: Exchange server has a broken SASL implementation
Cc: IMAP Interest List <[email-masked]>, Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Mon, 27 Oct 2003 18:14:44 +0100
Sender: [email-masked]

Ken Murchison writes:
> Mark Crispin wrote:
>> Yet more proof that the SASL specifications as currently constituted 
>> are too complex, and why IMAP should not add initial-response until 
>> the SASL specifications are fixed.
>
> Or its more proof that M$ doesn't care about specs and choose to 
> [re]define then as they see fit.

Do not attribute to malice that which can be adequately explained by 
ignorance/release pressure/lack of time/blah/blah. So far, every 
Microsoft programmer I've spoken to seemed to try hard. (I'm not saying 
they succeed, but I _am_ saying they don't seem a malicious bunch.)

We're talking about a set of interrelated documents that are light on 
examples and free of a test suite. I'm not greatly surprised that 
people have trouble implementing them correctly.

(Larry: if there were a test suite for SMTP/SASL, would Microsoft have 
used it?)

--Arnt

Date: Mon, 27 Oct 2003 12:00:01 -0500
From: Marc Blanchet <[email-masked]>
To: Keith Moore <[email-masked]>, Dave Crocker <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

-- Monday, October 27, 2003 10:52:22 -0500 Keith Moore <[email-masked]>
wrote/a ecrit:

>> PF>    What are the next steps for the IETF?
>> 
>> Would it help to have a draft charter for the meeting?  
> 
> let's back up a step further.
> 
> what problem are we trying to solve here?

to me, that (problem we are trying to solve) would be part of the
introduction in the charter...

so I guess some initial proposal for:
- what are we trying to solve
- what would be the way to solve it

would be a good starting point together with the "state-of-the-art"
presentations.

Marc.

> 
> Keith

------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------

Date: Mon, 27 Oct 2003 10:37:21 -0600
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Cc: Dave Crocker <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On 10/27/03 at 10:52 AM -0500, Keith Moore wrote:

>>DC: Would it help to have a draft charter for the meeting?

As was mentioned in the draft agenda at 
<http://www.ietf.org/ietf/03nov/iea.txt>, we want to simply start the 
discussion, not immediately attempt to charter a working group.

>let's back up a step further.
>
>what problem are we trying to solve here?

Please have a look at draft-hoffman-imaa, 
draft-klensin-emailaddr-i18n, and draft-duerst-iri. Certainly the 
first two have very explicit descriptions of the problem.

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

Date: Mon, 27 Oct 2003 11:14:33 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Mark Crispin <[email-masked]>
CC: IMAP Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Exchange server has a broken SASL implementation
Sender: [email-masked]

Mark Crispin wrote:
> It looks like Microsoft finally implemented support for the GSSAPI SASL
> mechanism.
> 
> Unfortunately, they screwed it up.  In their SMTP server, they respond to
> the command "AUTH GSSAPI" with "334 gssapi supported".
> 
> Yet more proof that the SASL specifications as currently constituted are
> too complex, and why IMAP should not add initial-response until the SASL
> specifications are fixed.

Or its more proof that M$ doesn't care about specs and choose to 
[re]define then as they see fit.

Can you show me where the SASL specs or SMTP SASL profile gives them 
license to put garbage in the challenge?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 27 Oct 2003 10:52:22 -0500
From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

> PF>    What are the next steps for the IETF?
> 
> Would it help to have a draft charter for the meeting?  

let's back up a step further.

what problem are we trying to solve here?

Keith

Date: Mon, 27 Oct 2003 07:41:11 -0800
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: =?ISO-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?= <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, Pete Resnick <[email-masked]>, Ted Hardie <[email-masked]>, Ned Freed <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Patrik,

Thanks for putting this BOF together.

PF>       Where should the IETF tackle it?

I am not sure I understand this question.  Please clarify.

PF>    What are the next steps for the IETF?

Would it help to have a draft charter for the meeting?  (I realize that the
presence of such different specifications makes a charter at least a bit
challenging, but it seems to help to have a draft, to make things concrete.)

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

Date: Mon, 27 Oct 2003 07:35:22 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: IMAP Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Exchange server has a broken SASL implementation
Sender: [email-masked]

It looks like Microsoft finally implemented support for the GSSAPI SASL
mechanism.

Unfortunately, they screwed it up.  In their SMTP server, they respond to
the command "AUTH GSSAPI" with "334 gssapi supported".

Yet more proof that the SASL specifications as currently constituted are
too complex, and why IMAP should not add initial-response until the SASL
specifications are fixed.

-- 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]>, Ted Hardie <[email-masked]>, Ned Freed <[email-masked]>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Subject: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Sun, 26 Oct 2003 20:55:08 +0100
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At the IETF in Minneapolis, there will be a BOF on Internationalized 
Email Addresses (IEA).

It is *preliminary* on the agenda on Monday, November 10, 2003 at 
1530-1730.

Chairs:  Pete Resnick, Patrik F�ltstr�m
Mailing list:[email-masked] (other salient lists include [email-masked])
Agenda:

Agenda Bashing (Chairs)                5 min.
Topic Introduction (Chairs)           10 min.
Proposals
   IDNA-Based (Paul Hoffman)           15 min.
   Infrastructure-Based (John Klensin) 15 min.
   IRI-Based (Michel Suignard)         15 min.

Discussion                            60 min.

Topics for discussion:

   Are there other solutions which have been specified?

   The solutions present the problem at different scopes;

      Where should the IETF tackle it?

      Are some short-term, and other long-term?

      Can the solutions be staged or co-exist?

      If staged, how to migrate from one to another?

   What are the next steps for the IETF?

NB:  This BoF is exploratory in nature, and it is not intended that the 
IETF will finalize a decision in this venue.  It was proposed to foster 
a community discussion, not charter a working group or pick a winner. 
If further work is required, step one would be identifying individuals 
willing to carry that work forward.

Reading material:
   draft-hoffman-imaa-03.txt
   draft-klensin-emailaddr-i18n-01.txt
   draft-duerst-iri-04.txt

Pete and myself hope people will come with a lot of constructive 
comments and ideas.

         Patrik, co-chair of the bof

Date: Wed, 22 Oct 2003 12:24:05 -0400
From: Cyrus Daboo <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt
Sender: [email-masked]

Hi Rob,

--On Wednesday, October 22, 2003 12:14 -0400 Rob Siemborski 
<[email-masked]> wrote:

| I did just notice (in the GETANNOTATION text):
|
|     This command is only available in authenticated state [IMAP4].
|
| Shouldn't it also be available in the selected state?  AFAIK, they aren't
| the same.

OK - fixed in working copy.

-- 
Cyrus Daboo

Date: Wed, 22 Oct 2003 12:14:07 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt
Sender: [email-masked]

On Wed, 22 Oct 2003, Cyrus Daboo wrote:

> | I tend to agree that punting seems to be the safest option.
>
> Would you want to restrict GETANNOTATION in the same way?

Not offhand, GETANNOTATION can safely suffer partial failures,
e.g.:

* ANNOTATION
* ANNOTATION
x NO Couldn't contact some backend servers

I did just notice (in the GETANNOTATION text):

    This command is only available in authenticated state [IMAP4].

Shouldn't it also be available in the selected state?  AFAIK, they aren't
the same.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Wed, 22 Oct 2003 12:10:23 -0400
From: Cyrus Daboo <[email-masked]>
To: Rob Siemborski <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt
Sender: [email-masked]

Hi Rob,

--On Wednesday, October 22, 2003 12:05 -0400 Rob Siemborski 
<[email-masked]> wrote:

| On Wed, 22 Oct 2003, Arnt Gulbrandsen wrote:
|
|> Cyrus Daboo writes:
|> > There could be client applications that require an all-or-nothing
|> > change. That said having partial failure (or success) responses would
|> > be OK too. Either that or we punt the whole question by disallowing
|> > multi-mailbox operations in the first place.
|>
|> Punting seems like a good idea. If necessary, add language mentioning
|> that clients can send several store commands at the same time. (That
|> should be possible, as I remember the draft... right?)
|
| I tend to agree that punting seems to be the safest option.

Would you want to restrict GETANNOTATION in the same way?

-- 
Cyrus Daboo

Date: Wed, 22 Oct 2003 12:05:02 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt
Sender: [email-masked]

On Wed, 22 Oct 2003, Arnt Gulbrandsen wrote:

> Cyrus Daboo writes:
> > There could be client applications that require an all-or-nothing
> > change. That said having partial failure (or success) responses would
> > be OK too. Either that or we punt the whole question by disallowing
> > multi-mailbox operations in the first place.
>
> Punting seems like a good idea. If necessary, add language mentioning
> that clients can send several store commands at the same time. (That
> should be possible, as I remember the draft... right?)

I tend to agree that punting seems to be the safest option.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

From: Arnt Gulbrandsen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt
Cc: Rob Siemborski <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Date: Wed, 22 Oct 2003 17:19:37 +0200
Sender: [email-masked]

Cyrus Daboo writes:
> There could be client applications that require an all-or-nothing 
> change. That said having partial failure (or success) responses would 
> be OK too. Either that or we punt the whole question by disallowing 
> multi-mailbox operations in the first place.

Punting seems like a good idea. If necessary, add language mentioning 
that clients can send several store commands at the same time. (That 
should be possible, as I remember the draft... right?)

--Arnt

Date: Wed, 22 Oct 2003 10:40:34 -0400
From: Cyrus Daboo <[email-masked]>
To: Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt
Sender: [email-masked]

Hi Rob,

--On Wednesday, October 22, 2003 10:10 -0400 Rob Siemborski 
<[email-masked]> wrote:

|> >    If the server is unable to store the annotations for one or more
|> >    mailboxes matching the mailbox-name pattern, then the SETANNOTATION
|> >    command MUST fail and there MUST NOT be any changes to any of the
|> >    matching mailboxes, even those for which annotations could have been
|> >    changed successfully.
|>
|> So you want to limit ANNOTATEMORE to work only with servers using
|> transactional databases?
|
| This worries me, as it is a pretty severe implementation burden on IMAP
| proxies as well.
|
|> Maybe SETANNOTATION could rather just send untagged replies for
|> mailboxes it changes?
|
| Or perhaps untagged NO responses for those annotations it couldn't change.

There could be client applications that require an all-or-nothing change. 
That said having partial failure (or success) responses would be OK too. 
Either that or we punt the whole question by disallowing multi-mailbox 
operations in the first place.

-- 
Cyrus Daboo

Date: Wed, 22 Oct 2003 10:10:56 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt
Sender: [email-masked]

On Wed, 22 Oct 2003, Timo Sirainen wrote:

> >    If the server is unable to store the annotations for one or more
> >    mailboxes matching the mailbox-name pattern, then the SETANNOTATION
> >    command MUST fail and there MUST NOT be any changes to any of the
> >    matching mailboxes, even those for which annotations could have been
> >    changed successfully.
>
> So you want to limit ANNOTATEMORE to work only with servers using
> transactional databases?

This worries me, as it is a pretty severe implementation burden on IMAP
proxies as well.

> Maybe SETANNOTATION could rather just send untagged replies for
> mailboxes it changes?

Or perhaps untagged NO responses for those annotations it couldn't change.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Date: Wed, 22 Oct 2003 07:57:12 +0300
Sender: [email-masked]

>    If the server is unable to store the annotations for one or more
>    mailboxes matching the mailbox-name pattern, then the SETANNOTATION
>    command MUST fail and there MUST NOT be any changes to any of the
>    matching mailboxes, even those for which annotations could have been
>    changed successfully.

So you want to limit ANNOTATEMORE to work only with servers using
transactional databases?

Maybe SETANNOTATION could rather just send untagged replies for
mailboxes it changes?

To: IETF-Announce: ;
From: [email-masked]
Reply-to: [email-masked]
Date: Tue, 21 Oct 2003 15:58:32 -0400
Subject: I-D ACTION:draft-daboo-imap-annotatemore-04.txt
Sender: [email-masked]

--==========1DDCBDEFA700D5D5269E==========
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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

	Title		: IMAP ANNOTATEMORE Extension
	Author(s)	: C. Daboo
	Filename	: draft-daboo-imap-annotatemore-04.txt
	Pages		: 17
	Date		: 2003-10-21
	
The ANNOTATEMORE extension to the Internet Message Access Protocol
[IMAP4] permits clients and servers to maintain 'metadata' on IMAP4
servers.  It is possible to store data on a per-mailbox basis or on
the server as a whole.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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
	"get draft-daboo-imap-annotatemore-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-daboo-imap-annotatemore-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--==========1DDCBDEFA700D5D5269E==========
Content-Type: multipart/alternative;
 boundary="==========12F7B0FC35D353082042=========="

--==========12F7B0FC35D353082042==========
Content-Type: message/external-body; ACCESS-TYPE=mail-server;
 SERVER="[email-masked]"
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-daboo-imap-annotatemore-04.txt

--==========12F7B0FC35D353082042==========
Content-Type: message/external-body;
 name="draft-daboo-imap-annotatemore-04.txt"; SITE="ftp.ietf.org";
 ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID:	<[email-masked]>

--==========12F7B0FC35D353082042==========--

--==========1DDCBDEFA700D5D5269E==========--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-08.txt
Date: Tue, 21 Oct 2003 16:01:09 -0400
Sender: [email-masked]

--NextPart

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		: IMAP ANNOTATE Extension
	Author(s)	: R. Gellens, C. Daboo
	Filename	: draft-ietf-imapext-annotate-08.txt
	Pages		: 22
	Date		: 2003-10-21
	
The ANNOTATE extension to the Internet Message Access Protocol
[IMAP4] permits clients and servers to maintain 'metadata' for
messages stored in an IMAP4 mailbox.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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
	"get draft-ietf-imapext-annotate-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-annotate-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-annotate-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-annotate-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 20 Oct 2003 17:08:32 -0500
To: Lemonade <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: IMAP COMPOSE extension
Sender: [email-masked]

[Bcc'ed to IMAPEXT; please followup to LEMONADE]

I didn't have time last week to finish an I-D before the deadline, 
but I figured I should at least start the conversation on the list 
before Minneapolis.

When talking about IMAP Push vs. IMAP Pull for "forward without 
download" in Vienna, a lot of us thought that in either case, it 
would be handy to have an an IMAP COMPOSE command. The idea here 
would be COMPOSE would be pretty much like APPEND (with the mailbox 
in which to append, an optional flag list and optional date/time 
string), except that instead of a message literal, it would take as 
parameters any number of literals and "message part identifiers". All 
of the literals and the message parts would be appended together in 
the destination mailbox as one big message. The client would be 
responsible for providing the appropriate MIME boundaries in the 
literals.

Having a composed message on the IMAP server would work for either 
IMAP push or IMAP pull, and this would obviously be useful for more 
than just "forward without download".

However, I still have some issues with the exact nature of this 
command. Specifically, my big question is how to deal with the 
"message part identifiers". A message part identifier would clearly 
include a sequence number or UID followed by message data item names 
or a macro, just like FETCH. However, the downside to making it look 
exactly like the FETCH parameters is that you can only compose a 
message made up of parts that are contained in the currently selected 
mailbox. Maybe that is sufficient given the application for which 
LEMONADE wants this, but it's clearly a limitation.

The other choice is that the message part identifier would also 
include a mailbox name. We could come up with some syntax for that or 
just use a relative IMAP URL. Of course, the upside is that you'd be 
able to collect together messages in different parts of the IMAP 
store. But there are a couple of really big downsides:

1. It breaks the assumption that you only ever have one mailbox 
selected. In effect, you'd be required on the server to access 
multiple mailboxes in the course of a single command execution. Maybe 
that's OK to require for this extension; maybe not.

2. If it is allowed to be other than a relative URL to *this* IMAP 
server, suddenly you get into the business of doing all of the IMAP 
client work that folks were so worried about when this discussion 
started.

3. Allowing it to be a URL might start us down the slippery slope of 
allowing *any* kind of URL, not just IMAP. The results of that are 
left as an exercise to the reader.

Having the more general syntax (i.e., something that includes the 
mailbox) might be nice for folks who want to do fancier things in the 
future. We could allow any server to say "NO" if given something with 
another mailbox (or server, or scheme). Or maybe we don't want to do 
this at all.

Feedback desired. I'll float a straw-man proposal to the list (which 
obviously won't make it as an I-D for Minneapolis) as soon as I can.

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

From: "Madan Ganesh Velayudham" <[email-masked]>
To: "'Lyndon Nerenberg'" <[email-masked]>
Cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
Date: Sat, 18 Oct 2003 15:34:13 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Lyndon Nerenberg
> Sent: Saturday, October 18, 2003 12:41 AM
> To: Madan Ganesh Velayudham
> Cc: 'IMAP Extensions WG'
> Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
> 
> 
> 
> > 	I understand them clearly. My belif is that my solution
> > 	would have some performance benefits compared having them
> > 	externally.
> 
> Then do the math and prove it.

	Definitely.
> 
> > 	I will try to find some loop holes in sieve for	arugments :-)
> 
> Please stop wasting our time. We do engineering here. 
> Marketing is down 
> the hall.
	
	That was just a comment. Pls donot take it seriously.
> 
> --lyndon
> 

Date: Fri, 17 Oct 2003 13:10:51 -0600
From: Lyndon Nerenberg <[email-masked]>
To: Madan Ganesh Velayudham <[email-masked]>
cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
Sender: [email-masked]

--==========10C64BD7E4C20F34569B==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

> 	I understand them clearly. My belif is that my solution
> 	would have some performance benefits compared having them
> 	externally.

Then do the math and prove it.

> 	I will try to find some loop holes in sieve for	arugments :-)

Please stop wasting our time. We do engineering here. Marketing is down=20
the hall.

--lyndon
--==========10C64BD7E4C20F34569B==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==========10C64BD7E4C20F34569B==========--

Date: Fri, 17 Oct 2003 09:19:02 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Madan Ganesh Velayudham <[email-masked]>
cc: "'Mark Crispin'" <[email-masked]>, "'IMAP Extensions WG'" <[email-masked]>
Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
Sender: [email-masked]

On Fri, 17 Oct 2003, Madan Ganesh Velayudham wrote:

> 	Thanks for your recommendations. Could you please get
> 	me the wg that analyzes sieve.

There is currently no working group, however there are a bunch of people
who read the [email-masked] list.

http://www.imc.org/ietf-mta-filters/index.html

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

From: Arnt Gulbrandsen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: SASL Initial Response?
Cc: Ken Murchison <[email-masked]>, Rob Siemborski <[email-masked]>, Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Fri, 17 Oct 2003 14:51:16 +0200
Sender: [email-masked]

Cyrus Daboo writes:
> A summary of the profiles and mechanisms - not a full detailed 
> description of each. This could be as simple as a table listing which 
> options a particular protocol's profile provides. e.g.:

That table belongs on www.iana.org, doesn't it? Like the (hopelessly 
outdated) IMAP extensions page.

> | b) a document that points out common errors in SASL implementations
>
> Yes..

Like 2683? Good idea, but I can't even comment on it, far less suggest 
appropriate content.

--Arnt

From: "Madan Ganesh Velayudham" <[email-masked]>
To: "'Mark Crispin'" <[email-masked]>
Cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
Date: Fri, 17 Oct 2003 17:33:26 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

> 
> Capabilities are defined in RFC 3501 as atoms.  You can not 
> have multi-atom capabilities.  This is an ongoing design 
> issue which other capabilities have had to face (and has had 
> considerable discussion) but as yet there is no clear solution.
> 

	Thanks for the explanation.

> I need to reiterate that sieve already has this 
> functionality, and quite a bit more.  You should be looking 
> into sieve rather than trying to shoehorn an orthogonal (and 
> much less functional) capability into IMAP.

	Hmm.. That was an effort to embedd the logic in IMAP.
	I will analyze further on this.

> 
> In most environments, filters are done in the MTA and/or MDA, 
> especially when a filter is a defined set of rules which are 
> executed for all incoming mail.  Filters are generally not 
> done in the MUA (such as an IMAP
> server) because of the problem of executing a filter 
> repetitively on the same data; when it is done the MUA often 
> has to undertake heroic (and sometimes unsuccessful) efforts 
> to avoid this problem.
> 
> In most environments, IMAP servers are completely separate 
> from the MTA and MDA.  There would be a substantial 
> implementation burden to create an intercommunication of 
> filtering information between the IMAP server and a separate 
> MTA/MDA (perhaps from a different vendor).
> 
> It is not likely that you will have much success convincing 
> either IMAP or MTA/MDA server implementors to implement your 
> extension, especially since sieve already addresses these 
> needs and quite a bit more.
> 
> In general, IETF protocols avoid having multiple solutions 
> for the same problem.  When multiple solutions exist, there 
> is strong pressure to have one solution win and the others 

	I understand them clearly. My belif is that my solution
	would have some performance benefits compared having them
	externally. 

	I will try to find some loop holes in sieve for	arugments :-)

> pass into oblivion.  For many years, there was such pressure 
> between IMAP and POP since these two protocols seemingly did 
> the same thing.  And, to be honest, it is likely that IMAP 
> would not have happened had I known about POP.

	I like this point very much :-)

> 
> I strongly urge you to look into sieve, and become involved 
> in that development effort.  You will find many helpful 
> people working on sieve, and you'll achieve your goals much 
> faster.  Otherwise, you are likely to end up having wasted 
> your time (and other people's time) with no results to show for it.

	Thanks for your recommendations. Could you please get
	me the wg that analyzes sieve.

	+MG

> -----Original Message-----
> From: Mark Crispin [mailto:[email-masked]] 
> Sent: Friday, October 17, 2003 12:35 AM
> To: Madan Ganesh Velayudham
> Cc: 'IMAP Extensions WG'; [email-masked]
> Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
> 
> 
> On Fri, 17 Oct 2003, Madan Ganesh Velayudham wrote:
> > 	* CAPABILITY IMAP4rev1 AUTH=DIGEST-MD5ORGANIZE=ADD,UPDATE
> > 	[APPEND,DELETE,STORE],REMOVE,ENABLE,DISABLE,LIST
> >
> > 	I understand [APPEND, ... ] is the one which you are
> > 	mentioning. Pls correct me if I'm wrong. I shall correct it
> > 	while refining the draft.
> 
> Capabilities are defined in RFC 3501 as atoms.  You can not 
> have multi-atom capabilities.  This is an ongoing design 
> issue which other capabilities have had to face (and has had 
> considerable discussion) but as yet there is no clear solution.
> 
> > > As such, this functionality does not seem to be within 
> the scope of 
> > > IMAP; and instead belongs with Sieve.
> > 	+ Client need nt do extra operations.
> >
> > 	+ I'm trying to leverage already available IMAP commands
> > 	( APPEND, STORE, Search Criterias, etc., ) to implement
> > 	this organization of message for user. I feel there wont be
> > 	much implementation strain : code reusability.
> >
> > 	+ Many customers would be interested in single entity which
> > 	will do the required tasks instead of having two independent
> > 	entities.
> 
> I need to reiterate that sieve already has this 
> functionality, and quite a bit more.  You should be looking 
> into sieve rather than trying to shoehorn an orthogonal (and 
> much less functional) capability into IMAP.
> 
> In most environments, filters are done in the MTA and/or MDA, 
> especially when a filter is a defined set of rules which are 
> executed for all incoming mail.  Filters are generally not 
> done in the MUA (such as an IMAP
> server) because of the problem of executing a filter 
> repetitively on the same data; when it is done the MUA often 
> has to undertake heroic (and sometimes unsuccessful) efforts 
> to avoid this problem.
> 
> In most environments, IMAP servers are completely separate 
> from the MTA and MDA.  There would be a substantial 
> implementation burden to create an intercommunication of 
> filtering information between the IMAP server and a separate 
> MTA/MDA (perhaps from a different vendor).
> 
> It is not likely that you will have much success convincing 
> either IMAP or MTA/MDA server implementors to implement your 
> extension, especially since sieve already addresses these 
> needs and quite a bit more.
> 
> In general, IETF protocols avoid having multiple solutions 
> for the same problem.  When multiple solutions exist, there 
> is strong pressure to have one solution win and the others 
> pass into oblivion.  For many years, there was such pressure 
> between IMAP and POP since these two protocols seemingly did 
> the same thing.  And, to be honest, it is likely that IMAP 
> would not have happened had I known about POP.
> 
> I strongly urge you to look into sieve, and become involved 
> in that development effort.  You will find many helpful 
> people working on sieve, and you'll achieve your goals much 
> faster.  Otherwise, you are likely to end up having wasted 
> your time (and other people's time) with no results to show for it.
> 
> -- Mark --
> 
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Thu, 16 Oct 2003 15:24:43 -0600
From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: IMAP Organize Extension
Sender: [email-masked]

--==========C47C3D6041106DB99DBE==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The functionality of Organize already exists in SIEVE.

Pushing the configuration of MDA filters into multiple unrelated=20
protocols is just bad engineering.

Also, this document falsely claims to be a product of the WG, which it is =

not. It's not even within the scope of the WG charter.

This draft should be withdrawn immediately. We should instead focus on=20
getting ManageSieve onto the standards track.

--lyndon
--==========C47C3D6041106DB99DBE==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==========C47C3D6041106DB99DBE==========--

Date: Thu, 16 Oct 2003 16:23:55 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Madan Ganesh Velayudham <[email-masked]>
cc: "'Mark Crispin'" <[email-masked]>, "'IMAP Extensions WG'" <[email-masked]>, [email-masked]
Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
Sender: [email-masked]

On Fri, 17 Oct 2003, Madan Ganesh Velayudham wrote:

> > In fact, it seems to me that sieve is more flexible than this
> > extension ever could be, since it is embeddable without
> > protocol changes in any mail handling program (IMAP server,
> > LMTP/SMTP server, POP client, etc).
> >
> 	+ Many customers would be interested in single entity which
> 	will do the required tasks instead of having two independent
> 	entities.

What users may perceive as a single entity does not need to be a single
protocol on the wire.  In fact, a single server product can support
multiple protocols and provide this functionality and the administrators
can still see it as a single product.

For example, Cyrus implements mail filtering with Sieve scripts that can
be manage remotely without touching the IMAP protocol at all.  Users can
have a mail client that supports both IMAP and MANAGESIEVE and have it
maintain their filters *and* read their mail.  The client can even support
Sieve itself and provide a GUI to manipulate the filters.

This doesn't require an extension to IMAP, and Sieve is already more
flexible than the much more limited set of IMAP operations (In addition to
simple file/reject/discard type actions, there are currently extensions
for vacation messages, spam/virus scoring, regular expressions, relational
comparisons and so on).

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Thu, 16 Oct 2003 15:38:55 -0400
From: Tony Hansen <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

Alexey Melnikov wrote:
> As I am the guilty party I should probably comment on this. It is quite 
> common for base64 encoding/decoding to be implemented by utility 
> functions that you steal from your friend or just implemented in a 
> library written by somebody-who-no-longer-works-for-the-company ten 
> years ago. These functions may have assumptions quite different from 
> those of IMAP AUTHENTICATE, because they could have been written for a 
> different environment. For example they were originally used to handle 
> MIME base64, which allows for spaces and CRLFs.

Ditto. I was using a base64 library and it worked great, until I had a string 
that caused the base64 output to be >76 characters and it inserted a crlf.

Sigh.

	Tony Hansen
	[email-masked]

Date: Thu, 16 Oct 2003 12:04:51 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Madan Ganesh Velayudham <[email-masked]>
cc: "'IMAP Extensions WG'" <[email-masked]>, [email-masked]
Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
Sender: [email-masked]

On Fri, 17 Oct 2003, Madan Ganesh Velayudham wrote:
> 	* CAPABILITY IMAP4rev1 AUTH=DIGEST-MD5ORGANIZE=ADD,UPDATE
> 	[APPEND,DELETE,STORE],REMOVE,ENABLE,DISABLE,LIST
>
> 	I understand [APPEND, ... ] is the one which you are
> 	mentioning. Pls correct me if I'm wrong. I shall correct it
> 	while refining the draft.

Capabilities are defined in RFC 3501 as atoms.  You can not have
multi-atom capabilities.  This is an ongoing design issue which other
capabilities have had to face (and has had considerable discussion) but as
yet there is no clear solution.

> > As such, this functionality does not seem to be within the
> > scope of IMAP; and instead belongs with Sieve.
> 	+ Client need nt do extra operations.
>
> 	+ I'm trying to leverage already available IMAP commands
> 	( APPEND, STORE, Search Criterias, etc., ) to implement
> 	this organization of message for user. I feel there wont be
> 	much implementation strain : code reusability.
>
> 	+ Many customers would be interested in single entity which
> 	will do the required tasks instead of having two independent
> 	entities.

I need to reiterate that sieve already has this functionality, and quite a
bit more.  You should be looking into sieve rather than trying to shoehorn
an orthogonal (and much less functional) capability into IMAP.

In most environments, filters are done in the MTA and/or MDA, especially
when a filter is a defined set of rules which are executed for all
incoming mail.  Filters are generally not done in the MUA (such as an IMAP
server) because of the problem of executing a filter repetitively on the
same data; when it is done the MUA often has to undertake heroic (and
sometimes unsuccessful) efforts to avoid this problem.

In most environments, IMAP servers are completely separate from the MTA
and MDA.  There would be a substantial implementation burden to create an
intercommunication of filtering information between the IMAP server and a
separate MTA/MDA (perhaps from a different vendor).

It is not likely that you will have much success convincing either IMAP or
MTA/MDA server implementors to implement your extension, especially since
sieve already addresses these needs and quite a bit more.

In general, IETF protocols avoid having multiple solutions for the same
problem.  When multiple solutions exist, there is strong pressure to have
one solution win and the others pass into oblivion.  For many years, there
was such pressure between IMAP and POP since these two protocols seemingly
did the same thing.  And, to be honest, it is likely that IMAP would not
have happened had I known about POP.

I strongly urge you to look into sieve, and become involved in that
development effort.  You will find many helpful people working on sieve,
and you'll achieve your goals much faster.  Otherwise, you are likely to
end up having wasted your time (and other people's time) with no results
to show for it.

-- Mark --

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

From: "Madan Ganesh Velayudham" <[email-masked]>
To: "'Rob Siemborski'" <[email-masked]>, "'Mark Crispin'" <[email-masked]>
Cc: "'IMAP Extensions WG'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
Date: Fri, 17 Oct 2003 00:34:07 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

Hi Rob,

	Thanks for your comments.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rob Siemborski
> Sent: Thursday, October 16, 2003 2:21 AM
> To: Mark Crispin
> Cc: IMAP Extensions WG; [email-masked]
> Subject: Re: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
> 
> 
> 
> On Wed, 15 Oct 2003, Mark Crispin wrote:
> 
> > As such, this functionality does not seem to be within the scope of 
> > IMAP; and instead belongs with Sieve.  Not withstanding the 
> attractive 
> > nuisance of rendering IMAP into Exchange ("shove everything 
> remotely 
> > related to email into one protocol"), I don't see how ORGANIZE 
> > provides any added value over Sieve.
> 
> I agree with Mark's comments.  I don't see any win here over 
> sieve, except that the client can avoid making the additional 
> MANAGESIEVE connection to update its filtering rules, which 
> is not compelling enough to try to reimplement all of Sieve's 
> functionality inside of the IMAP protocol.

	As I mentioned in Mark's reply, I'm trying to leverage 
	existing IMAP commands feature to orgainze user mails.

> 
> (Which reminds me -- MANAGESIEVE has yet to be published as 
> an RFC, I should probably bother Tim again).

	I've just went through the abstract of it and understand that
	managing sieve script remotely.

> 
> In fact, it seems to me that sieve is more flexible than this 
> extension ever could be, since it is embeddable without 
> protocol changes in any mail handling program (IMAP server, 
> LMTP/SMTP server, POP client, etc).
> 
	+ Many customers would be interested in single entity which
	will do the required tasks instead of having two independent
	entities.

	Please let me know your comments.

	Thanks again,
	MG

> -Rob
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Rob Siemborski | Andrew Systems Group * Research Systems 
> Programmer PGP:0x5CE32FCC | Cyert Hall 207 * 
> [email-masked] * 412.268.7456 -----BEGIN GEEK CODE BLOCK----
> Version: 3.12
> GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ 
> N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ 
> DI+++ G e h r- y? ------END GEEK CODE BLOCK-----
> 
> 

From: "Madan Ganesh Velayudham" <[email-masked]>
To: "'Mark Crispin'" <[email-masked]>, "'IMAP Extensions WG'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
Date: Fri, 17 Oct 2003 00:06:53 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

Hi Mark,

	Thanks for your comments.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mark Crispin
> Sent: Thursday, October 16, 2003 1:41 AM
> To: IMAP Extensions WG
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
> 
> 
> 
> Leaving aside the bugs in this specification (for example, 
> the added capabilities violate RFC 3501, security 
> considerations are glossed over), it seems that the purpose 
> of this proposed extension is not to "organize", but rather 
> to define MDA filtering rules.

	* CAPABILITY IMAP4rev1 AUTH=DIGEST-MD5ORGANIZE=ADD,UPDATE 
	[APPEND,DELETE,STORE],REMOVE,ENABLE,DISABLE,LIST

	I understand [APPEND, ... ] is the one which you are 
	mentioning. Pls correct me if I'm wrong. I shall correct it 
	while refining the draft.

	Since the ORGANIZE command is in autenticated state, 
	only users with proper credentials can have access to
	PUOT.

	I will definitely elaborate 3.2 Section ... 
	[ When the IMAP server receives... It performs the specified 
	action.. ] to include more implementation issues. How IMAP 
	could behave for append, delete, store operations. In future,
	I would like expand these operations to include forwarding 
	messages, automatic response for messages, etc. I could 
	understand that the much emphasis is on define organizing 
	(filtering)	rules. I understand I should elaborate it.

> 
> As such, this functionality does not seem to be within the 
> scope of IMAP; and instead belongs with Sieve.  Not 
> withstanding the attractive nuisance of rendering IMAP into 
> Exchange ("shove everything remotely related to email into 
> one protocol"), I don't see how ORGANIZE provides any added 
> value over Sieve.

	+ Client need nt do extra operations.

	+ I'm trying to leverage already available IMAP commands
	( APPEND, STORE, Search Criterias, etc., ) to implement 
	this organization of message for user. I feel there wont be
	much implementation strain : code reusability.

	+ Many customers would be interested in single entity which
	will do the required tasks instead of having two independent
	entities.

> 
> The proposed SMTP extension for ORGANIZE is bizarre.  The 
> purpose seems to be to shoehorn manipulation of MDA filtering 
> rules into yet another orthogonal protocol (plus note the 
> syntax errors in the example).  The SMTP extensions people 
> can shoot that down.
> 

	I understand it and will definitely correct any errors.
Actually,
	the idea that I came to me, just thought capture them in the
draft
	merely I don't want to extent this part. This is just an idea.

	Thanks again,
	MG

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

Date: Thu, 16 Oct 2003 19:06:40 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Rob Siemborski <[email-masked]>, Cyrus Daboo <[email-masked]>, Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

Mark Crispin wrote:

>Another damning point.  Just recently, it was claimed that RFC 3501 does
>not enforce BASE64 syntax in the AUTHENTICATE command.  The Formal Syntax
>says otherwise; but that was countered with "nobody reads the formal
>syntax."  Or, as in the case with Courier server, the formal syntax is
>openly defied if it does not match how the implementor chooses to
>interpret the main text.
>
As I am the guilty party I should probably comment on this. It is quite 
common for base64 encoding/decoding to be implemented by utility 
functions that you steal from your friend or just implemented in a 
library written by somebody-who-no-longer-works-for-the-company ten 
years ago. These functions may have assumptions quite different from 
those of IMAP AUTHENTICATE, because they could have been written for a 
different environment. For example they were originally used to handle 
MIME base64, which allows for spaces and CRLFs.

(And I am actually talking from my own experience and I've ended up 
discovering certain side effects of a base64 decoder I has borrowed).

So, explicitly emphasizing some problems with existing base64 decoders 
will not hurt.

>Perhaps if we lived in a world in which it was a criminal offense to
>distribute non-compliant protocol implementations, we might see greater
>attention to specifications.  I don't see that happening; if anything I
>see an increasingly lackadasical approach to specifications.
>
>Thus, we need more pedagogical texts, separate from the specifications, if
>we hope to retain any interoperability at all.
>
Exactly.

Alexey

Date: Thu, 16 Oct 2003 10:37:43 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Thu, 16 Oct 2003, Rob Siemborski wrote:
> Do you mean:
> a) a document that includes SASL profiles for all of these protocols
> b) a document that points out common errors in SASL implementations
> c) a document akin to STD 1 that just points at the documents
> that define various SASL profiles.

What I would think would be a "SASL for Dummies"; that is, a document
which gives a "how to" overview of SASL along with real-life examples.

We live in a world full of implementors who do not read specifications.
This isn't just with hacker-wannabees in the open source community;
vendors are hiring such individuals.

There's also a matter of blunder; simply not understanding how seemingly
unrelated statements interact (or, for that matter, the significance of a
seemingly unimportant statement).  As I pointed out before, many POP and
SMTP server SASL implementations fail to handle properly the case when the
client does not provide an initial response for the PLAIN mechanism.

Rob's new set of I-Ds should help a lot.  But it should also tell us that
we can not depend upon specifications, especially syntax of the
specification, to get people to do the right thing.

Another damning point.  Just recently, it was claimed that RFC 3501 does
not enforce BASE64 syntax in the AUTHENTICATE command.  The Formal Syntax
says otherwise; but that was countered with "nobody reads the formal
syntax."  Or, as in the case with Courier server, the formal syntax is
openly defied if it does not match how the implementor chooses to
interpret the main text.

Perhaps if we lived in a world in which it was a criminal offense to
distribute non-compliant protocol implementations, we might see greater
attention to specifications.  I don't see that happening; if anything I
see an increasingly lackadasical approach to specifications.

Thus, we need more pedagogical texts, separate from the specifications, if
we hope to retain any interoperability at all.

-- Mark --

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

Date: Thu, 16 Oct 2003 13:36:17 -0400
From: Cyrus Daboo <[email-masked]>
To: Rob Siemborski <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: Mark Crispin <[email-masked]>, Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

Hi Rob,

--On Thursday, October 16, 2003 13:30 -0400 Rob Siemborski 
<[email-masked]> wrote:

| (c) seems likely to fall out of date.

It would have to be updated on a regular basis to account for new protocols 
and mechanisms, but the document will point to the definitive place to get 
the most up to date information (e.g. IANA for mechanisms).

-- 
Cyrus Daboo

Date: Thu, 16 Oct 2003 13:33:06 -0400
From: Cyrus Daboo <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Mark Crispin <[email-masked]>, Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

Hi Rob,

--On Thursday, October 16, 2003 12:55 -0400 Rob Siemborski 
<[email-masked]> wrote:

| I'm somewhat confused by what you're proposing here Cyrus...
|
| Do you mean:
|
| a) a document that includes SASL profiles for all of these protocols

A summary of the profiles and mechanisms - not a full detailed description 
of each. This could be as simple as a table listing which options a 
particular protocol's profile provides. e.g.:

Protocol        Initial Response        Base64 Encoding  Relevant RFCs
                Supported

IMAP            No                      Yes              3501
ACAP            Yes                     Yes              2244
SMTP            Yes                     Yes              2821, 2554
etc

Mechanism       Initial Response        Supports Security  RFCs
                Allowed                 Layer

CRAM-MD5        No                      No                 2195
DIGEST-MD5      Sometimes (see rfc)     Yes                2831
GSSAPI          Yes                     Yes                2222
etc

| b) a document that points out common errors in SASL implementations

Yes..

| c) a document akin to STD 1 that just points at the documents
| that define various SASL profiles.

The table should list the references.

-- 
Cyrus Daboo

Date: Thu, 16 Oct 2003 13:30:40 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Mark Crispin <[email-masked]>, Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Thu, 16 Oct 2003, Alexey Melnikov wrote:

> >I'm somewhat confused by what you're proposing here Cyrus...
> >
> >Do you mean:
> >
> >a) a document that includes SASL profiles for all of these protocols
> >b) a document that points out common errors in SASL implementations
> >c) a document akin to STD 1 that just points at the documents
> >that define various SASL profiles.
> >
> I think Cyrus was talking about b) with some pieces of c).
>
> After writing HTTP SASL spec and reviewing XMPP/BEEP/SMTP/etc. I am
> willing to invest effort in this.

Ok.  (b) seems worthwhile but I wonder if there is enough there to justify
a document separate from RFC2222bis.

(c) seems likely to fall out of date.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Thu, 16 Oct 2003 18:23:52 +0100
From: Alexey Melnikov <[email-masked]>
To: Rob Siemborski <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, Mark Crispin <[email-masked]>, Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

Rob Siemborski wrote:

>On Thu, 16 Oct 2003, Cyrus Daboo wrote:
>  
>
>>I think what would be handy is to have a single informational RFC, that
>>could be continually updated, that summarizes all the SASL profiles for
>>standard protocols that use it. i.e. the document would describe how IMAP,
>>ACAP, SMTP, POP3, LDAP, BEEP etc all use SASL paying particular attention
>>to implementation differences (the initial response has been shown to be
>>one problem). This document could list the relevant RFCs to read to get the
>>specifics for implementing each profile. i.e. it would be the something
>>akin t the IMAP implementer's guide but for SASL.
>>    
>>
>
>I'm somewhat confused by what you're proposing here Cyrus...
>
>Do you mean:
>
>a) a document that includes SASL profiles for all of these protocols
>b) a document that points out common errors in SASL implementations
>c) a document akin to STD 1 that just points at the documents
>that define various SASL profiles.
>
I think Cyrus was talking about b) with some pieces of c).

After writing HTTP SASL spec and reviewing XMPP/BEEP/SMTP/etc. I am 
willing to invest effort in this.

Alexey

Date: Thu, 16 Oct 2003 12:55:40 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Mark Crispin <[email-masked]>, Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Thu, 16 Oct 2003, Cyrus Daboo wrote:

> I think what would be handy is to have a single informational RFC, that
> could be continually updated, that summarizes all the SASL profiles for
> standard protocols that use it. i.e. the document would describe how IMAP,
> ACAP, SMTP, POP3, LDAP, BEEP etc all use SASL paying particular attention
> to implementation differences (the initial response has been shown to be
> one problem). This document could list the relevant RFCs to read to get the
> specifics for implementing each profile. i.e. it would be the something
> akin t the IMAP implementer's guide but for SASL.

I'm somewhat confused by what you're proposing here Cyrus...

Do you mean:

a) a document that includes SASL profiles for all of these protocols
b) a document that points out common errors in SASL implementations
c) a document akin to STD 1 that just points at the documents
that define various SASL profiles.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Thu, 16 Oct 2003 08:43:12 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Thu, 16 Oct 2003, Cyrus Daboo wrote:
> I think what would be handy is to have a single informational RFC, that
> could be continually updated, that summarizes all the SASL profiles for
> standard protocols that use it. i.e. the document would describe how IMAP,
> ACAP, SMTP, POP3, LDAP, BEEP etc all use SASL paying particular attention
> to implementation differences (the initial response has been shown to be
> one problem). This document could list the relevant RFCs to read to get the
> specifics for implementing each profile. i.e. it would be the something
> akin t the IMAP implementer's guide but for SASL.

This is an excellent idea.

-- Mark --

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

Date: Thu, 16 Oct 2003 11:39:45 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Ken Murchison <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

Hi Mark,

{Coming into this debate late since I've been on vacation...]

--On Tuesday, October 7, 2003 18:33 -0700 Mark Crispin 
<[email-masked]> wrote:

|> At the very least, shouldn't the IMAP initial response doc and revised
|> SMTP AUTH and POP3 AUTH docs be able to proceed in parallel, especially
|> if they all use similar language for the initial client response issue?
|
| The question is if the SMTP and POP3 documents are going to advance or
| not.  This also depends upon the SASL document.  I'd like to hear IESG
| feedback on this.

Clearly implementing SASL across multiple protocols is problematic because 
you have to read multiple documents to fully understand what optional 
features are supported etc.

I think what would be handy is to have a single informational RFC, that 
could be continually updated, that summarizes all the SASL profiles for 
standard protocols that use it. i.e. the document would describe how IMAP, 
ACAP, SMTP, POP3, LDAP, BEEP etc all use SASL paying particular attention 
to implementation differences (the initial response has been shown to be 
one problem). This document could list the relevant RFCs to read to get the 
specifics for implementing each profile. i.e. it would be the something 
akin t the IMAP implementer's guide but for SASL.

-- 
Cyrus Daboo

Date: Wed, 15 Oct 2003 16:50:35 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
Sender: [email-masked]

On Wed, 15 Oct 2003, Mark Crispin wrote:

> As such, this functionality does not seem to be within the scope of IMAP;
> and instead belongs with Sieve.  Not withstanding the attractive nuisance
> of rendering IMAP into Exchange ("shove everything remotely related to
> email into one protocol"), I don't see how ORGANIZE provides any added
> value over Sieve.

I agree with Mark's comments.  I don't see any win here over sieve, except
that the client can avoid making the additional MANAGESIEVE connection to
update its filtering rules, which is not compelling enough to try to
reimplement all of Sieve's functionality inside of the IMAP protocol.

(Which reminds me -- MANAGESIEVE has yet to be published as an RFC, I
should probably bother Tim again).

In fact, it seems to me that sieve is more flexible than this extension
ever could be, since it is embeddable without protocol changes in any mail
handling program (IMAP server, LMTP/SMTP server, POP client, etc).

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Wed, 15 Oct 2003 13:11:21 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt
Sender: [email-masked]

Leaving aside the bugs in this specification (for example, the added
capabilities violate RFC 3501, security considerations are glossed over),
it seems that the purpose of this proposed extension is not to "organize",
but rather to define MDA filtering rules.

As such, this functionality does not seem to be within the scope of IMAP;
and instead belongs with Sieve.  Not withstanding the attractive nuisance
of rendering IMAP into Exchange ("shove everything remotely related to
email into one protocol"), I don't see how ORGANIZE provides any added
value over Sieve.

The proposed SMTP extension for ORGANIZE is bizarre.  The purpose seems to
be to shoehorn manipulation of MDA filtering rules into yet another
orthogonal protocol (plus note the syntax errors in the example).  The
SMTP extensions people can shoot that down.

-- Mark --

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

From: Arnt Gulbrandsen <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Cc: Alexey Melnikov <[email-masked]>, Rob Siemborski <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Date: Wed, 15 Oct 2003 10:43:55 +0200
Sender: [email-masked]

Mark Crispin writes:
> On Tue, 14 Oct 2003, Rob Siemborski wrote:
>>  I have replaced that paragraph with:
>>
>>  When decoding the [BASE64] data in the initial client response, 
>>  decoding errors MUST be treated as [IMAP4] would handle them in any 
>>  normal SASL client response. In particular, the server should check 
>>  for any characters not explicitly allowed by the BASE64 alphabet, 
>>  as well as any sequence of BASE64 characters that contains the pad 
>>  character ('=') anywhere other than the end of the string (e.g. 
>>  "=AAA" and "AAA=BBB" are not allowed).
>
> Excellent. Thanks!

I like it.

--Arnt

Date: Tue, 14 Oct 2003 11:32:54 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, IMAP extensions Mailing List <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 14 Oct 2003, Rob Siemborski wrote:
> I have replaced that paragraph with:
>
> When decoding the [BASE64] data in the initial client response, decoding
> errors MUST be treated as [IMAP4] would handle them in any normal SASL
> client response.  In particular, the server should check for
> any characters not explicitly allowed by the BASE64 alphabet, as well as
> any sequence of BASE64 characters that contains the pad character ('=')
> anywhere other than the end of the string (e.g. "=AAA" and "AAA=BBB" are
> not allowed).

Excellent.  Thanks!

-- Mark --

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

Date: Tue, 14 Oct 2003 14:25:59 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, IMAP extensions Mailing List <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

On Tue, 14 Oct 2003, Mark Crispin wrote:

> > replacing it with something like "When base64 decoding the initial
> > response argument, it MUST be treated as [IMAP4] would treat any
> > other SASL client response.")
>
> It wouldn't hurt to add expository text with something like the original
> wording, just for emphasis.

I have replaced that paragraph with:

When decoding the [BASE64] data in the initial client response, decoding
errors MUST be treated as [IMAP4] would handle them in any normal SASL
client response.  In particular, the server should check for
any characters not explicitly allowed by the BASE64 alphabet, as well as
any sequence of BASE64 characters that contains the pad character ('=')
anywhere other than the end of the string (e.g. "=AAA" and "AAA=BBB" are
not allowed).

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Tue, 14 Oct 2003 11:10:08 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, IMAP extensions Mailing List <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 14 Oct 2003, Rob Siemborski wrote:
> In that case, I am inclined to drop the paragraph from this draft (perhaps
> replacing it with something like "When base64 decoding the initial
> response argument, it MUST be treated as [IMAP4] would treat any
> other SASL client response.")

It wouldn't hurt to add expository text with something like the original
wording, just for emphasis.

-- Mark --

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

Date: Tue, 14 Oct 2003 13:58:17 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, IMAP extensions Mailing List <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

On Tue, 14 Oct 2003, Mark Crispin wrote:

> > > This stuff is over and above the restrictions imposed by RFC 3501
> > > section 6.2.2.
> > Since Alexey was the one who wanted me to add this, I'll ask him to
> > comment here.
>
> I'm not Alexey, but I'll comment anyway.
>
> RFC 3501 fully supports the proposed restrictions in the Formal Syntax.
> Characters that are not in the BASE64 alphabet and non-terminal = are
> specifically prohibited in the formal syntax, violation of which leads to
> a BAD.
>
> Just because something isn't explicitly mentioned in expository text (such
> as 6.2.2) does not mean that it isn't there.

In that case, I am inclined to drop the paragraph from this draft (perhaps
replacing it with something like "When base64 decoding the initial
response argument, it MUST be treated as [IMAP4] would treat any
other SASL client response.")

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Tue, 14 Oct 2003 18:12:12 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Arnt Gulbrandsen <[email-masked]>, Rob Siemborski <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

Mark Crispin wrote:

>On Tue, 14 Oct 2003, Alexey Melnikov wrote:
>  
>
>>>This stuff is over and above the restrictions imposed by RFC 3501
>>>section 6.2.2.
>>>      
>>>
>>Yes. The base IMAP spec should be updated as well.
>>    
>>
>
>As noted in my previous message, this is unnecessary except as an
>explanatory note.  The Formal Syntax is already clear on this point.
>
Yes, but nobody reads ABNF anyway ;-).

You are right, "this is not a bug", but I suggest you add some text, as 
this is a known issue that causes problems already.

Alexey

Date: Tue, 14 Oct 2003 10:00:43 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, Rob Siemborski <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 14 Oct 2003, Alexey Melnikov wrote:
> > This stuff is over and above the restrictions imposed by RFC 3501
> > section 6.2.2.
> Yes. The base IMAP spec should be updated as well.

As noted in my previous message, this is unnecessary except as an
explanatory note.  The Formal Syntax is already clear on this point.

-- Mark --

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

Date: Tue, 14 Oct 2003 09:59:12 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, IMAP extensions Mailing List <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 14 Oct 2003, Rob Siemborski wrote:
> >      If the server cannot decode the [BASE64] data
> >      transmitted by the client, the server MUST fail the authentication
> >      with a tagged BAD response.  In particular, the server MUST reject
> >      (and not ignore) any characters not explicitly allowed by the BASE64
> >      alphabet, and should reject any sequence of BASE64 characters that
> >      contains the pad character ('=') anywhere other than the end of the
> >      string (e.g. "=AAA" and "AAA=BBB" are not allowed).
> > This stuff is over and above the restrictions imposed by RFC 3501
> > section 6.2.2.
> Since Alexey was the one who wanted me to add this, I'll ask him to
> comment here.

I'm not Alexey, but I'll comment anyway.

RFC 3501 fully supports the proposed restrictions in the Formal Syntax.
Characters that are not in the BASE64 alphabet and non-terminal = are
specifically prohibited in the formal syntax, violation of which leads to
a BAD.

Just because something isn't explicitly mentioned in expository text (such
as 6.2.2) does not mean that it isn't there.

-- Mark --

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

Date: Tue, 14 Oct 2003 17:42:12 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: Rob Siemborski <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

Arnt Gulbrandsen wrote:

>     If the server cannot decode the [BASE64] data
>     transmitted by the client, the server MUST fail the authentication
>     with a tagged BAD response.  In particular, the server MUST reject
>     (and not ignore) any characters not explicitly allowed by the BASE64
>     alphabet, and should reject any sequence of BASE64 characters that
>     contains the pad character ('=') anywhere other than the end of the
>     string (e.g. "=AAA" and "AAA=BBB" are not allowed).
>
> This stuff is over and above the restrictions imposed by RFC 3501 
> section 6.2.2.

Yes. The base IMAP spec should be updated as well.

> I don't feel pedantic enough to look up the original base64 RFC and 
> see if there's equivalent text there.

Unfortunately the base64 RFC was published before the issue was raised. 
There are problems in real world that different implementations treat 
invalid (as shown in the text above) base64 text in different ways. Some 
implementations just ignore invalid characters. Others truncate data at 
the first '='. And other reject the value (the right think). base64 is 
silent on this and this causes problems.

> Either there is, and the text is superfluous, or there isn't, and the 
> quoted text is a syntax difference of the kind I don't want.

Cheers,
Alexey
__________________________________________
Isode Limited, http://www.isode.com

Cell: +44 7753759732

IETF standard related pages:
http://orthanc.ab.ca/mel/devel/Links.html

Personal Home Page: http://orthanc.ab.ca/mel
__________________________________________

From: Arnt Gulbrandsen <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Cc: Rob Siemborski <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Date: Tue, 14 Oct 2003 18:32:25 +0200
Sender: [email-masked]

Mark Crispin writes:
> On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote:
>>  With SMTP, the server can know that the client supports initial responses.
>
> Say WHAT?????
>
> Where did you get THAT???

Too tired. I mixed "mandatory for SMTP servers" up with "mandatory in 
SMTP". Sorry.

--Arnt

Date: Tue, 14 Oct 2003 12:28:31 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote:

> Good. They aren't the same as the document stands now. There are 2-3
> extra restrictions, both/all small.
>
>      If the client needs to transmit an
>      initial response which is a zero-length string, it MUST transmit a
>      single equals sign ("=").  This indicates that the response is
>      present, but is a zero-length string.
>
> There's a MUST here, although I'm not sure whether it represents an
> additional requirement over and above RFC 3501.
>
> Let me suggest a rewording. "To send a zero-length initial response, the
> client can send a single pad character ("="). When decoded, this will
> result in a zero-length string on the server." Or perhaps use "AUTH
> EXTERNAL =" as an example. Either way, it's the same meaning, no
> additional restrictions.

I think this needs to be "the client MUST" for interoperability purposes.
But I am willing to rework this and add the EXTERNAL example (which is
good).

Note that this only refers to the SASL initial response (as it is included
with the AUTHENTICATE command), not to any part of the negotiation that
proceeds later.  Do you perhaps want text to that effect?

>      If the server cannot decode the [BASE64] data
>      transmitted by the client, the server MUST fail the authentication
>      with a tagged BAD response.  In particular, the server MUST reject
>      (and not ignore) any characters not explicitly allowed by the BASE64
>      alphabet, and should reject any sequence of BASE64 characters that
>      contains the pad character ('=') anywhere other than the end of the
>      string (e.g. "=AAA" and "AAA=BBB" are not allowed).
>
> This stuff is over and above the restrictions imposed by RFC 3501
> section 6.2.2. I don't feel pedantic enough to look up the original
> base64 RFC and see if there's equivalent text there. Either there is,
> and the text is superfluous, or there isn't, and the quoted text is a
> syntax difference of the kind I don't want.

Since Alexey was the one who wanted me to add this, I'll ask him to
comment here.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

From: Arnt Gulbrandsen <[email-masked]>
To: Rob Siemborski <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Cc: IMAP extensions Mailing List <[email-masked]>
Date: Tue, 14 Oct 2003 18:27:40 +0200
Sender: [email-masked]

Rob Siemborski writes:
> On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote:
>> I'm proposing that whether or not the server supports your extension, 
>> the rules that govern the client's first response should be the 
>> same.
>
> I agree.

Good. They aren't the same as the document stands now. There are 2-3 
extra restrictions, both/all small.

     If the client needs to transmit an
     initial response which is a zero-length string, it MUST transmit a
     single equals sign ("=").  This indicates that the response is
     present, but is a zero-length string.

There's a MUST here, although I'm not sure whether it represents an 
additional requirement over and above RFC 3501.

Let me suggest a rewording. "To send a zero-length initial response, the 
client can send a single pad character ("="). When decoded, this will 
result in a zero-length string on the server." Or perhaps use "AUTH 
EXTERNAL =" as an example. Either way, it's the same meaning, no 
additional restrictions.

     If the server cannot decode the [BASE64] data
     transmitted by the client, the server MUST fail the authentication
     with a tagged BAD response.  In particular, the server MUST reject
     (and not ignore) any characters not explicitly allowed by the BASE64
     alphabet, and should reject any sequence of BASE64 characters that
     contains the pad character ('=') anywhere other than the end of the
     string (e.g. "=AAA" and "AAA=BBB" are not allowed).

This stuff is over and above the restrictions imposed by RFC 3501 
section 6.2.2. I don't feel pedantic enough to look up the original 
base64 RFC and see if there's equivalent text there. Either there is, 
and the text is superfluous, or there isn't, and the quoted text is a 
syntax difference of the kind I don't want.

Thanks for taking the trouble to write the spec.

--Arnt

Date: Tue, 14 Oct 2003 12:07:58 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

On Tue, 14 Oct 2003, Mark Crispin wrote:

> On Tue, 14 Oct 2003, Rob Siemborski wrote:
> > > Mandatory to implement. With SMTP, the server can know that the client
> > > supports initial responses.
> > Sure, it knows that it supports it, but that doesn't change the fact that
> > the server still must deal with the client leaving off the initial
> > response.  That's part of the sasl specification.
>
> Huh???
>
> The server must implement initial responses in POP3 and SMTP, but there is
> no requirement that the client do so since the client can always omit it.

Yes, this is correct.  I misspoke.

FWIW, I hope that draft-siemborski-rfc2554bis-00.txt clarifies this
situation.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Tue, 14 Oct 2003 09:06:32 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

On Tue, 14 Oct 2003, Rob Siemborski wrote:
> > Mandatory to implement. With SMTP, the server can know that the client
> > supports initial responses.
> Sure, it knows that it supports it, but that doesn't change the fact that
> the server still must deal with the client leaving off the initial
> response.  That's part of the sasl specification.

Huh???

The server must implement initial responses in POP3 and SMTP, but there is
no requirement that the client do so since the client can always omit it.

-- Mark --

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

Date: Tue, 14 Oct 2003 09:05:15 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: Rob Siemborski <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote:
> With SMTP, the server can know that the client
> supports initial responses.

Say WHAT?????

Where did you get THAT???

-- Mark --

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

Date: Tue, 14 Oct 2003 12:03:01 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote:

> Rob Siemborski writes:
> > So you're proposing a situation where an extension that has an empty
> > string as an initial response is penalized a round trip:
>
> Not at all.
>
> I'm proposing that whether or not the server supports your extension,
> the rules that govern the client's first response should be the same.

I agree.

> >> SMTP is different - initial responses are m-t-i there.
> >
> > I'm sorry, What is m-t-i?
>
> Mandatory to implement. With SMTP, the server can know that the client
> supports initial responses.

Sure, it knows that it supports it, but that doesn't change the fact that
the server still must deal with the client leaving off the initial
response.  That's part of the sasl specification.

> With IMAP that's not the case. With IMAP,
> the first response may be an initial response, or it may be a response
> to an empty challenge. Either way, the syntax should be the same.

Either way, the syntax is the same.  The sever doesn't care if the client
supports initial response or not.  At the application level, it's not even
allowed to care!

If the client doesn't support an initial response, *or* the client doesn't
choose to send an initial response, then the negotiation proceeds the same
way: there was no initial response.

For example, in the DIGEST-MD5 case, where there *is* a difference (fast
reauth or not)  in both of the above cases, you proceed without fast
reauth.  The server doesn't care about the reason.

FWIW, EXTERNAL is likely to send an empty initial response.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

From: Arnt Gulbrandsen <[email-masked]>
To: Rob Siemborski <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Cc: IMAP extensions Mailing List <[email-masked]>
Date: Tue, 14 Oct 2003 18:00:14 +0200
Sender: [email-masked]

Rob Siemborski writes:
> So you're proposing a situation where an extension that has an empty 
> string as an initial response is penalized a round trip:

Not at all.

I'm proposing that whether or not the server supports your extension, 
the rules that govern the client's first response should be the same.

>> SMTP is different - initial responses are m-t-i there.
>
> I'm sorry, What is m-t-i?

Mandatory to implement. With SMTP, the server can know that the client 
supports initial responses. With IMAP that's not the case. With IMAP, 
the first response may be an initial response, or it may be a response 
to an empty challenge. Either way, the syntax should be the same.

--Arnt

Date: Tue, 14 Oct 2003 11:54:18 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

On Tue, 14 Oct 2003, Rob Siemborski wrote:

> clearly says "there is an initial response here, but it is the empty
> string"
>
> vs
>
> AUTHENTICATE MUMBLE
>
> which is required to mean "no initial response"
>
> Without the "=", you're required to fall back to the old behavior.

I suppose you could also do

"AUTHENTICATE MUMBLE "

to indicate an empty response.

Is that what you were proposing instead?

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Tue, 14 Oct 2003 11:46:21 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote:

> I can see that empty responses may one day be meaningful. However, I
> cannot see what's special about the combination of empty responses and
> this extension.
>
> Suppose AUTH=MUMBLE has some feature whereby an empty response makes
> sense. Shouldn't it work basically the same way whether this extension
> is present or not?
>
> C: a AUTHENTICATE MUMBLE
> S: +
> C: =
> ...

No, in this case you'd use the normal SASL negotiation, you wouldn't have
an =.

> or
>
> C: a AUTHENTICATE MUMBLE =
> ...
>
> IMO, the "=" should be governed by the same syntax in both cases, so the
> extension should avoid specifying new rules. Now that I think about it,
> I suppose that argument covers my base64 queasiness too - the argument
> should use the same rules as the same response would follow in the
> absence of the extension.

So you're proposing a situation where an extension that has an empty
string as an initial response is penalized a round trip:

AUTHENTICATE MUMBLE =

clearly says "there is an initial response here, but it is the empty
string"

vs

AUTHENTICATE MUMBLE

which is required to mean "no initial response"

Without the "=", you're required to fall back to the old behavior.

> > FWIW, SMTP does this.
>
> SMTP is different - initial responses are m-t-i there.

I'm sorry, What is m-t-i?

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

From: Arnt Gulbrandsen <[email-masked]>
To: Rob Siemborski <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Cc: IMAP extensions Mailing List <[email-masked]>
Date: Tue, 14 Oct 2003 17:44:32 +0200
Sender: [email-masked]

Rob Siemborski writes:
> On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote:
>> 2. The extension's capability name sounds a little inappropriate. 
>> This extension isn't "the SASL extension". I suggest SASL-IR 
>> instead.
>
> I was originally using SASLINITIAL, but it was suggested that I use 
> "SASL" instead because IMAP now "fully supports SASL" (well, as much 
> as it can without a client-side-capability extension, which would be 
> needed for server-last-sends).

"PRACTICALLYSASL"? Please not ;)

> Frankly, I don't really care what capability name is used, but I'd 
> like this to not be a continual point of argument.

I'd rather see your initial name than the current, but either way I've 
had my say about it.

> Whaile it is true that no current mechanisms have a situation where 
> they can send an empty initial response, a mechanism might be 
> developed where there may be something distinguising about the client 
> sending an empty initial send and the client omiting the initial send 
> (think of behavior like DIGEST-MD5 fast reauth). We need to handle 
> the two cases separately.

I can see that empty responses may one day be meaningful. However, I 
cannot see what's special about the combination of empty responses and 
this extension.

Suppose AUTH=MUMBLE has some feature whereby an empty response makes 
sense. Shouldn't it work basically the same way whether this extension 
is present or not?

C: a AUTHENTICATE MUMBLE
S: +
C: =
...

or

C: a AUTHENTICATE MUMBLE =
...

IMO, the "=" should be governed by the same syntax in both cases, so the 
extension should avoid specifying new rules. Now that I think about it, 
I suppose that argument covers my base64 queasiness too - the argument 
should use the same rules as the same response would follow in the 
absence of the extension.

> FWIW, SMTP does this.

SMTP is different - initial responses are m-t-i there.

--Arnt

Date: Tue, 14 Oct 2003 11:12:30 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Sender: [email-masked]

On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote:

> 1. The server must reject, not ignore, any characters outside the base64
> alphabet. Ditto = before the end.
>
> Why that? I can see it makes sense, but I'm tired of minor differences.
> Won't stock base64 do?

This was Alexey's suggestion due to bugs in base64 parsers.

> 2. The extension's capability name sounds a little inappropriate. This
> extension isn't "the SASL extension". I suggest SASL-IR instead.

I was originally using SASLINITIAL, but it was suggested that I use "SASL"
instead because IMAP now "fully supports SASL" (well, as much as it can
without a client-side-capability extension, which would be needed for
server-last-sends).

Frankly, I don't really care what capability name is used, but I'd like
this to not be a continual point of argument.

> 3. The draft makes mandates specific syntax for empty initial responses.
> I don't lik that. For one thing, under what circumstances would a
> client _need_ to send an empty initial response? That is, as opposed to
> sending no initial response at all? For another, why shouldn't the same
> rules as for other empty responses apply? (I confess I didn't look
> those up.)

There is a difference between "" and NULL, as there is a difference
between omiting the initial response and encoding an empty string.

Whaile it is true that no current mechanisms have a situation where they
can send an empty initial response, a mechanism might be developed
where there may be something distinguising about the client sending an
empty initial send and the client omiting the initial send (think of
behavior like DIGEST-MD5 fast reauth).  We need to handle the two cases
separately.

FWIW, SMTP does this.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

From: Arnt Gulbrandsen <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Date: Tue, 14 Oct 2003 14:08:54 +0200
Sender: [email-masked]

[email-masked] writes:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>         Title         : IMAP Extension for SASL Initial Client Response
>         Author(s)       : R. Siemborski
>         Filename        : draft-siemborski-imap-sasl-initial-response-00.txt

I'll skip the big issue and comment on some small ones.

1. The server must reject, not ignore, any characters outside the base64 
alphabet. Ditto = before the end.

Why that? I can see it makes sense, but I'm tired of minor differences. 
Won't stock base64 do?

2. The extension's capability name sounds a little inappropriate. This 
extension isn't "the SASL extension". I suggest SASL-IR instead.

3. The draft makes mandates specific syntax for empty initial responses. 
I don't lik that. For one thing, under what circumstances would a 
client _need_ to send an empty initial response? That is, as opposed to 
sending no initial response at all? For another, why shouldn't the same 
rules as for other empty responses apply? (I confess I didn't look 
those up.)

--Arnt

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt
Date: Mon, 13 Oct 2003 11:15:25 -0400
Sender: [email-masked]

--NextPart

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

	Title		: IMAP Extension for SASL Initial Client Response
	Author(s)	: R. Siemborski
	Filename	: draft-siemborski-imap-sasl-initial-response-00.txt
	Pages		: 7
	Date		: 2003-10-10
	
To date, the Internet Message Access Protocol (IMAP) has used a
Simple Authentication and Security Layer (SASL) profile which always
required at least one complete round trip for an authentication, as
it did not support an initial client response argument.  This
additional round trip at the beginning of the session is
undesirable, especially when round trip costs are high.

This document defines an extension to IMAP which allows clients and
servers to avoid this round trip by allowing an initial client
response argument to the IMAP AUTHENTICATE command.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-siemborski-imap-sasl-initial-response-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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
	"get draft-siemborski-imap-sasl-initial-response-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-siemborski-imap-sasl-initial-response-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-siemborski-imap-sasl-initial-response-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-siemborski-imap-sasl-initial-response-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 7 Oct 2003 18:33:51 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Tue, 7 Oct 2003, Ken Murchison wrote:
> I don't see why implementations which are clearly broken and in
> violation of the specs (regardless of how poorly written those specs may
> or may not be), should prevent the IMAP initial client response
> extension from proceeding as long as it avoids/corrects the problems
> with the SMTP AUTH and POP3 AUTH specs.

Ken, I believe that you are are thinking about a specification whereas I
am thinking more about human nature.  We have to allow for Murphy's Law.

The IMAP spec will be much more complicated than the SMTP or POP3 specs,
because IMAP is server-optional on initial response.  That is four support
states, whereas SMTP and POP3 only have two

> At the very least, shouldn't the IMAP initial response doc and revised
> SMTP AUTH and POP3 AUTH docs be able to proceed in parallel, especially
> if they all use similar language for the initial client response issue?

The question is if the SMTP and POP3 documents are going to advance or
not.  This also depends upon the SASL document.  I'd like to hear IESG
feedback on this.

Without some surety that the SMTP/POP3 situation is fixed, I feel like I
am being asked to leap from a tall building, based upon unproven claims
that the building is on fire and with equally unproven assurances that by
the time I reach the ground, you will have contrived to have erected a
net.

I don't see any urgency for initial response in IMAP; it is cosmetic or a
minor RTT savings at best.  We can afford to take the time to do it right.

-- Mark --

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

From: Steve Hole <[email-masked]>
Date: Tue, 7 Oct 2003 14:43:35 -0600
To: Mark Crispin <[email-masked]>
Subject: Re: SASL Initial Response?
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Tue, 7 Oct 2003 10:52:59 -0700 (Pacific Daylight Time) Mark Crispin 
<[email-masked]> wrote:

> Hi Steve -
> 
> I'm afraid that you misunderstood the issue.  The problem is not broken
> server interoperability with clients that send initial responses to SMTP
> and POP3 servers; rather, it is broken server interoperability with
> clients that do NOT send the initial responses.

Ah!   Sorry about that.

---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Tue, 07 Oct 2003 14:28:15 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

Mark Crispin wrote:

> It is for this reason that I think that the proponents of an initial
> response on the command line should back off until the specifications are
> clarified such that these broken SMTP and POP3 servers stop happening.

I don't see why implementations which are clearly broken and in 
violation of the specs (regardless of how poorly written those specs may 
or may not be), should prevent the IMAP initial client response 
extension from proceeding as long as it avoids/corrects the problems 
with the SMTP AUTH and POP3 AUTH specs.

At the very least, shouldn't the IMAP initial response doc and revised 
SMTP AUTH and POP3 AUTH docs be able to proceed in parallel, especially 
if they all use similar language for the initial client response issue?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Tue, 7 Oct 2003 14:00:20 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Steve Hole <[email-masked]>
cc: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Tue, 7 Oct 2003, Steve Hole wrote:

> Perhaps the larger surprise is why people suddenly feel this important.
> Cutting a round trip is nice if you're connecting/reconnecting a lot, but
> I'm not sure why you would want to do that.   In general, the cost of
> select/examine is pretty high and part of the channel setup.  It more or
> less mandates efficient use of connection pooling and maintenance. Over
> highly latent connections, anything that reduces roundtrips is useful
> though.

Personally, I don't think its "suddenly important."  I just think that the
lack of initial response here is unfortunate given that it violates a
SASL SHOULD.  Of course, the reason for this is because IMAP AUTHENTICATE
came before SASL, but that doesn't preclude it being fixed by an
extension.

> Personally I'd be thinking about synchronization optimizations
> first.   Let's see ... which set of message had flags that have changed
> since this time??

Doesn't CONDSTORE (which is in IETF Last Call) handle this?

e.g.
              C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345)
              S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen))
              S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted))
              S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk $MDNSent))
              S: s100 OK FETCH completed

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Tue, 7 Oct 2003 10:52:59 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Steve Hole <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Organization: Networks & Distributed Computing
Sender: [email-masked]

Hi Steve -

I'm afraid that you misunderstood the issue.  The problem is not broken
server interoperability with clients that send initial responses to SMTP
and POP3 servers; rather, it is broken server interoperability with
clients that do NOT send the initial responses.

There are multiple SMTP and POP3 servers, some running at large ISPs,
which do NOT respond correctly when a client does not provide an initial
response to the PLAIN authenticator.  The most common offenses are
	334 ok, go on
from an SMTP server and
	+ ok, go on
from a POP3 server.

Another common offense is to respond with something like:
	334 VXNlciBOYW1lAA==
(that is, treating AUTH PLAIN with no initial response as if it was AUTH
LOGIN).  Yet another variation does this, but has an extra CRLF.

These problems occur both with open source and vendor servers.

Once again, we hear the old tired story of "our server works with Netscape
[or Outlook], so your client must be broken."

As for "why is this important" for IMAP; I agree with you in thinking that
AUTHENTICATE command line initial response is not all that important for
IMAP, since IMAP sessions generally are much longer-lived than POP3 or
SMTP sessions.

It is for this reason that I think that the proponents of an initial
response on the command line should back off until the specifications are
clarified such that these broken SMTP and POP3 servers stop happening.

*AFTER* the specifications are fixed, I promise in return that I will not
only stop opposing initial response on the AUTHENTICATE command line, but
will also promptly implement support for it in UW imapd.

-- Mark --

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

From: Steve Hole <[email-masked]>
Date: Tue, 7 Oct 2003 11:25:49 -0600
To: Mark Crispin <[email-masked]>
Subject: Re: SASL Initial Response?
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Mon, 6 Oct 2003 15:55:30 -0700 (Pacific Daylight Time) Mark Crispin 
<[email-masked]> wrote:

> > > The second most common offense is "334 ok, go on" or "+ ok, go on".
> > > Somtimes you also find extra CRLFs in the responses.
> > This might be an ambiguous/incomplete specification for SMTP AUTH.  I'll
> > take a look.
> 
> It's not ambiguous, but you have to read three separate documents (RFCs
> 2222, 2554, and 2595) to work out how to handle an AUTH PLAIN command in
> SMTP.  For POP3, you just need to read 2222 and 2595.
> 
> There is no single document, and *NO* examples, that explains this.  RFC
> 2554 is a bit better in talking about empty challenges than 2595 (see
> first paragraph of page 3, RFC 2554) but without the context of RFC 2222
> it makes no sense.

Yes, you do have to look at more than one document, and I think that this 
did cause some problems in the beginning.

I have to admit to being a bit surprised though Mark.   We have been 
sending out initial responses to SMTP and POP3 servers for a number of 
years without too much in the way of interoperability problems.  There 
were some in the beginning, but most of those sorted out during the first 
IMC interop testing.  Many implementations use the Cyrus SASL library 
which provides good examples for usage and clearly supports initial 
response for those mechanisms that support it.

Perhaps the larger surprise is why people suddenly feel this important.  
Cutting a round trip is nice if you're connecting/reconnecting a lot, but 
I'm not sure why you would want to do that.   In general, the cost of 
select/examine is pretty high and part of the channel setup.  It more or 
less mandates efficient use of connection pooling and maintenance. Over
highly latent connections, anything that reduces roundtrips is useful 
though.   

Personally I'd be thinking about synchronization optimizations 
first.   Let's see ... which set of message had flags that have changed 
since this time??

Cheers.
---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Mon, 6 Oct 2003 16:12:58 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: "RL 'Bob' Morgan" <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 6 Oct 2003, Rob Siemborski wrote:
> I agree.  I also suspect an example or two could help the appropriate
> sections of 2222bis.  But further discussion of this should probably move
> to the ietf-sasl list.

I'm not on the ietf-sasl list, so would appreciate this being passed on.
I guess that I should be at the SASL session in Minneapolis (assuming I go
there which seems likely).

Examples are always helpful.  Section 6.1 of 2222bis should give examples
of AUTH PLAIN in SMTP both with and without initial client data.

Similar examples should appear in the specification for the PLAIN
mechanism (which currently is hidden in the IMAP/POP3/ACAP TLS spec!)
*and* in the specifications for POP3 SASL and SMTP SASL.

> Obviously.  But currently it seems that the primary reason that we don't
> have an initial SASL response in IMAP is concerns over clarity of the
> SASL specification.

Actually, the primary reason was compatibility with the past; IMAP SASL is
older than SASL.  I'm willing to go along with it as a server-optional
extension *IF* the problems with the current client-optional
server-mandatory initial client data POP3/SMTP SASL are fixed.

Since implementation of initial client data will be server-optional in
IMAP, it will be more complex than in POP3/SMTP.  This is because it's
mandatory to implement in POP3/SMTP servers.

> If fixing *that* specification still isn't good enough, I'm totally
> willing to supply text in the draft for the IMAP extention to the effect
> of "pay careful attention to the fact that initial responses are
> *optional*," even to the point of making it a Security Consideration.

We will need that text, and much more.

> And indeed, any IMAP server that didn't get this right would immediately
> have a large number of old-style clients fail to work against it anyway,
> since it is an extention and not part of the base protocol.

It's not just IMAP servers we have to worry about.  It's also IMAP
clients.

We already have clients which fail to interoperate with a server that does
not have a particular extension and/or declare such servers to be
"broken."  The offenders know who they are.

We have to concern ourselves about the possibility of clients that think
that initial data is mandatory to implement in the server (since it is
mandatory in POP3 and SMTP).

Thus, the situation is *worse* with IMAP than with POP3 or SMTP.

-- Mark --

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

Date: Mon, 6 Oct 2003 15:55:30 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: Rob Siemborski <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 6 Oct 2003, Ken Murchison wrote:
> Was there a broken Sendmail patch?  For all mechs, or just one in
> particular?

I don't know.  I know that sendmail at UW works correctly for GSSAPI and
PLAIN.

> > The most common offense is to implement PLAIN and LOGIN as the same thing,
> > thus giving LOGIN challenges to PLAIN with no initial response.
> That's inexcusable, since they are clearly NOT the same thing, and PLAIN
> has always had a standardized SPEC.  Obviously we can't make people read
> the specs correctly, all we can do is make them clear and unambiguous.

Agreed completely.  However, multiple commercial implementations have done
this blunder.

> > The second most common offense is "334 ok, go on" or "+ ok, go on".
> > Somtimes you also find extra CRLFs in the responses.
> This might be an ambiguous/incomplete specification for SMTP AUTH.  I'll
> take a look.

It's not ambiguous, but you have to read three separate documents (RFCs
2222, 2554, and 2595) to work out how to handle an AUTH PLAIN command in
SMTP.  For POP3, you just need to read 2222 and 2595.

There is no single document, and *NO* examples, that explains this.  RFC
2554 is a bit better in talking about empty challenges than 2595 (see
first paragraph of page 3, RFC 2554) but without the context of RFC 2222
it makes no sense.

> > Over and over again, I get told "just make Pine send the initial
> > challenge"; in other words, that the initial challenge is mandatory.  But
> > the SASL specification does not say that; and the idea of inflicting the
> > non-interoperable brokenness of POP/SMTP on IMAP repels me.
> So, you would like to see section 6.1 of RFC 2222bis use a MUST instead
> of SHOULD?  For some mechs (e.g. DIGEST-MD5) this could become
> problematic because the initial response truely is optional.

Actually, I would like the SHOULD to become a MAY, and it be emphasized
that servers MUST implement the correct empty challenge behavior.

However, a MUST is preferable to the status quo, which is a de jure SHOULD
but (at least according to certain individuals) a de facto MUST.

> I will do this.  Just to be clear, we are only talking about
> client-first mechanisms in which the client chooses to not send an
> initial response, correct?

Correct.  SMTP is the worst case, since you have to read three RFCs to
work out how to implement PLAIN in SMTP.

Note that there are no examples.

-- Mark --

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

Date: Mon, 06 Oct 2003 14:28:46 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Mark Crispin <[email-masked]>
CC: Rob Siemborski <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

Mark Crispin wrote:

> On Mon, 6 Oct 2003, Ken Murchison wrote:
> 
>>Can you list the broken implementations?  Are there any current versions
>>of servers which are broken, or just old/deprecated/unsupported code?
> 
> 
> It's easier to list the non-broken implementations: UW, Cyrus, and one of
> the SASL patches to sendmail.

Was there a broken Sendmail patch?  For all mechs, or just one in 
particular?

> The most common offense is to implement PLAIN and LOGIN as the same thing,
> thus giving LOGIN challenges to PLAIN with no initial response.

That's inexcusable, since they are clearly NOT the same thing, and PLAIN 
has always had a standardized SPEC.  Obviously we can't make people read 
the specs correctly, all we can do is make them clear and unambiguous.

> The second most common offense is "334 ok, go on" or "+ ok, go on".
> Somtimes you also find extra CRLFs in the responses.

This might be an ambiguous/incomplete specification for SMTP AUTH.  I'll 
take a look.

> Over and over again, I get told "just make Pine send the initial
> challenge"; in other words, that the initial challenge is mandatory.  But
> the SASL specification does not say that; and the idea of inflicting the
> non-interoperable brokenness of POP/SMTP on IMAP repels me.

So, you would like to see section 6.1 of RFC 2222bis use a MUST instead 
of SHOULD?  For some mechs (e.g. DIGEST-MD5) this could become 
problematic because the initial response truely is optional.

> The text is NOT clear as to how a non-specified client response is to be
> handled.  You have to go through multiple documents to work it out.
> 
> The best way to understand the problem is to go through the exercise
> yourself.  Pretend that you don't know how SASL works.  The client gives
> an "AUTH PLAIN" command to an SMTP server without the initial response.
> Now, go through the steps of going through the RFCs to interpret that
> command, and determine the proper response.

I will do this.  Just to be clear, we are only talking about 
client-first mechanisms in which the client chooses to not send an 
initial response, correct?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 6 Oct 2003 14:00:10 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: "RL 'Bob' Morgan" <[email-masked]>
cc: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Mon, 6 Oct 2003, RL 'Bob' Morgan wrote:

> On Mon, 6 Oct 2003, Mark Crispin wrote:
>
> > > If there is a problem, it should
> > > probably be raised in the SASL WG.  (Of course, that document's WG last
> > > call allegedly finished on Sep 30, but it looks like comments are still
> > > being made).
> >
> > Well, there's a problem right there; it's probably too late to raise it
> > in the SASL WG.  I agree that that is where it should have been raised.
>
> WG Last Call is only the first of many hurdles, including IETF-wide Last
> Call.  There is still lots of time to comment on
> draft-ietf-sasl-rfc2222bis-02.txt.

I agree.  I also suspect an example or two could help the appropriate
sections of 2222bis.  But further discussion of this should probably move
to the ietf-sasl list.

> > So it becomes an IMAP question again.
>
> Any change to the IMAP protocol is of course an IMAP(ext) WG question,
> even if the SASL text is perfect.

Obviously.  But currently it seems that the primary reason that we don't
have an initial SASL response in IMAP is concerns over clarity of the
SASL specification.

If fixing *that* specification still isn't good enough, I'm totally
willing to supply text in the draft for the IMAP extention to the effect
of "pay careful attention to the fact that initial responses are
*optional*," even to the point of making it a Security Consideration.

And indeed, any IMAP server that didn't get this right would immediately
have a large number of old-style clients fail to work against it anyway,
since it is an extention and not part of the base protocol.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Mon, 6 Oct 2003 10:31:07 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: Rob Siemborski <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Mon, 6 Oct 2003, Ken Murchison wrote:
> Can you list the broken implementations?  Are there any current versions
> of servers which are broken, or just old/deprecated/unsupported code?

It's easier to list the non-broken implementations: UW, Cyrus, and one of
the SASL patches to sendmail.

I'm encountering broken server implementations all the time, and big
providers run them.  I've seen little progress in getting it fixed.  It's
pretty high on my FAQ list, second only to the PC Pine crashes caused by
Microsoft's persistant failure to fix the bug in SSPI that they've known
about for years (they fixed it in Win2K but not WinXP).

The most common offense is to implement PLAIN and LOGIN as the same thing,
thus giving LOGIN challenges to PLAIN with no initial response.

The second most common offense is "334 ok, go on" or "+ ok, go on".
Somtimes you also find extra CRLFs in the responses.

Over and over again, I get told "just make Pine send the initial
challenge"; in other words, that the initial challenge is mandatory.  But
the SASL specification does not say that; and the idea of inflicting the
non-interoperable brokenness of POP/SMTP on IMAP repels me.

IMAP currently forces a correct implementation of null server challenges.
Before this protection is removed, something must be done to fix the
broken situation in those protocols which lack this protection.

> Based on RFC 2222(bis), RFC 1734/2449 and RFC 2554, do you have any
> insight?  I think the text is pretty clear, but maybe others don't.

The text is NOT clear as to how a non-specified client response is to be
handled.  You have to go through multiple documents to work it out.

The best way to understand the problem is to go through the exercise
yourself.  Pretend that you don't know how SASL works.  The client gives
an "AUTH PLAIN" command to an SMTP server without the initial response.
Now, go through the steps of going through the RFCs to interpret that
command, and determine the proper response.

I've done this tedious exercise multiple times with server implementors
who simply refuse to believe that I know what I am talking about.  It
would be helpful if you (Ken and Rob) went through it yourselves.

I agree that the specification is complete and precise.  The problem is
that too many implementors fail to understand it.

Incidentally, it would be an acceptable answer to me to declare "on
January 1, 2004, the initial challenge becomes mandatory in all
protocols."  I would not *like* it, but it would be better than the status
quo with POP3/SMTP.

-- Mark --

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

Date: Mon, 06 Oct 2003 18:28:52 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Rob Siemborski <[email-masked]>, Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

Cyrus mentioned this extension during a private talk at least 6 month ago.

Unless there is a compeling reason not to add this, I am in full support 
for this extension.

Mark Crispin wrote:

>On Mon, 6 Oct 2003, Rob Siemborski wrote:
>  
>
>>I agree -- this sounds like an issue with initial responses in general,
>>not with a specific use of them in IMAP.
>>    
>>
>I agree.  However, the question at hand is whether to reverse an earlier
>decision NOT to add this facility to IMAP.
>
Mark, coould you remind me when this has taken place?

>  Thus, it is an IMAP question.
>  
>
>>If there is a problem, it should
>>probably be raised in the SASL WG.  (Of course, that document's WG last
>>call allegedly finished on Sep 30, but it looks like comments are still
>>being made).
>>    
>>
>
>Well, there's a problem right there; it's probably too late to raise it in
>the SASL WG.  I agree that that is where it should have been raised.
>
As the editor of RFC2222bis, I can say that it is not too late.

>So it becomes an IMAP question again.
>
Alexey

Date: Mon, 6 Oct 2003 10:12:32 -0700 (PDT)
From: "RL 'Bob' Morgan" <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Mon, 6 Oct 2003, Mark Crispin wrote:

> > If there is a problem, it should
> > probably be raised in the SASL WG.  (Of course, that document's WG last
> > call allegedly finished on Sep 30, but it looks like comments are still
> > being made).
>
> Well, there's a problem right there; it's probably too late to raise it
> in the SASL WG.  I agree that that is where it should have been raised.

WG Last Call is only the first of many hurdles, including IETF-wide Last
Call.  There is still lots of time to comment on
draft-ietf-sasl-rfc2222bis-02.txt.

> So it becomes an IMAP question again.

Any change to the IMAP protocol is of course an IMAP(ext) WG question,
even if the SASL text is perfect.

 - RL "Bob"

Date: Mon, 6 Oct 2003 10:03:25 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Mon, 6 Oct 2003, Rob Siemborski wrote:
> I agree -- this sounds like an issue with initial responses in general,
> not with a specific use of them in IMAP.

I agree.  However, the question at hand is whether to reverse an earlier
decision NOT to add this facility to IMAP.  Thus, it is an IMAP question.

> If there is a problem, it should
> probably be raised in the SASL WG.  (Of course, that document's WG last
> call allegedly finished on Sep 30, but it looks like comments are still
> being made).

Well, there's a problem right there; it's probably too late to raise it in
the SASL WG.  I agree that that is where it should have been raised.

So it becomes an IMAP question again.

-- Mark --

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

Date: Mon, 6 Oct 2003 12:30:17 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Mon, 6 Oct 2003, Ken Murchison wrote:

> > 4) Would a change of wording in the specification help?
>
> Based on RFC 2222(bis), RFC 1734/2449 and RFC 2554, do you have any
> insight?  I think the text is pretty clear, but maybe others don't.

I agree -- this sounds like an issue with initial responses in general,
not with a specific use of them in IMAP.  If there is a problem, it should
probably be raised in the SASL WG.  (Of course, that document's WG last
call allegedly finished on Sep 30, but it looks like comments are still
being made).

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Mon, 06 Oct 2003 12:30:26 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Mark Crispin <[email-masked]>
CC: Rob Siemborski <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

Mark Crispin wrote:

> On Mon, 6 Oct 2003, Ken Murchison wrote:
> 
>>This might be true, but it doesn't seem like a compelling technical
>>argument against allowing this in IMAP.  Existing or future poor
>>implementations should not stand in the way of progress, unless the
>>specification is so complex that it is part of the implementation problem.
> 
> 
> Well, I think that the example of POP and SMTP suggests that it may well
> be too complex.  Before proceeding, I think that the POP/SMTP experience
> needs to be carefully reviewed.
> 
> 
>>Are you saying that you would oppose such an extension, or just saying
>>that based on past experience it might cause some heartburn?
> 
> 
> It will cause some heartburn.  The proof is out there.

Can you list the broken implementations?  Are there any current versions 
of servers which are broken, or just old/deprecated/unsupported code?

> 
> As for support or opposition, I haven't taken a position; but if it is
> proposed without any attempt to study or learn from the POP/SMTP
> experience I probably will oppose it.
> 
> Suggested topics for study:
> 
> 1) Why is it difficult to understand that the initial response is
> optional?
> 
> 2) Why do server implementors have trouble in generating appropriate
> initial challenges ("ok, go ahead" in plaintext is not appropriate)?
> 
> 3) Why are incorrect implementations so widespread in the POP/SMTP world?
> 
> 4) Would a change of wording in the specification help?

Based on RFC 2222(bis), RFC 1734/2449 and RFC 2554, do you have any 
insight?  I think the text is pretty clear, but maybe others don't.

> If these questions are answered in a reasonable way, I will either support
> or be neutral on the proposal.

Glad to hear it.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 6 Oct 2003 09:18:07 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: Rob Siemborski <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Mon, 6 Oct 2003, Ken Murchison wrote:
> This might be true, but it doesn't seem like a compelling technical
> argument against allowing this in IMAP.  Existing or future poor
> implementations should not stand in the way of progress, unless the
> specification is so complex that it is part of the implementation problem.

Well, I think that the example of POP and SMTP suggests that it may well
be too complex.  Before proceeding, I think that the POP/SMTP experience
needs to be carefully reviewed.

> Are you saying that you would oppose such an extension, or just saying
> that based on past experience it might cause some heartburn?

It will cause some heartburn.  The proof is out there.

As for support or opposition, I haven't taken a position; but if it is
proposed without any attempt to study or learn from the POP/SMTP
experience I probably will oppose it.

Suggested topics for study:

1) Why is it difficult to understand that the initial response is
optional?

2) Why do server implementors have trouble in generating appropriate
initial challenges ("ok, go ahead" in plaintext is not appropriate)?

3) Why are incorrect implementations so widespread in the POP/SMTP world?

4) Would a change of wording in the specification help?

If these questions are answered in a reasonable way, I will either support
or be neutral on the proposal.

-- Mark --

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

Date: Mon, 06 Oct 2003 11:55:57 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Mark Crispin <[email-masked]>
CC: Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: SASL Initial Response?
Sender: [email-masked]

Mark Crispin wrote:

> On Mon, 6 Oct 2003, Rob Siemborski wrote:
> 
>>Is there any reason no one has ever proposed an IMAP extention to support
>>SASL initial client responses?
> 
> 
> Experience with POP and SMTP suggests that if the protcol supports initial
> client responses, server implementors will never correctly implement the
> case when the client does not supply one.
> 
> This has been an ongoing problem which, to date, IMAP has had blissful
> immunity.

This might be true, but it doesn't seem like a compelling technical 
argument against allowing this in IMAP.  Existing or future poor 
implementations should not stand in the way of progress, unless the 
specification is so complex that it is part of the implementation problem.

Are you saying that you would oppose such an extension, or just saying 
that based on past experience it might cause some heartburn?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 6 Oct 2003 08:27:46 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: [email-masked]
Subject: Re: SASL Initial Response?
Sender: [email-masked]

On Mon, 6 Oct 2003, Rob Siemborski wrote:
> Is there any reason no one has ever proposed an IMAP extention to support
> SASL initial client responses?

Experience with POP and SMTP suggests that if the protcol supports initial
client responses, server implementors will never correctly implement the
case when the client does not supply one.

This has been an ongoing problem which, to date, IMAP has had blissful
immunity.

-- Mark --

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

Date: Mon, 6 Oct 2003 10:50:37 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: SASL Initial Response?
Sender: [email-masked]

Is there any reason no one has ever proposed an IMAP extention to support
SASL initial client responses?

My basic idea would be that the server would advertise another (sigh)
capability, and would then accept a second argument to the AUTHENTICATE
command which would contain the initial SASL blob (if applicable).

Can anyone offhand see why this would be an outright bad idea?
Certainly, I can understand not being able to do this for
server-last-sends currently (since that seems to require a client-side
capability mechanism of some sort), but it seems like initial client
responses would be both easy to add, and beneficial (in terms of the
number of round trips required at startup).

If there aren't significant initial objections, I'm willing to put
together an individual ID for this.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

From: Arnt Gulbrandsen <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: two ACL2 points
Cc: IMAP extensions Mailing List <[email-masked]>
Date: Sat, 4 Oct 2003 21:57:58 +0200
Sender: [email-masked]

Mark Crispin writes:
> On Sat, 4 Oct 2003, Arnt Gulbrandsen wrote:
>> What I'd like is a requirement that the server MAY send unsolicited 
>> LIST (ACL) responses for any mailbox for which the client has issued 
>> an ACL command, and that the client MUST handle such responses.
>
> That is already a requirement of IMAP, and always has been.

Yes, I've seen the half-sentence in 2.2.2. But I don't see much about 
"client MUST handle", except specific requirements such as that in 
7.2.6.

A nudge and a wink doesn't seem out of place in the ACL2 document. 
Perhaps in the form of a stated "client MUST handle", or perhaps in the 
form of an example that draws attention to rules that are in the base 
RFC.

(I ran into this while fooling with an ACL dialog and thinking, what if 
this is run by two IMAP clients at the same time, e.g. two people 
responding to the same e-mailed request?)

--Arnt

Date: Sat, 4 Oct 2003 22:06:36 +0300
Subject: Re: two ACL2 points
Cc: IMAP extensions Mailing List <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
From: Timo Sirainen <[email-masked]>
Sender: [email-masked]

On Saturday, Oct 4, 2003, at 20:41 Europe/Helsinki, Arnt Gulbrandsen 
wrote:

> 1. The SELECT command looks at ACL, says the draft, but as soon as a 
> client has selected a mailbox that's it. The security considerations 
> should probably note that if an ACL is restricted, any client that 
> already has selected the mailbox keeps its access indefinitely.
>
> Perhaps the server should be explicitly allowed to kick the client out 
> in this case.

This is mail store dependent. If you drop access to maildir in 
filesystem level, you can't open mails anymore.

Date: Sat, 4 Oct 2003 11:42:20 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: two ACL2 points
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Sat, 4 Oct 2003, Arnt Gulbrandsen wrote:
> 1. The SELECT command looks at ACL, says the draft, but as soon as a
> client has selected a mailbox that's it. The security considerations
> should probably note that if an ACL is restricted, any client that
> already has selected the mailbox keeps its access indefinitely.

I agree.

> 2. A client that has run LIST ACL isn't told about later changes.

Similarly, a client that does a LIST isn't told when mailboxes are created
or deleted.

> What I'd like is a requirement that the server MAY send unsolicited LIST
> (ACL) responses for any mailbox for which the client has issued an ACL
> command, and that the client MUST handle such responses.

That is already a requirement of IMAP, and always has been.  For example,
a server can send an untagged SEARCH even if the client never issued a
SEARCH command.  However, there is no reason to believe that any client
will do anything with such responses.

The unsolicited data model only requires that clients keep track of
state changes in the selected mailbox, and is silent about other data.  It
neither mandates nor forbids it.

-- Mark --

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

From: Arnt Gulbrandsen <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: two ACL2 points
Date: Sat, 4 Oct 2003 19:41:21 +0200
Sender: [email-masked]

[ As I write this mail I have a deja vu feeling. Have I already noted 
these things? I don't see anything in my mail archive. ]

Both points relate to changes in ACLs done by one client that affect another.

1. The SELECT command looks at ACL, says the draft, but as soon as a 
client has selected a mailbox that's it. The security considerations 
should probably note that if an ACL is restricted, any client that 
already has selected the mailbox keeps its access indefinitely.

Perhaps the server should be explicitly allowed to kick the client out 
in this case.

2. A client that has run LIST ACL isn't told about later changes.

IMO, the server has the right to send any and all unsolicited responses 
during IDLE mode, and also as side effects for most commands. But I 
suspect many clients don't handle that very well...

What I'd like is a requirement that the server MAY send unsolicited LIST 
(ACL) responses for any mailbox for which the client has issued an ACL 
command, and that the client MUST handle such responses.

--Arnt

To: IETF-Announce :;
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: Last Call: 'IMAP Extension for Conditional STORE operation' to  Proposed Standard 
Reply-to: [email-masked]
Date: Fri, 03 Oct 2003 10:16:55 -0400
Sender: [email-masked]

The IESG has received a request from the Internet Message Access Protocol 
Extension WG to consider the following document:

- 'IMAP Extension for Conditional STORE operation '
   <draft-ietf-imapext-condstore-04.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 any comments to the
[email-masked] or [email-masked] mailing lists by 2003-10-17.
                                                                                       
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-04.txt

Date: Thu, 02 Oct 2003 09:55:35 -0700 (PDT)
From: [email-masked]
Subject: Re: AD review comments on draft-ietf-imapext-condstore
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked], Pete Resnick <[email-masked]>, [email-masked], Ned Freed <[email-masked]>, [email-masked]
Sender: [email-masked]

> > The production:
> >
> >    fetch               = "FETCH" SP sequence-set SP ("ALL" / "FULL" /
> >                          "FAST" / fetch-att /
> >                          "(" fetch-att *(SP fetch-att) ")")
> > [SPfetch-modifiers]
> >
> > should read:
> >
> >    fetch               = "FETCH" SP sequence-set SP ("ALL" / "FULL" /
> >                          "FAST" / fetch-att /
> >                          "(" fetch-att *(SP fetch-att) ")") [SP
> > fetch-modifiers]

> Actually, this production is correct (there is a space between SP and
> fetch-modifiers.

Some sort of wierd cut and paste error on my part then. Sorry about that.

> I've updated the document.

Yes, thanks, and now that the revision has hit the repository I'll ask for
a last call.

				Ned 

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-condstore-04.txt
Date: Thu, 02 Oct 2003 10:50:27 -0400
Sender: [email-masked]

--NextPart

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		: IMAP Extension for Conditional STORE operation
	Author(s)	: A. Melnikov, S. Hole
	Filename	: draft-ietf-imapext-condstore-04.txt
	Pages		: 16
	Date		: 2003-10-2
	
Often, multiple IMAP clients need to coordinate changes to a common
IMAP mailbox.  Examples include different clients for the same user,
and multiple users accessing shared mailboxes. These clients
need a mechanism to synchronize state changes for messages within the
mailbox. They must be able to guarantee that only one client can change
message state (e.g., message flags or annotations) at any time.  An
example of such an application is use of an IMAP mailbox as a message
queue with multiple dequeueing clients.
The Conditional Store facility provides a protected update mechanism for
message state information that can detect and resolve conflicts between
multiple writing mail clients.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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
	"get draft-ietf-imapext-condstore-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-condstore-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-condstore-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-condstore-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Thu, 02 Oct 2003 10:01:45 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: Pete Resnick <[email-masked]>, [email-masked], Ned Freed <[email-masked]>, [email-masked]
Subject: Re: AD review comments on draft-ietf-imapext-condstore
Sender: [email-masked]

[email-masked] wrote:

>
> Pete asked me to last call this document. However, my AD review turned up
> a number of errors, mostly editorial in nature. There are enough of these
> that I think they need to be corrected in a revised I-D before 
> proceeding.
>
> - - - - - -
>
> Section 2, fifth paragraph: A reference to [ANNOTATE] should be added.
>
> Section 2, seventh paragraph: extention -> extension
>
> Section 4, second paragraph: "[IMAP4]" -> "[IMAP4] or [ANNOTATE]"
>
> There are lots of ABNF errors. The production:
>
> entry-name          = entry-name-flag / entry-annotate-name
>    should be:
>
> entry-name          = entry-flag-name / entry-annotate-name
>    (There is no entry-name-flag production.) The production:
>
>    entry-flag-name     = '"' "/flags/" attr-flag '"'
>
> isn't syntactically valid and needs to be changed to:
>
>    entry-flag-name     = DQUOTE "/flags/" attr-flag DQUOTE
>
> (The DQUOTE production is used in RFC 3501, whose ABNF is available to
> this document.) The production:
>
>    entry-type-resp     = "priv" | "shared"
>
> should be:
>
>    entry-type-resp     = "priv" / "shared"
>
> The production:
>
>    entry-type-req      = entry-type-resp | "all"
>
> should be:
>
>    entry-type-req      = entry-type-resp / "all"
>
> The production:
>
>    store               = "STORE" SP set store-modifiers SP 
> store-att-flags
>
> should read:
>
>    store               = "STORE" SP sequence-set store-modifiers
>                          SP store-att-flags 

> The production:
>
>    fetch               = "FETCH" SP sequence-set SP ("ALL" / "FULL" /
>                          "FAST" / fetch-att /
>                          "(" fetch-att *(SP fetch-att) ")") 
> [SPfetch-modifiers]
>
> should read:
>
>    fetch               = "FETCH" SP sequence-set SP ("ALL" / "FULL" /
>                          "FAST" / fetch-att /
>                          "(" fetch-att *(SP fetch-att) ")") [SP 
> fetch-modifiers] 

Actually, this production is correct (there is a space between SP and 
fetch-modifiers.

> The production:
>
>    mod-sequence-valzer = "0" | mod-sequence-value
>
> should be:
>
>    mod-sequence-valzer = "0" / mod-sequence-value
>
> The production name "search_sort_mod_seq" needs to be changed to
> "search-sort-mod-seq" everywhere. (Underscors aren't allowed in 
> production
> names.)
>
> Security considerations:
>
> The statement "It is believed that the Conditional STORE extension
> doesn't raise any new security concerns that are not already discussed
> in [IMAP4]" is correct as far as it goes. However, this extension
> provides a means by which an IMAP store can be used for potentially
> criticial applications involving multiple clients that could not be
> supported before. This may have the effect of making correct IMAP
> server behavior more important. Accordingly, I suggest amending the
> section to read:
>
> It is believed that the Conditional STORE extension doesn't raise
> any new security concerns that are not already discussed in [IMAP4].
> However, the availability of this extension may make it possible
> for IMAP4 to be used in critical applications it could not be used
> for previously, making correct IMAP server implementation and
> operation in even more important.
>
> Section 7: The wording here is awkward. I suggest changing it to read:
> "This document defines  the CONDSTORE and SORT=MODSEQ IMAP capabilities.
> IANA should add them to the registry accordingly."
>
> Acknowledgements, third paragraph:  "Authors" -> "The authors"
>
> That's it!
>
>                 Ned

Thank you Ned.
I've updated the document.

Alexey

Date: Wed, 01 Oct 2003 23:15:36 -0700 (PDT)
From: [email-masked]
Subject: AD review comments on draft-ietf-imapext-condstore
To: Pete Resnick <[email-masked]>, [email-masked]
Cc: Ned Freed <[email-masked]>, [email-masked]
Sender: [email-masked]

Pete asked me to last call this document. However, my AD review turned up
a number of errors, mostly editorial in nature. There are enough of these
that I think they need to be corrected in a revised I-D before proceeding.

- - - - - -

Section 2, fifth paragraph: A reference to [ANNOTATE] should be added.

Section 2, seventh paragraph: extention -> extension

Section 4, second paragraph: "[IMAP4]" -> "[IMAP4] or [ANNOTATE]"

There are lots of ABNF errors. The production:

 entry-name          = entry-name-flag / entry-annotate-name
    
should be:

 entry-name          = entry-flag-name / entry-annotate-name
    
(There is no entry-name-flag production.) The production:

    entry-flag-name     = '"' "/flags/" attr-flag '"'

isn't syntactically valid and needs to be changed to:

    entry-flag-name     = DQUOTE "/flags/" attr-flag DQUOTE

(The DQUOTE production is used in RFC 3501, whose ABNF is available to
this document.) The production:

    entry-type-resp     = "priv" | "shared"

should be:

    entry-type-resp     = "priv" / "shared"

The production:

    entry-type-req      = entry-type-resp | "all"

should be:

    entry-type-req      = entry-type-resp / "all"

The production:

    store               = "STORE" SP set store-modifiers SP store-att-flags

should read:

    store               = "STORE" SP sequence-set store-modifiers
                          SP store-att-flags

The production:

    fetch               = "FETCH" SP sequence-set SP ("ALL" / "FULL" /
                          "FAST" / fetch-att /
                          "(" fetch-att *(SP fetch-att) ")") [SPfetch-modifiers]

should read:

    fetch               = "FETCH" SP sequence-set SP ("ALL" / "FULL" /
                          "FAST" / fetch-att /
                          "(" fetch-att *(SP fetch-att) ")") [SP fetch-modifiers]

The production:

    mod-sequence-valzer = "0" | mod-sequence-value

should be:

    mod-sequence-valzer = "0" / mod-sequence-value

The production name "search_sort_mod_seq" needs to be changed to
"search-sort-mod-seq" everywhere. (Underscors aren't allowed in production
names.)

Security considerations:

The statement "It is believed that the Conditional STORE extension
doesn't raise any new security concerns that are not already discussed
in [IMAP4]" is correct as far as it goes. However, this extension
provides a means by which an IMAP store can be used for potentially
criticial applications involving multiple clients that could not be
supported before. This may have the effect of making correct IMAP
server behavior more important. Accordingly, I suggest amending the
section to read:

 It is believed that the Conditional STORE extension doesn't raise
 any new security concerns that are not already discussed in [IMAP4].
 However, the availability of this extension may make it possible
 for IMAP4 to be used in critical applications it could not be used
 for previously, making correct IMAP server implementation and
 operation in even more important.

Section 7: The wording here is awkward. I suggest changing it to read:
"This document defines  the CONDSTORE and SORT=MODSEQ IMAP capabilities.
IANA should add them to the registry accordingly."

Acknowledgements, third paragraph:  "Authors" -> "The authors"

That's it!

				Ned