Subject: IPP> Four IPP methods for encoding correlated elements

From: "McDonald, Ira" <[email-masked]>
Date: Wed, 19 Jul 2006 11:43:03 -0700

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: [email-masked]

------------------------------------------------------------------------

(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

---

From: "Ted Tronson" <[email-masked]>
Date: Wed, 19 Jul 2006 13:38:37 -0600

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

>>> "McDonald, Ira" <[email-masked]> 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 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,

    Remarks: In practice, localized elements can't be supported with
             reliable interoperability - but this has no importance
for
             the current IPP PSX spec.

             In practice, this means that a generic IPP parser MUST
NOT
             be order-preserving, thus the inherent fragility.

    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).

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

---

From: Michael Sweet <[email-masked]>
Date: Wed, 19 Jul 2006 16:25:26 -0400

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

> easy addition to ALL of the existing IPP implementations, or els! e such a
>                (ftp://ftp.pwg.org! /pub/pwg/ipp/new_DRV/
>       &! nbsp;&nb sp;         draft-ietf-ipp-install-04.txt)
>                &! nbsp; rfc2911.txt)
>                MUS! T be in a certain order for that attribute."
> 
>  &nbs! p;            In practice, this means that a generic IPP parser 
> MUST NOT

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

>               ! ; "media-info (text(255))"
> 
>           ! ;   support the protocol/datatypes in IPP/1.0 (RFC 2! 
> 565/2566 ).
> 
> 
>   &! nbsp;          There was a strong resistance among former IPP 
> editors to

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