Subject: RE: [lemonade] IMAP Channel draft updates

From: Erev Ari <[email-masked]>
Date: Wed, 10 Sep 2003 10:23:20 +0300

Lyndon,

You answered Eric, that the "push" vs. "pull" differentiation can be
underdstood from the client that provides the URL.

>> How would ftp push work?

>By giving a fully specified URL. E.g.,
>
>  0 CHANNEL 1 ftp://example.com/filename.

However, this means that when the server announces support for FTP (e.g. in:
CHANNEL=imap,ftp), it needs to support each protocol both as a server as
well as a client (as it does not know yet what URL the client will provide
later, in the CHANNEL command).

I can see cases where a server would choose to support (for example) ftp
only as a server and not necessarily as a client.
There is no provisioning to announce this capability right now.

Also - see my comments below.

Regards,
Ari

> -----Original Message-----
> From: Lyndon Nerenberg [mailto:[email-masked]]
> Sent: Wednesday, September 10, 2003 2:48 AM
> To: Erev Ari
> Cc: [email-masked]; [email-masked]
> Subject: RE: [lemonade] IMAP Channel draft updates
> 
> 
> > It would be nice IMHO if the protocol schemes supported 
> would have an
> > indication whether the protocol supported is a "push" or 
> "pull" type.
> 
> I'm not sure this is a good idea. It requires the IMAP server to have
> knowledge of the external service provider, which places an 
> implementation
> burden on the IMAP server -- it forces a much tighter 
> coupling between the
> two.

Why? Doesn't the channel-announcement (provdied by the imap server) need to
reflect exactly which protocol "the system" supports and whether they are
push (ie. servers) or pull (i.e, clients)?
(the system, being the collection of servers, and protocol clients in this
installation/site implementing the support for the announced channel
protocols).
After all, "something" in the system whether it is the imap server itself,
or other servers) will need to support the actual functionality.

> 
> Push vs. pull is really an attribute of the scheme itself. IMAP itself
> shouldn't be announcing these sorts of attributes, and in 
> many cases it
> won't know what they are, anyway.
Maybe the server does not "know" what they are, but the system of which the
imap server is part of (together with the other protocol servers and/or
client) is a finite one. So, the channel capabiliy announced by the imap
server should reflect the actual servers/clients that the "system" can
support.
> 
> If a client wants a push, it can just issue the command. If 
> that fails, it
> can re-issue the request as a pull. Or pull and fall back to 
> push. Or fall
> back to a different scheme.
> 
> --lyndon
>

---

From: Lyndon Nerenberg <[email-masked]>
Date: Fri, 12 Sep 2003 14:23:32 -0600 (MDT)

> later, in the CHANNEL command).

No, and this is where I think we have a disconnect.

Just because an IMAP server advertises ftp as a Channel scheme does NOT
mean the IMAP server implements the ftp protocol itself. Imagine an
interface whereby you could arbitrarily attach "scheme modules" to an IMAP
servers channel mechanism. This would be through (say) an API where the
IMAP server passes a message reference and the suggested URL (from the
client) to an external via the API. The outside service would reply with
the URL representing the actual message as expressed by the scheme (or a
failure code). The IMAP server cannot know ahead of time if any specific
URL passed to it by the client will be honoured (or honourable) by the
external scheme server.

The only way the IMAP server could correctly indicate the push/pull
semantics of a particular scheme is if it was fully cognizant of the
scheme. With an external API-based interface, you cannot guarantee this,
therefore I'm very reluctant to require this functionality in the
specification.

--lyndon

If we do not succeed, then we run the risk of failure.
			-- Vice President Dan Quayle

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

---

From: [email-masked]
Date: Fri, 12 Sep 2003 14:30:58 -0700

Hi Lyndon,
	A question in line.

>URL passed to it by the client will be honoured (or honourable) by the

	I don't think I understand what "The outside service would
reply with the URL representing the actual message as expressed by the
scheme" means or would buy you.  Let's say we have a channel support
advertisement for imap,https.  The IMAP server passes the reference
https://secure.example.com/message-id=GIGO12345 to an external
service.  What does the outside service reply with?  Does it reply immediately,
or only after dereferencing the URI?

>therefore I'm very reluctant to require this functionality in the

	I'm not sure I follow this logic either.  If the IMAP server is
advertising support, presumable we have some minimal level of protocol
processing (it can read scheme names and pass them to the appropriate
handler).  It doesn't seem unreasonable for that protocol processing to
include basic knowledge of the result code semantics on a per protocol
basis, so that it can register success vs. failure.  It might not need to
understand the full protocol semantics, but knowing that the 2xx series in
HTTPS is a success and the 4xx a failure does seem useful.
	There are, of course, other issues in that--hold the process
while you wait for success or failure and you create conditions for a
denial of service.  But there may be some place in the trade off other
than "no results expected".
			regards,
				Ted Hardie