attachment

<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
<META content="MSHTML 6.00.2900.2912" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">I will be unable to attend the meeting tomorrow.&nbsp; But just to give my two cents worth, I would be ok with option 1 or 2<BR><BR>&gt;&gt;&gt; "McDonald, Ira" &lt;imcdonald@sharplabs.com&gt; 7/19/2006 12:43 PM &gt;&gt;&gt;<BR>Hi folks,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Wednesday (19 July 2006)<BR><BR>As background for tomorrow's teleconference reviewing the first draft of<BR>PWG IPP Printer State Reasons Extensions, below is a summary of the four<BR>available methods in IPP to represent correlated elements (e.g., various<BR>columnar object values from a specific 'prtAlertTable' entry).<BR><BR>Note that the IPP Printer State Reasons Extensions MUST be practical for<BR>easy addition to ALL of the existing IPP implementations, or else such a<BR>standardized approach is not cost effective (to specify or implement).<BR><BR>Method (1) below was chosen for our first draft IPP PSX spec because it<BR>requires NO new IPP atrributes (uses existing "printer-state-reasons"<BR>and "printer-state-message") and thus is immediately available in all<BR>existing IPP client implementations - this is very important to Sharp.<BR><BR>Cheers,<BR>- Ira (co-editor of PWG IPP Printer State Reasons Extensions)<BR><BR><BR>Ira McDonald (Musician / Software Architect)<BR>Blue Roof Music / High North Inc<BR>PO Box 221&nbsp; Grand Marais, MI&nbsp; 49839<BR>phone: +1-906-494-2434<BR>email: imcdonald@sharplabs.com<BR><BR>------------------------------------------------------------------------<BR><BR>(1) Method:&nbsp; Structured encoding in a single string<BR><BR>&nbsp;&nbsp;&nbsp; Example: From IPP Printer Installation Extension<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (ftp://ftp.pwg.org/pub/pwg/ipp/new_DRV/<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&!
 nbsp;&nb

sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; draft-ietf-ipp-install-04.txt)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "client-print-support-files-supported (1setOf<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; octetString(MAX))"<BR><BR>&nbsp;&nbsp;&nbsp; Remarks: In practice, localized elements can't be supported with<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reliable interoperability - but this has no importance for<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the current IPP PSX spec.<BR><BR><BR>(2) Method:&nbsp; Parallel ordered multi-valued attributes<BR><BR>&nbsp;&nbsp;&nbsp; Example: From IPP/1.1 Model and Semantics<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (ftp://ftp.isi.edu/in-notes/<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rfc2911.txt)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "printer-uri-supported (1setOf uri)"<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "uri-authentication-supported (1setOf type2 keyword)"<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "uri-security-supported (1setOf type2 keyword)<BR><BR>&nbsp;&nbsp;&nbsp; Remarks: The '1setOf X' datatype (section 4.1.16 of RFC2911) is<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fragile for interoperability, because IPP/1.1 states:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Sets are normally unordered.&nbsp; However each attribute<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; description of this type may specify that the values<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MUST be in a certain order for that attribute."<BR><BR>&nbsp;&nbs!
 p;&nbsp;

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In practice, this means that a generic IPP parser MUST NOT<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; be order-preserving, thus the inherent fragility.<BR><BR><BR>(3) Method:&nbsp; Members in an IPP 'collection' attribute (per RFC 3382)<BR><BR>&nbsp;&nbsp;&nbsp; Example: From IPP Production Printing Attributes - Set1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (ftp://ftp.pwg.org/pub/pwg/candidates/<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cs-ippprodprint10-20010212-5100.3.pdf)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "media-col (collection)"<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "media-type (type3 keyword | name(MAX))"<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "media-info (text(255))"<BR><BR>&nbsp;&nbsp;&nbsp; Remarks: The 'collection' datatype is NOT a base IPP/1.1 type, but<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rather an extension - which has NOT been demonstrated to be<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; interoperable across various IPP parser implementations.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The 'collection' datatype is NOT supported in the majority<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of existing IPP/1.1 implementations from various vendors.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; There are no known implementations of 'collection' datatype<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in IPP/1.0 implementations - many network printers ONLY<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; support the protocol/datatypes in IPP/1.0 (RFC 2!
 565/2566

).<BR><BR><BR>(4) Method:&nbsp; Attributes in a new first-class IPP object<BR><BR>&nbsp;&nbsp;&nbsp; Example: From IPP Document Object<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (ftp://ftp.pwg.org/pub/pwg/candidates/<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cs-ippdocobject10-20031031-5100.5.pdf)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "document-charset (charset)"<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "document-format (mimeMediaType)"<BR><BR>&nbsp;&nbsp;&nbsp; Remarks: The Document object is the ONLY object that has ever been<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; defined to extend IPP/1.1 - there has never been an IPP<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bakeoff to demonstrate interoperability of this object.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; There was a strong resistance among former IPP editors to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the definition of new first-class IPP objects - which was<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the specific justification for the introduction of the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 'collection' datatype - this is not a practical approach.<BR><BR>------------------------------------------------------------------------<BR><BR>-- <BR>No virus found in this outgoing message.<BR>Checked by AVG Free Edition.<BR>Version: 7.1.394 / Virus Database: 268.10.1/391 - Release Date: 7/18/2006<BR><BR></BODY></HTML>