At least from a process point-of-view, it would just require a 4 week last call.
Even if a WG were formed, it could have a narrow scope. it would not need
to consider every proposal for a change or extension to HTTP.
At this point of time, I have not idea of what it takes to make a WG, a proposal and get it approved.
However, as you mention about "a narrow scope" - I would like to just give an example supporting this. RFC 821 details SMTP. RFC 2554 is entitled "SMTP Service Extension for Authentication". A very small extension to 821.
That's not what I meant by "narrow scope". By "narrow scope" I meant that a WG could be chartered for only the purpose of developing a better authentication method for HTTP, and forbidden to develop any extensions for HTTP that were not needed to provide better authentication. (IMHO, creating a new HTTP extensions WG would be to open Pandora's box)
Regarding your SMTP analogy, I don't think it is the case that adding another authentication flavor to HTTP is as simple as it was to add authentication to SMTP - first, because HTTP is much more complex than SMTP (especially in how it negotiates protocol options); second, because SMTP has a much cleaner extension model than HTTP (thank you mtr); third, because the relationships between principals tend to be different for HTTP than for SMTP; and fourth, because in the case of HTTP servers there is a significant investment in existing authentication databases and the types of credentials they support which did not exist for SMTP when authentication was added to it.
Keith
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf