Subject: [EAI] WG LAST CALL for draft-ietf-eai-pop-06

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 13 Jul 2009 14:59:38 +0200

This is the second of 3 WG Last Calls on EAI documents.

The Last Call runs for 3 weeks - from July 13 to Monday, August 3, 2009, 
to allow for IETF week.

As usual:

- If you have an ISSUE with the document, write a mail to the mailing 
list with the subject line of ISSUE: POP - description (preferably with 
section number)

- If you have an editorial correction, send it with a subject line of 
EDITORIAL: POP to the mailing list, or send it directly to the author.

- Do NOT raise new issues in replies to other messages. They will not be 
tracked.

With hopes of completing this task quickly

          Harald Alvestrand

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 18 Jul 2009 21:21:41 +0100

I am sorry I haven't followed Harald's request to post each issue in a 
separare message, but it is actually easier for me as an AD to track all 
issues in one place.

The document is in a good shape. I have mostly minor comments:

In Section 2:

>   The LANG command requests that human-readable text included in all
>   subsequent +OK and -ERR responses be localized to a language matching
>   the language range argument as described by [RFC4647].
>
I think this text needs to be clearer that it means "Basic Language 
Range" as defined in section 2.1 of RFC 4647.

> 3.1. The UTF8 Command
>
>    The octet count (size) of a message reported in a response to the
>    LIST command SHOULD match the actual number of octets sent in a RETR
>    response.  Sizes reported elsewhere, such as in STAT responses and
>    non-standardized free-form text in positive status indicators
>    (following "+OK") need not be accurate, but it is preferable if they
>    are.

I would like to hear some justification for returning inaccurate sizes 
(and for the SHOULD instead of a MUST).

> 3.2. USER Argument to UTF8 Capability
>
>    If the USER argument is included with this capability, it indicates
>    that the server accepts UTF-8 user names and passwords and applies
>    SASLprep [RFC4013] to the arguments of the AUTH, USER, PASS and APOP
>    commands.  A client that supports APOP and permits UTF-8 in user
>    names or passwords MUST also implement SASLprep [RFC4013] on the user
>    name and password used to compute the APOP digest.

I think the last sentence should read:

  A client that supports APOP and permits UTF-8 in user
   names or passwords MUST apply SASLprep [RFC4013] to the user
   name and password used to compute the APOP digest.

Also, the document is missing a statement about what should be done 
about Unicode characters disallowed by SASLPrep.
So, I would recommend adding the following sentence:

   The server MUST reject UTF-8 user names/password which fails to comply
   with the formal syntax in RFC 3629 [RFC3629] or if it encounters a 
Unicode
   characters listed in section 2.3 of RFC 4013 [RFC4013].

>    The client does not need to issue the UTF8 command prior to using
>    UTF8 in authentication.  However, clients MUST NOT use UTF8 in USER,
>    PASS, or APOP commands unless the USER argument is included with the
>    UTF8 capability.
>
>    Use of UTF8 in the AUTH command is governed by the SASL mechanism.

Should this have an Informative reference to RFC 4422?

As a side note: UTF-8 was always allowed in AUTH command, as support for 
it is required by SASL.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 19 Jul 2009 20:45:49 +0100

After further discussion of this document with Kurt Zeilenga:

>   characters listed in section 2.3 of RFC 4013 [RFC4013].

Kurt said that SASLPrep is a MUST for both clients and servers 
implementing APOP. For USER/PASS, he suggested that SASLPrep is a SHOULD 
on the server side only (this matches SASL PLAIN mechanism).

> As a side note: UTF-8 was always allowed in AUTH command, as support 
> for it is required by SASL.

Please delete any references to UTF8 updating how AUTH command behave 
(this affects both sections 3 and 3.2). Each SASL mechanism describes 
how username and passwords (if any) are encoded, so the current text in 
EAI-POP3 can be read as conflicting with this.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 20 Jul 2009 17:29:49 -0400

> I would like to hear some justification for returning inaccurate sizes (and
> for the SHOULD instead of a MUST).

It may be that a conversion has to be made in order to get an accurate
size.  Perhaps an implementation would be well advised to go ahead and
do the conversion as soon as the size is needed, and then cache the
converted document until the RETR is done, but that might not be
practical (suppose a LIST is listing 5000 messages; the server can't
really convert all 5000 for the list command, and it'd likely then
have to re-convert the ones that are actually retrieved).

The SHOULD (and the permission to be inaccurate in other responses)
gives an "out" to the server, allowing it to reserve the expensive
processing for when the message is actually retrieved.

Because clients have to be changed to ask for this anyway, those
clients can also understand that they have to deal with a retrieval
that might be larger than they were led to expect, and they can code
for it.

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 22 Jul 2009 14:32:45 +0100

>that might be larger than they were led to expect, and they can code
Note that in IMAP we decided to always return exact sizes. This is true 
for the base IMAP spec and for the CONVERT extension, which is similar 
to what EAI POP3 servers might be doing.

If we want to keep the SHOULD, your last point ("Because clients have to 
be changed to ask for this anyway") needs to be explicitly spelled out. 
I am not sure how existing clients are using results of the LIST 
command. I also think that in this case the document needs to say that 
messages sizes MUST be consistent (i.e. for a given message the server 
must return the same size in LIST all the time).

---

From: Randall Gellens <[email-masked]>
Date: Mon, 27 Jul 2009 01:42:19 -0700

At 9:21 PM +0100 7/18/09, Alexey Melnikov wrote:

>  I would like to hear some justification for returning inaccurate 
> sizes (and for the SHOULD instead of a MUST).

Depending on server implementation, it might be expensive to 
calculate an exact size, and so shouldn't be forced without good 
reason.  I'm thinking tat the LIST size is mostly to give the client 
an idea if it wants to download the message or part of it.  Also, the 
free-form sizes are not part of the spec in any way, just common 
practice.  I'm aware that there have been cases where clients went 
bonkers or casters-up (behaved badly) if the server put an inaccurate 
count in the free-form text, but hopefully this isn't a reason to now 
mandate that such sizes be included at all, much less be accurate.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Please ignore previous fortune.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 27 Jul 2009 01:51:22 -0700

>  Should this have an Informative reference to RFC 4422?

Or maybe RFC 5034?

>  As a side note: UTF-8 was always allowed in AUTH command, as 
> support for it is required by SASL.

Indeed so, including a SHOULD for SASLprep in 5034.

-------------- Randomly selected tag: ---------------
    The highlight of the annual Computer Bowl occurred when Bill Gates,
who was a judge, posed the following question to the contestants:
    "What contest, held via Usenet, is dedicated to examples of weird,
obscure, bizarre, and really bad programming?"
    After a moment of silence, Jean-Louis Gassee (ex-honcho at Apple)
hit his buzzer and answered "Windows."
                                          --Recounted by Adam C. Engst

---

From: Randall Gellens <[email-masked]>
Date: Mon, 27 Jul 2009 01:54:41 -0700

>  that might be larger than they were led to expect, and they can code

If the size is an approximation and used only as advice by the 
client, it should be fine.  The danger is if a client relies on it to 
know if it has the entire message (in violation of POP), for example.

-------------- Randomly selected tag: ---------------
As you know, any depiction of nasal mucus brings with it problems for
our sales division.
    --ABC's Broadcast Standards & Practices board, to producers of the
    cartoon "Bump in the Night"

---

From: Randall Gellens <[email-masked]>
Date: Mon, 27 Jul 2009 01:57:27 -0700

At 2:32 PM +0100 7/22/09, Alexey Melnikov wrote:

>  If we want to keep the SHOULD, your last point ("Because clients 
> have to be changed to ask for this anyway") needs to be explicitly 
> spelled out. I am not sure how existing clients are using results 
> of the LIST command. I also think that in this case the document 
> needs to say that messages sizes MUST be consistent (i.e. for a 
> given message the server must return the same size in LIST all the 
> time).

More text making it clear that sizes in POP should be advisory could 
be helpful.  I'm not sure why the size needs to be consistent, 
though.  For example, if a server uses a guestimate initially, but 
then does a conversion and learns the exact size, why shouldn't it 
start returning the exact size?

-------------- Randomly selected tag: ---------------
Language is a virus from outer space.  --William S. Burroughs

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 27 Jul 2009 11:04:08 +0200

Randall Gellens wrote:

>> spelled out. I am not sure how existing clients are using results of 
>> the LIST command. I also think that in this case the document needs 
>> to say that messages sizes MUST be consistent (i.e. for a given 
>> message the server must return the same size in LIST all the time).
>
> be helpful.

Right.

> I'm not sure why the size needs to be consistent, though.  For 
> example, if a server uses a guestimate initially, but then does a 
> conversion and learns the exact size, why shouldn't it start returning 
> the exact size?

Ok, this is a convincing argument.

My concern was about clients caching message sizes between sessions, 
maybe to help identify messages uniquely. But that might not be a real 
problem.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 27 Jul 2009 11:05:40 +0200

>>  Should this have an Informative reference to RFC 4422?

Yes, indeed.

> Indeed so, including a SHOULD for SASLprep in 5034.

See my other reply on this. I don't think the document need to say 
anything normative about AUTH.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 27 Jul 2009 02:20:23 -0700

> anything normative about AUTH.

I agree with what you said elsewhere (the POP draft should take out 
text about AUTH).

-------------- Randomly selected tag: ---------------
Ever notice that people who are late are much jollier
than the people who have to wait for them?

---

From: Randall Gellens <[email-masked]>
Date: Mon, 27 Jul 2009 04:52:24 -0700

At 11:04 AM +0200 7/27/09, Alexey Melnikov wrote:

>  My concern was about clients caching message sizes between 
> sessions, maybe to help identify messages uniquely. But that might 
> not be a real problem.

We have a unique identifier (UID) for that :-)

-------------- Randomly selected tag: ---------------
When we remember we are all mad, the mysteries disappear and
life stands explained.                          --Mark Twain

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 27 Jul 2009 15:00:32 +0200

Randall Gellens wrote:

>> maybe to help identify messages uniquely. But that might not be a 
>> real problem.
>

Which don't have to be unique among all messages in POP, as far as I 
remember...

---

From: Randall Gellens <[email-masked]>
Date: Mon, 27 Jul 2009 09:38:03 -0700

At 3:00 PM +0200 7/27/09, Alexey Melnikov wrote:

>>> sessions, maybe to help identify messages uniquely. But that 
>>> might not be a real problem.
>>
>  Which don't have to be unique among all messages in POP, as far as 
> I remember...

RFC 1939 requires that UID "uniquely identifies a message within a 
maildrop and which persists across sessions".

Besides, clients creating their own UIDs are more likely to hash 
selects headers than to consider size, in my opinion.

-------------- Randomly selected tag: ---------------
Never doubt that a small group of thoughtful, committed citizens can
change the world.  Indeed, it's the only thing that ever has.
                                                     --Margaret Meed