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