From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Wed Jul 19 2006 - 14:43:03 EDT
Hi folks, Wednesday (19 July 2006)
As background for tomorrow's teleconference reviewing the first draft of
PWG IPP Printer State Reasons Extensions, below is a summary of the four
available methods in IPP to represent correlated elements (e.g., various
columnar object values from a specific 'prtAlertTable' entry).
Note that the IPP Printer State Reasons Extensions MUST be practical for
easy addition to ALL of the existing IPP implementations, or else such a
standardized approach is not cost effective (to specify or implement).
Method (1) below was chosen for our first draft IPP PSX spec because it
requires NO new IPP atrributes (uses existing "printer-state-reasons"
and "printer-state-message") and thus is immediately available in all
existing IPP client implementations - this is very important to Sharp.
Cheers,
- Ira (co-editor of PWG IPP Printer State Reasons Extensions)
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com
------------------------------------------------------------------------
(1) Method: Structured encoding in a single string
Example: From IPP Printer Installation Extension
(ftp://ftp.pwg.org/pub/pwg/ipp/new_DRV/
draft-ietf-ipp-install-04.txt)
"client-print-support-files-supported (1setOf
octetString(MAX))"
Remarks: In practice, localized elements can't be supported with
reliable interoperability - but this has no importance for
the current IPP PSX spec.
(2) Method: Parallel ordered multi-valued attributes
Example: From IPP/1.1 Model and Semantics
(ftp://ftp.isi.edu/in-notes/
rfc2911.txt)
"printer-uri-supported (1setOf uri)"
"uri-authentication-supported (1setOf type2 keyword)"
"uri-security-supported (1setOf type2 keyword)
Remarks: The '1setOf X' datatype (section 4.1.16 of RFC2911) is
fragile for interoperability, because IPP/1.1 states:
"Sets are normally unordered. However each attribute
description of this type may specify that the values
MUST be in a certain order for that attribute."
In practice, this means that a generic IPP parser MUST NOT
be order-preserving, thus the inherent fragility.
(3) Method: Members in an IPP 'collection' attribute (per RFC 3382)
Example: From IPP Production Printing Attributes - Set1
(ftp://ftp.pwg.org/pub/pwg/candidates/
cs-ippprodprint10-20010212-5100.3.pdf)
"media-col (collection)"
"media-type (type3 keyword | name(MAX))"
"media-info (text(255))"
Remarks: The 'collection' datatype is NOT a base IPP/1.1 type, but
rather an extension - which has NOT been demonstrated to be
interoperable across various IPP parser implementations.
The 'collection' datatype is NOT supported in the majority
of existing IPP/1.1 implementations from various vendors.
There are no known implementations of 'collection' datatype
in IPP/1.0 implementations - many network printers ONLY
support the protocol/datatypes in IPP/1.0 (RFC 2565/2566).
(4) Method: Attributes in a new first-class IPP object
Example: From IPP Document Object
(ftp://ftp.pwg.org/pub/pwg/candidates/
cs-ippdocobject10-20031031-5100.5.pdf)
"document-charset (charset)"
"document-format (mimeMediaType)"
Remarks: The Document object is the ONLY object that has ever been
defined to extend IPP/1.1 - there has never been an IPP
bakeoff to demonstrate interoperability of this object.
There was a strong resistance among former IPP editors to
the definition of new first-class IPP objects - which was
the specific justification for the introduction of the
'collection' datatype - this is not a practical approach.
------------------------------------------------------------------------
-- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.1/391 - Release Date: 7/18/2006
This archive was generated by hypermail 2.1.4 : Wed Jul 19 2006 - 14:43:15 EDT