RE: Optional Extensions

As much as I dislike 'SHOULD' (my personal rule is that it's mandatory or
it's not in the spec) I think in this case SHOULD is appropriate. The whole
point of 'SHOULD' was to say that you really should behave a certain way
unless you have a really good reason not to. That would seem to apply here.

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> Behalf Of Mark Baker
> Sent: Wednesday, January 28, 2004 12:48 PM
> To: www-ws-desc@w3.org
> Subject: Re: Optional Extensions
>
>
>
> On Wed, Jan 28, 2004 at 11:58:27AM -0800, Prasad Yendluri wrote:
> > Good point. What if the definition of the optional
> extension is "faulty"
> > :).
> > Well I guess we would have come full circle on this if we
> do end up with
> > optional extensions MAY be ignored.
>
> What's important here is that an expectation be created amoungst
> would-be extenders that their extensions won't break existing
> software.
> "MUST" definitely does that. "SHOULD" does too, though less
> emphatically.  "MAY" does not; you might have noticed that
> RFC 2119 does
> not define "MAY NOT", as it's semantically equivalent to "MAY".
>
> FWIW, HTTP uses SHOULD, and that seems to suffice;
>
>    The extension-header mechanism allows additional
> entity-header fields
>    to be defined without changing the protocol, but these
> fields cannot
>    be assumed to be recognizable by the recipient. Unrecognized header
>    fields SHOULD be ignored by the recipient and MUST be forwarded by
>    transparent proxies.
>     -- http://www.ietf.org/rfc/rfc2616, sec 7.1
>
> So, does "SHOULD ignore" work for everyone?
>
> Mark.
> --
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
>
>

Received on Wednesday, 28 January 2004 17:24:16 UTC