Subject: [lemonade] responses to GENURLAUTH in URLAUTH

From: Peter Coates <[email-masked]>
Date: Mon, 03 Apr 2006 11:05:12 -0700

It may me me being not very clever, but I am not certain what the
specifications expects me to do if a GENURLAUTH command carries 2 or more
URL/mechanism pairs, and some are good and some are bad.  The specification
seems to suggest that the error response is a tagged response, but the error
is per URL.  I see several ways to interpret the spec.  The way I like is to
allow the server to sent untagged GENURLAUTH for each good URL/mechanism
pairs, then a tagged BAD for the first URL/mechanism in error.  But then I'm
a server guy, not a client guy.  From a client point of view, the preferred
solution is a mechanism by which the error response indicates which URL was
in error.
 
Peter

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Mark Crispin <[email-masked]>
Date: Mon, 3 Apr 2006 11:17:36 -0700 (PDT)

If something generates a BAD response, then it is a syntax error that was 
detected during command processing.  Full stop.  Do nothing.  This is 
basic to the IMAP architecture.

IMAP is a little bit more generous with NO responses; but even then the 
protocol strongly discourages partial success behavior.  For example, COPY 
and multi-APPEND aren't allowed to do some messages but not others.

Put another way, since GENURLAUTH's validation is defined as returning BAD 
instead of NO upon failure, this is a syntax validation.  Therefore, the 
list of URLs must be collected and validated prior to generating any 
responses.

A debugged client should never get a BAD from GENURLAUTH.  Like other BAD 
responses, this is not something that software-based error analysis can 
fix; this is something that is remedied by fixing the broken code that 
sent the command that led to the BAD response.

> solution is a mechanism by which the error response indicates which URL was

-- Mark --

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

---

From: Mark Crispin <[email-masked]>
Date: Mon, 3 Apr 2006 11:26:50 -0700 (PDT)

On Mon, 3 Apr 2006, Mark Crispin wrote:
> detected during command processing.  Full stop.  Do nothing.  This is basic 
> to the IMAP architecture.

There is a corrolary to all this.  If it is intended that, for a 
particular error condition:
  1) the client should be able to analyze the error and determine what is
     wrong
OR
  2) the command may partially execute and have some side effect even
     though overall it fails
then the specification for that command MUST define that this condition 
generates a NO response and MUST NOT define that it uses a BAD response.

The difference between NO and BAD is not cosmetic.  It has a definite 
purpose: segregating operational errors from buggy protocol.

If it is felt that that failed validation of GENURLAUTH is an operational 
error rather than a protocol syntax error, then we need to change that BAD 
response to a NO and probably also define some sort of error reporting 
mechanism.

I don't think that it's an operational error.  It seems to me that a 
client is fully capable of preventing the error condition.

-- Mark --

http://panda.com/mrc

---

From: Peter Coates <[email-masked]>
Date: Mon, 03 Apr 2006 11:36:58 -0700

That is all very well, and in in accord with my understanding of the
protocol.  But it is a  pain in this instance.  Further, if the server
chooses to implement the check
(4) the server MAY also verify that the Message-ID and/or
            second components (if present) are valid.
Then it is not necessarily a client error if the URL is incorrect.  That
then requires a NO response, and I'd say it was perfectly valid to send the
untagged success responses to earlier good URLs.  (the spec says that this
case requires a BAD response)

Further, sending untagged GENURLAUTH to good URLs before finding a URL that
is unsatisfactory in some way is not an action that changes the state of
either the server.  It ought, in that case, to be an acceptable action.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark
Crispin
Sent: April 3, 2006 11:27
To: Peter Coates
Cc: [email-masked]
Subject: Re: [lemonade] responses to GENURLAUTH in URLAUTH

On Mon, 3 Apr 2006, Mark Crispin wrote:
> If something generates a BAD response, then it is a syntax error that 
> was detected during command processing.  Full stop.  Do nothing.  This 
> is basic to the IMAP architecture.
> IMAP is a little bit more generous with NO responses; but even then 
> the protocol strongly discourages partial success behavior.  For 
> example, COPY and multi-APPEND aren't allowed to do some messages but not
others.

There is a corrolary to all this.  If it is intended that, for a particular
error condition:

I don't think that it's an operational error.  It seems to me that a client
is fully capable of preventing the error condition.

-- Mark --

http://panda.com/mrc

---

From: Dave Cridland <[email-masked]>
Date: Mon, 03 Apr 2006 19:57:20 +0100

On Mon Apr  3 19:36:58 2006, Peter Coates wrote:
> protocol.

Indeed - Mark's summary made for good reading.

>   But it is a  pain in this instance.  Further, if the server

Is this text actually meant to be this way?

Is "Message-ID" intended to read "message", and "second" intended to 
read "section"? Or am I missing something?

> case requires a BAD response)
Yes, a BAD response cannot happen after the server has accepted the 
command. If you cannot reasonably accept the command until after 
check 4, then don't perform check 4. (In particular, you can choose 
to only perform check 4 when the client has the mailbox selected, 
when a failure of check 4 does indeed mean a client error).

> either the server.  It ought, in that case, to be an acceptable 

Ah, but here's a curiosity for you. BAD indicates that the command 
was not processed at all - therefore you cannot, technically, emit 
EXPUNGE messages, and any GENURLAUTH messages must be assumed by the 
client to be unilaterally sent. Moreover, whilst it's likely that 
existing URLAUTH mechanisms don't have side-effects, that may not 
always be the case.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

---

From: Peter Coates <[email-masked]>
Date: Mon, 03 Apr 2006 12:09:16 -0700

I accept most of your points.  I'm not sure I agree about a failure under
check 4.  There is nothing to stop a message being deleted and expunged in
some other session unbeknownst to the poor client.  This really feels like a
"NO" case rather than a "BAD" case.  Either the protocol should allow for a
"NO" response or check 4 be precluded.

And it is a good indicator of my proof reading ability that I missed the
errors in the wording for check (4).

-----Original Message-----
From: Dave Cridland [mailto:[email-masked]] 
Sent: April 3, 2006 11:57
To: Peter Coates
Cc: Enhancements to Internet email to support diverse service enivronments;
Mark Crispin
Subject: RE: [lemonade] responses to GENURLAUTH in URLAUTH

>   But it is a  pain in this instance.  Further, if the server chooses 
> to implement the check

Is "Message-ID" intended to read "message", and "second" intended to read
"section"? Or am I missing something?

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 03 Apr 2006 20:19:55 +0100

> "NO" response or check 4 be precluded.
It's only a MAY.

For sections, I think a client basically has to know that the section 
exists before trying to do anything with the signed URL, and even in 
my more nefarious moments, I can't think of a use for using 
GENURLAUTH on sections which don't exist, or even on sections I 
simply haven't verified the existence of.

For the message itself, it depends on how your store works, and, in 
particular, whether an EXPUNGE in another session causes the message 
data to be unavailable immediately to concurrent sessions, or whether 
other sessions still have access. The client certainly believes the 
message not only exists, but will remain in existence for a 
substantial amount of time.

As an asmuing aside, you can't tell the client about the expunge 
until after accepting the command, incidentally - that is, you can't 
say "* 14 EXPUNGE", followed by a tagged BAD, because you can't send 
an EXPUNGE unless there's a command in progress, and by issuing a 
tagged BAD, you're indicating that the command was never accepted.

> errors in the wording for check (4).
Yes, I only noticed it halfway through typing my response - I wanted 
to match the terms Mark used, and realised it didn't make sense.

Dave.

---

From: Mark Crispin <[email-masked]>
Date: Mon, 3 Apr 2006 12:28:25 -0700

On Mon, 3 Apr 2006, Peter Coates wrote:
> There is nothing to stop a message being deleted and expunged in
> some other session unbeknownst to the poor client.

Yes there is.

Until the expunge is announced with an untagged EXPUNGE response, the 
message still exists as far as the server is concerned; and an untagged 
EXPUNGE in turn can't be sent except at certain well-documented points in 
the session.

-- Mark --

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

---

From: Mark Crispin <[email-masked]>
Date: Mon, 3 Apr 2006 12:30:50 -0700

On Mon, 3 Apr 2006, Dave Cridland wrote:
> particular, whether an EXPUNGE in another session causes the message data to 
> be unavailable immediately to concurrent sessions, or whether other sessions 
> still have access.

I never, ever, approved of the former behavior.  Such behavior is wrong 
from an architectural standpoint -- and equally importantly is proven to 
break clients.

> The client certainly believes the message not only exists, 
> but will remain in existence for a substantial amount of time.

Correct.

-- Mark --

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 08 Apr 2006 23:26:43 +0100

Mark Crispin wrote:

> message still exists as far as the server is concerned; and an 
> untagged EXPUNGE in turn can't be sent except at certain 
> well-documented points in the session.

This only works if the client that requested generation of URLAUTH URLs 
is the same client as the one who is using URLFETCH. (And even this 
might not work for offline clients)
This is not the case for BURL capable submission server retrieving 
messages using URLAUTH URLs.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 10 Apr 2006 13:33:54 +0100

Alexey Melnikov wrote:

> This only works if the client that requested generation of URLAUTH 
> URLs is the same client as the one who is using URLFETCH. (And even 
> this might not work for offline clients)

Never mind, I was thinking about URLFETCH.