Re: Interesting (gross?) use of CHANNEL

On 3/6/02 at 11:35 PM -0700, Lyndon Nerenberg wrote:

>Urgh. If you mailto:, I would expect the server to simply BARF the 
>request back to you.

The scenario assumes that the server has advertised "CHANNEL=mailto" 
in the capabilities.

>Unless, in some bizarre circumstance, it made sense to honour the request.

Why would this request be absurd?

>>In my ideal picture, the server would take the message and prepend 
>>Resent-* fields using the destination and whatever other fields are 
>>specified in the URL.
>
>No! The draft does not mention it, but the (my) intent is that the 
>server (or anything else in the data path) canNOT mess with the data 
>content in any way.

Um, this is just nonsense. Of course when you send the data to RTSP, 
for example, you're going to send all of the appropriate RTSP 
commands and then you send the data down the pipe. If it helps, make 
believe that you are channeling the message to a process that handles 
the mailto, and that process is the one that prepends Resent-* 
fields. Remember, what comes after the Resent-* fields is the 
original data, completely unmodified.

>>You would, of course, only be able to CHANNEL to mailto for an 
>>entire message or for a subpart which was itself of type 
>>message/rfc822. This seems to me an ideal way to implement the 
>>Resend command in many clients, and could even be used to send 
>>draft messages out for the first time.
>
>Yuk. No. Again, CHANNEL is NOT alowwed to modify the data content in ANY way.

What data content is being modified here? You are simply sending the 
data (unchanged) to another process which is going to do something 
with it. In some cases, that will be "Play the sounds to the user 
using a speaker". In my case, it will be "Send this data via SMTP". 
What's the problem?

pr
-- 
Pete Resnick <mailto:[email protected]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102