> Could you elaborate on why you think that the requester needs to be
> able to flag each supplied attribute as to whether it is a
> compulsory (what you call mandatory) or is non-compulsory (what you
> call optional) in order to achieve extensibility.
HTTP has had the notion of 'ignore any header you don't understand'
as its extensibility mechanism. It's allowed lots of extensions
while also allowing older implementations to interoperate. However,
there've been cases where that kind of extensibility has gotten
in the way.
> IPP has dropped the idea of allowing the requester to be able to
> indicate. Now IPP requires the provider to reject the request if there
> are any values that the provider doesn't understand.
> The requester
> then needs to fix up the request until the provider can accept all
> values. The requester can query the provider to determine all supported
> values of all attributes that the requester can supply.
If the provider MUST reject any values it doesn't understand, requestors
will likely NOT include any extensions in requests, lest it pay
the cost of mainly having its initial requests rejected. The
problem with prospective discovery (remember from the past whether
this provider understands this extension) is that it is fragile:
provider's capabilities can change, but the timeout of cached
capabilities isn't explicit; a single virtual provider might front
for several actual providers, but the capabilties might be variable.
This is mainly an issue for HTTP-NG, I think, but IPP is a good
example of the kind of extensible protocol we'd like to support in the
NG effort.
Larry
--
http://www.parc.xerox.com/masinter