Date: Wed, 29 Jan 2003 12:45:12 -0600
From: Pete Resnick <presnick@qualcomm.com>
Message-ID: <p0600010cba5dc6d587ee@[216.43.25.67]>
First, I have now seen that the draft charter I was commenting on was
not the correct one, but for the two things I was most concerned about,
there doesn't seem to be much difference of substance...
| No, that's not what this means. Actually, it's probably just the
| opposite of what you fear.
OK. That's much more reasonable. Now, what is needed is for the
charter to actually say that, instead of implying that (one possible)
result would be to use IMAP as a streaming video source...
Perhaps rather that the rather specific (yet imprecise) "satisfy the
requirements for streaming playback of multimedia content" what it
should be saying is something more like "allow referrals to more
appropriate protocols for retrieval of content" (or something).
| The solution is not known. The problem is that there is currently no
| standard mechanism for mail servers to announce the existence of new
| mail. Current protocols rely on polling or a constant connection to
| the mail server. The work item is to come up with a protocol that
| does notifications. Does the above not describe that work item
| appropriately?
It presumes that such a protocol is the answer to something, and can
necessarily be delivered.
This looks to me to be not unrelated (in some ways) to what the msgtrack
people were working on.
If all you really want is to formalise a (rational) method to implement
biff, then that's fine, but "message status information" might be much
more than that. As written it suggests more like a way for servers to
let other servers know when messages have been delivered, read, ... (etc).
If "announce the existence of new mail" is really the objective here,
then how about something more like
Provide a mechanism that allows mail arrival to be detected
without requiring polling.
kre