IPP> Four IPP methods for encoding correlated elements

IPP> Four IPP methods for encoding correlated elements

IPP> Four IPP methods for encoding correlated elements

Michael Sweet mike at easysw.com
Wed Jul 19 16:25:26 EDT 2006


Ted Tronson wrote:
>   I will be unable to attend the meeting tomorrow.  But just to give my 
> two cents worth, I would be ok with option 1 or 2

Ditto here, as long as we don't use printer-state-message for
this purpose.

>  >>> "McDonald, Ira" <imcdonald at sharplabs.com> 7/19/2006 12:43 PM >>>
> 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 els! e 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/
>       &! nbsp;&nb sp;         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/
>                &! nbsp; 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
>                MUS! T be in a certain order for that attribute."
> 
>  &nbs! p;            In practice, this means that a generic IPP parser 
> MUST NOT
>              be order-preserving, thus the inherent fragility.

That's a bit strong; a generic IPP parser MAY NOT be order-preserving,
which is probably what you meant... :)

> 
> (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 2! 
> 565/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.
>   &! nbsp;          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
> 


-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com



More information about the Ipp mailing list