IPP> Four IPP methods for encoding correlated elements

IPP> Four IPP methods for encoding correlated elements

IPP> Four IPP methods for encoding correlated elements

McDonald, Ira imcdonald at sharplabs.com
Wed Jul 19 14:43:03 EDT 2006


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 at 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
 



More information about the Ipp mailing list