From: Michael Sweet (mike@easysw.com)
Date: Wed Jul 19 2006 - 16:25:26 EDT
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@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@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
This archive was generated by hypermail 2.1.4 : Wed Jul 19 2006 - 16:25:34 EDT