Just a couple of clarifications. NDPS does explicitly include the type of =
all the attributes it sends over the wire, which, as Ira mentioned, allows =
for extensions to the protocol to be easy incorporated. Also, NDPS was =
built from the ground up with internationalization in mind. Language id =
and code page information are communicated when appropriate. NDPS'es =
choice to use OIDs to represent all attributes and most attribute values =
greatly simplifies the internationalization effort, moving the requirement =
for printers to support multiple languages and code pages to the clients =
that need this functionality.
IPP restricts itself to describing a job-submission and printer-capability-=
discovery protocol. NDPS, in addition to these, defines the attributes =
and behaviors needed to implement a full, distributed print system (i.e, =
places defined print objects in the network context that allows them to be =
discoverable, configurable, and manageable).
If you'd like to discuss this further, I'd be happy to do so offline.
>>> Ira Mcdonald x10962 <email@example.com> 10/27/98 09:49AM >>>
Apart from interoperability (which is the whole reason that the
IETF IPP WG got their charter, to build an Internet standard
replacement for LPR), I'd say the other great strength of IPP/1.0
is the explicit typing of all the attributes in the over-the-wire
encoding (which greatly enhances ease of extensions and
preserves interworking) and the ability to present 'mixed'
job sets, with string attributes of individual jobs in many
different languages simultaneously. IPP/1.0 is the best that
the IETF has done so far about internationalization, in any
Lastly, IPP is strongly based on ISO 10175, Document Printing
Application (DPA), so it interworks well with implementations
of ISO 1075 (such as the NDPS you mentioned in your note).
As is the PWG's recent Job Monitoring MIB v1.0 (Feb 1998),
which covers the full range of IPP job attributes.
- Ira McDonald (outside consultant at Xerox)