My replies are inline below.
On Tue, Jan 5, 2010 at 4:35 PM, William Wagner <wamwagner at comcast.net>wrote:
> Hi Ira,
>>>> Quite so. But I had not entered these questions as answered since the
> responses did not appear to resolve my questions.
>>>> 1. Since from your response, a document may contain zero or one
> document ticket, and a job can contain zero or more documents, I do not see
> the error in saying that a job can contain zero or more document tickets. At
> any rate, for those who have not internalized the model, it does answer the
> question of how the document tickets get into the service.
>> I may misunderstand, but I think it would be misleading to say in the
> general document description that a document may contain zero or one
> document ticket since documents can exist exclusive of jobs, but I assume
> that it is only when a document is part of a job that it may contain a
> document ticket.
When using the correctly capitalized terms for
the SM *objects*, a Document object can only
be created *after* a Job object has been created
and the DocumentTicket object is optional (and
rarely used) to override the JobTicket object in
the Job object.
There is no such thing as a *lowercase* document
ticket in the Semantic Model.
>>> 2. Your response with regard to StorageMakeAndModel, although it
> appears to confirm my observation, does not address the question of what the
> reference should be. We originally had two separate elements but there
> appeared to be consensus that a single MakeAndModel element was
> reference-able. I do not recall who maintained that, but if that is so, I
> would like the reference.
There is no possible public MIB general reference
for MakeAndModel (which was inherited from IPP
in SM/1.0 and was for whole Printers only).
IETF Host Resources MIB only supports ASN.1
OIDs in the ProductID textual convention used
in hrDeviceID (and elsewhere) for manufacturer
and model - these OIDs cannot be meaningfully
converted to human-readable values for make
By very loose implementation convention, most
imaging device manufacturers use sysDescr
and/or hrDeviceDescr (for hrDevicePrinter) to
include human-readable make and model - this
information cannot be parsed reliably - I have
had a long thread with HP WJA developers on
An IEEE 1284 Device ID does include make
and model, but a separate string (at least for
the whole network device) is redundant.
For *only* two of the subunits (InputTray and
OutputTray), Printer MIB v2 includes make
and model. So there's no public MIB source
for make and model of any other subunits.
The SM/2.0 MakeAndModel element is synthetic
and does *not* have any public MIB reference.
Whether this element is a good idea is really
>>>> Bill Wagner
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...