Carl-Uno,
The new draft proposal looks pretty good. Some comments on a few
things in your new draft text:
> The working group shall coordinate its activities with other
> printing-related standards bodies.
Perhaps the sentence could read: "The working group shall strive to coordinate
its activities with other printing-related bodies."
We certainly don't want anyone to believe that our schedule could be
significantly impacted due to possible scheduling problems of such
related bodies, right? This issue is further implicated in another
comment below.
> The working group shall define solutions that do not preclude the
> notion of multi-tiered configurations consisting of both logical and
> physical printers.
Saying that our efforts shall not preclude other concepts could be
interpreted the wrong way. Do we really mean that our solutions
shall not _necessarily_ preclude such concepts? I'm not really mincing
words here. A fear that might arise (based on the many, many months
trudging thru the Job Monitoring MIB) is one in which a group claims
that our solution does not fit their particular model of the printing
universe. What then?
> Also, the new job submission protocol should not
> preclude submitting jobs to any type of output device (e.g., fax,
> printer, gateway).
This, too, sounds like an ultimate rat-hole, depending on how hard
those "other printing-related standards bodies" wish to push their point.
We know of at least one visible standards body that firmly believes that
printing and faxing should be much, MUCH closer than they are now in terms
of standardization. Again, perhaps the sentence should be modified to
say something like "...should not strive to preclude..." so that we can
head-off those kinds of problems.
> Also, the working group shall define extensibility
> paths so that similar extensions will interoperate and proprietary,
> dissimilar extensions will never conflict.
Extensibility paths would be truly excellent. I'll admit that I have
not done due diligence on the proffered documentation, but I don't
recall us talking about this topic. Can such "paths" be defined in the
bullish schedule we've set? Can anyone else make a few comments on
exactly what these extensibility paths would/could be?
> This working group may define work that will replace RFC 1179 'Line
> Printer Daemon Protocol'. LPR/LPD was designed a long time ago with
> line printers in mind. It does not fit with current page oriented
> printing technologies.
I agree with Bill Wagner's comments on how our solution should be viewed
in comparison with RFC 1179. If we intend to supplant RFC 1179, then we
should flatly make such a statement and not beat around the bush. If we
are all trying to get the world to move away from 1179, then let's be
forthright in that regard.
> Deliverables and Milestones:
>> Done
> Mailing list and archive
>> November 1996 - Submit first set of Internet-Drafts
>> December 1996 - BOF in IETF meeting in San Jose, CA, USA
>> March 1997 - Submit Internet-Drafts
>> April 1997 - Review of specification in IETF meeting in Memphis, TN, USA
>> May 1997 - At least 2 implemented protypes
>> May 1997 - Submit document to the IESG for Proposed Standard
A very aggressive schedule, indeed. What I find interesting is the
entry for May 1997 in which two prototypes (note spelling error) are
to be implemented. This is very aggressive indeed...but I'm hoping
such a plan doesn't preclude open-minded consideration of the issues
and potential solutions.
In order to accomplish such an aggressive engineering schedule, it just
seems that some folks might not be too willing to entertain
ideas/concepts/issues/solutions that haven't already been cooked up in
the back room over the last several months.
Some of us in the PWG have been waiting a very long time to begin
addressing print submission-related standards, but felt that we had
to wait until the first pass at device management-related standards
were completed (ie, the Printer MIB, etc). To now have such a new
submission-related standards effort spring up *so* quickly--and with
such an aggressive schedule that includes working prototypes--is a
bit scary. It makes us wonder whether our concerns and interests
will be properly considered by the many "new" folks deeply involved
in the IPP project.
Just some comments for consideration. I know I am not alone in expecting
that the IPP effort--as with all other PWG efforts--is one revolving around
OPEN standards, and not just thinly veneered attempts to justify proprietary
goals.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm at underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03015-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------