Dennis,
While it may be a good idea to move all OPTIONAL (Printer MAY):
operations,
Operation attributes
Document Temploate attributes
Document Description attributes
Printer Description attributes
and leave only REQUIRED (Printer MUST and CMUST support). I think that the
REQUIRED document would be very thin: Just the REQUIRED operations and
attributes and maybe the CONDITIONALLY REQUIRED Document Object attributes.
Note that this would move out ALL Document Template attributes, since they
are all OPTIONAL.
The down sides are:
1. It would be a significant hardship on the editor to have to keep moving
things back and forth between the two documents as we agrue about whether to
make them REQUIRED or OPTIONAL.
2. Such a massive reorganization would take a lot of time and we are trying
to get the Document object spec out.
BTW,
I see very little support for each of the 4+2+1 increases in conformance
requirements that are out for the 2 week review, so maybe the spec won't
change much as a result of those proposals, since they are coming under
fire.
A slightly different suggestions on yesterday's IPPFAX telecon was to move
out into a separate short spec the few Operation attributes and their
corresponding Printer Description attributes that an implementation would
find useful to implement without having to implement any of the Document
Object operations. They would all be OPTIONAL in this new separate thin
spec. The Document Object spec can then make some of them MUST or CMUST as
in the current Document Object spec.
These Operation attributes include:
1. "job-mandatory-attributes"
These Operation attributes and their corresponding "xxx-default", and
"xxx-supported" Printer attributes would be useful in Print-Job, Print-URI,
Send-Document, Send-URI even without the Document object:
2. "document-charset", "-default", "-supported"
3. "document-digital-signature", "-default", "-supported"
4. "document-format-details", "-default", "-supported", "-implemented"
5. "document-format-version", "-default", "-supported"
(They would have coresponding Document Description attributes indefined only
in the Document Object spec, along with "compression", "document-format",
and "document-natural-language" Document Description attributes).
Tom
-----Original Message-----
From: Mike Sweet [mailto:mike at easysw.com]
Sent: Monday, April 21, 2003 14:09
To: Dennis Carney
Cc: sm at pwg.org; ps at pwg.org; ipp at pwg.org
Subject: Re: IPP> 2 more significant proposed increases in conformance
requirements for the IPP Document object spec
Dennis Carney wrote:
>>>> This might be an awful idea, so feel free to shoot it down with vicious
> force...
>> Based on the desire to have extensions that do not include OPTIONAL items,
> might it make sense to break the current Document object spec into two:
> - The "Base Document object" spec, which defines the basics of the
Document
> object and has no OPTIONAL items: everything is mandatory. This would
make
> interop a breeze, and would hopefully also encourage adoption since the
> spec would hopefully be relatively small.
> - The "Extended Document object" spec, containing all the currently
> OPTIONAL items. This spec *could* also make all the extensions mandatory
> (I would think that making absolutely *everything* mandatory would
> discourage adoption, however).
>> The process of going through the current spec to determine which items are
> "Base" and which are "Extended" might also result in determining which
> items aren't "Document object" items at all.
> ...
How about the following:
1. Put the non-document object stuff into a separate IPP
extension spec (I think that would just be the changes
to Get-Jobs - I'll review to see if there are others)
2. Remove the REQUIRED status from the URI-based document
operations and publish the document object spec (with
any other changes that come up after reviewing it)
3. Publish a new PSI spec which adds additional requirements
for IPP conformance in a PSI environment; this spec would
reference all of the applicable IPP documents and provide
"one-stop-shopping" for someone that wanted to determine
conformance for PSI.
No matter what way we go, I still think we'll need another round
of document review before we go to last-call and voting.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com