Charles McCathieNevile wrote:
It's true that it makes no sense to standardise something that isn't
going to get implemented. Opera are also concerned that there may be
security implications in allowing any random verb.
Please be more specific. POST today allows *anything*. It's not a safe
method, and basically *anything* can be done with it (-> SOAP). On the
other hand, other extension methods defined in standards track RFC do
have strictly defined semantics, and usually none of these are a
security risk (otherwise they wouldn't have passed IESG review).
We can provide a list of verbs that MUST be supported, and say that
implementations should allow other verbs, (that's something that should
be in extensibility anywa, and we will probably get comments from Karl
Dubost or W3C QA), but note for authors that implementations may not do
this, for example due to security concerns.
Why can't the spec just be silent about it? If there's a "SHOULD" to
support other methods, then I think a white-list approach wouldn't be
compliant.
This allows for implementations that restrict the set of available
verbs, and also allows development that remains conformant with the
specification. From time to time there are new verbs that people like,
and even if not every implementation offers them, their development is a
Good Thing™...
The problem here is that by having to update user agents to support
them, this working group restricts the ability of other standards bodies
to use new HTTP methods as extension point. We've already seen people
going to the CalDAV mailing list (after last-call...) asking to drop the
use of the REPORT method because of WEBAPI.
Besides, I am with Mark on the principle that standardising things based
on security is generally something this group should not do. There are
many different security models and approaches on the web, and in order
to make documents that are usable in implmentations it is helpful to
allow for this, where possible.
Since security will virtually always trump standards conformance for
implementors (there are use cases for providing insecure systems too),
when we choose how to standardise current practice we should be wary of
following restrictions imposed for security over openness desired for
some use cases.
Trading off too much functionality for totally compatible
interoperability eventually comes at the cost of assuming no new
development or innovation, which would be a bad thing (and symbolic of a
struggle against reality - developers *will* innovate). That said, this
is something that generally comes to a case-by-case analysis of the
particular problem...
(agreeing with the remainder)
Best regards,
Julian
