Scott, here are my comments on the presentation:
o Background Chart
do we need to list individual pointers at this point? I'd suggest
a separate page with all of the reference material, including
how to subscribe to the discussion group and what can be
found at the ftp-site.
o ISO/IEC 10175 DPA chart
- Dazzle should be Dazel
- Please include IBM's Printing Systems Manager
o Synergy chart
The fact that we agreed on an approach and completed the
initial draft in 12 days (thanks to Scott's hard work) clearly shows
that we have gotten to consensus quickly. However, I'd feel
more comfortable just saying "Quick Consensus", perhaps some
will not take the proposal seriously when we say it only took 12
working days to produce.
Should the "simplified" bullet include the fact that the first version
of the standard is intended to support only end-user operations?
If not, should we say that explicitly elsewhere, since Don's
requirements presentation will list all of the roles?
Should we list some (or all) of the companies involved? I think
it would add credibility.
o What is IPP? chart
Should the bullet HTTP 1.0 say "Built (or based) on HTTP 1.0" to
be consistent with the prior bullet?
Should we say here that the proposal uses simple ascii encodings,
for those familiar with DPA and the Printer MIB, who might expect
to see ASN.1 or OIDs?
o Generic Distributed Printing chart
I made a similar comment on Don's charts -- would pictures here
provide a more meaningful way to present this infomation? I like
pictures personally, it helps me to see the relationships of things.
The same chart (or a modified/colored) version could then be
used to talk about the IPP printing model. This would make clear
which components of the printing system have been modeled as
IPP Objects.
o IPP Operations
At this point do we need quotes around the word documents? I
have a feeling we may get into trouble with the IPP notion of an
object vs. things that IPP deals with. We can clearly print multiple
documents in a job. The fact that we don't define a document as
an IPP object is confusing.
o Printer chart
I suspect that you will say this as you present the chart, but it is not
clear from the words on the chart that the abstraction we call a Printer
includes functionality often supported in a print server, e.g. queuing,
scheduling, etc.
o Job chart
I think that the first major bullet and its sub-bullets are confusing. We
need to come to terms with what a document is! If we can have one
or more of them, and they can have attributes, why aren't they objects?
Will this be hard to explain in the presentation?
o Job Template
I'd remove the bullet "Several per Printer", given the issues surrounding
the definition of job-template. One could suggest that as an abstraction,
a Printer has but one set of defaults. A physical device may have multiple
job-templates and a server may share templates among many physical
devices, but it seems simpler to me to think of the abstraction as a single
view of the device. Another view is another Printer.
o IPP Messages chart
an IPP message is in fact an HTTP message with the IPP part imbedded
in the HTTP message's entity body. At least this is what the current spec
(and the next chart) says. Perhaps if you switched the order of this chart
with the next one (IPP Messages over HTTP/1.0) it would make this clear.
Instead of writing down the syntax, I also think that an example make this
more clear. You could uses one of the examples from the appendix.
This is probably an important point to make clear as it will allow people
attending the BOF to focus on exactly how we use HTTP, an area where
there could be a lot of debate.
o Security chart
If asked, can we respond with what existing security mechanisms we
rely on? Should we simply say that this is an open issue, or under study?
I don't understand the multi-valued list of end user names bullet.