> 3. Have you considered the alternative of defining a new method, say,
> PRINT, with entity headers appropriate for the new task?
>
> Yes, we did consider this. In speaking with some of the people involved
> in HTTP, it was their recommendation to NOT extend the set of HTTP
> methods. Do you see any strong benefits to doing so? We were
> concerned about forcing a rev of HTTP to support this.
The MMUSIC group is currently considering extending HTTP for conference
control (see my RTSP draft and a yet-to-be-published conference
initiation draft). We'll discuss this with the HTTP WG chair, but our
impression is that extending HTTP does not necessarily imply changing
the base draft. The advantage is conciseness and the immediate ability
to extend web servers to do the job. Your method is then a "first-class
citizen", with appropriate access control, query about existing methods,
etc..
>
> Thanks for your input.
>
> Scott Isaacson
>
> ************************************************************
> Scott A. Isaacson
> Print Services Consulting Engineer
> Novell Inc., 122 E 1700 S, Provo, UT 84606
> V: (801) 861-7366, (800) 453-1267 x17366
Henning Schulzrinne email: schulzrinne@cs.columbia.edu
Dept. of Computer Science phone: +1 212 939-7042
Columbia University fax: +1 212 666-0140
New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs