At 09:25 06/23/97 PDT, Larry Masinter wrote:
>> 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.
I think that there are several important differences with printing from
browsing:
1. Clients are less likely to remember capabilities of previously accessed
Printers, since the performance gain in such caching is not as great as with
browsing. They may do a Get-Attributes anyway before submitting. And if
they don't an immediate rejection could be the trigger for a client that doea
cache to invaidate that cache and do a rediscovery Get-Attributes.
2. Administrators are less likely to take away capabilities of Printers, since
it will impact users (no matter what we do in the protocol).
3. If a single virtual provider is fronting for several actual providers, and
gets an attribute that is supported by one but not by another, the virtual
provider MUST forward the job to the actual provider that can handle the job.
So the bottom line of requiring an IPP Printer to reject an operation,
rather than ignore an unsupported (or unrecognized) attribute, is simplicity
of the protocol. With discovery, a client can still use an extension
(though we may need some more discovery meta-attributes in order for a client
to "understand" a new attribute). Such meta-attributes are NOT for version
1.0 of IPP. We can add them later as extensions themselves.
On the other hand, a client must ignore attributes its gets from a
Printer, that the client doesn't understand (or maybe dump them out as
not recognized ASCII), rather than refusing to understand the rest of the
response from the Printer, or else we will have real trouble extensing IPP.
>>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>>>>