Subject: Re: IPP> extensibility

From: Tom Hastings <[email-masked]>
Date: Thu, 19 Jun 1997 11:21:31 PDT

Larry,

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.

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.

Thanks,
Tom

At 13:10 06/09/97 PDT, Larry Masinter wrote:
>For good extensibility and interoperability, you need both
>manditory parameters ("reject this job if you don't understand
>this parameter") and optional ones ("if you don't understand
>this, just ignore it").
>
>A recipient must be able to tell just by examining the
>attribute which class it is in.
>
>I thought this was part of the whole job/PDL parameter override
>issue, but it looks like I must have missed something.
>
>Larry
>
>

---

From: Larry Masinter <[email-masked]>
Date: Mon, 23 Jun 1997 09:25:04 PDT

> 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.

> are any values that the provider doesn't understand. 

> The requester

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