IPP> DIR - Revised text for SLP 'printer:' template

IPP> DIR - Revised text for SLP 'printer:' template

IPP> DIR - Revised text for SLP 'printer:' template

Hastings, Tom N hastings at cp10.es.xerox.com
Fri Nov 6 04:43:53 EST 1998


TH0>>>>
Here are my numbered comments on the SLP Printer template
Each preceded by THn>>>> ended by a blank line.

I would like to process these comments on the IPP mailing list and at the 
IPP WG meeting next week.  Some of the comments propose adding 
attributes or values to the IPP Model and Semantics specification to 
keep the alignment with the SLP template.

Thanks,
Tom Hastings
Editor, IPP Model and Semantics specification



Date: Wed, 28 Oct 1998 07:14:05 PST
From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962)
Message-Id: <9810281514.AA15079 at snorkel.eso.mc.xerox.com>
To: Pete.StPierre at eng.sun.com, hastings at cp10.es.xerox.com,
imcdonal at eso.mc.xerox.com, ipp at pwg.org, robert.herriot at eng.sun.com
Subject: IPP> DIR - Revised text for SLP 'printer:' template
Sender: owner-ipp at pwg.org
Status: R


Hi folks,

Since I've had no comments from my fellow editors on the following
SLP 'printer:' template in the past week, I'm forwarding it to the
IPP WG for comment.

To read it, you'll need the latest 'service:' scheme spec (see note
below) and Pete's last draft of SLP 'printer:' template spec
(from March 1998, sorry I don't have the URL in front of me -
all drafts on SLP are of the form 'draft-ietf-svrloc-xxx.txt'
at 'ftp://ftp.ietf.org/internet-drafts').

I'd like to discuss the updated SLP 'printer:' template at our
IPP WG Telecon next week (Wednesday, 4 November 1998).

Cheers,
- Ira McDonald (outside consultant at Xerox)
  High North Inc
  906-494-2434
----------------------------------
Copies: Pete St. Pierre <Pete.StPierre at eng.sun.com>
        Tom Hastings <hastings at cp10.es.xerox.com>
        Bob Herriot <robert.herriot at eng.sun.com>
        Ira McDonald <imcdonal at eso.mc.xerox.com>

Hi Pete, Tom, and Bob                        Wednesday (21 October 1998)

As the primary editors of SLP 'printer:' template, IPP Model, and IPP
Encoding and Transport, I'm sending this along to you first for review.

Here's a few more references, a change log, and my proposed text for 
the next version of the SLP 'printer:' template.  Briefly, several 
attribute names grew the '-supported' suffix, because they were multi-
valued capabilities info.  And I added a comment to every attribute 
showing the primary source document (IPP, Printer MIB, or Salutations) 
for the values and semantics of the attribute. 

Also this version conforms (I hope) to the latest "Service Templates 
and service:  Schemes", <draft-ietf-svrloc-service-scheme-11.txt>, 
October 1998.  Specifically, the 'language' attribute was deleted from 
the template (it's now explicit in the SLP protocol envelope in SLPv2).  
And the language of all IANA-registered templates is now English in 
SLPv2 (although templates may be translated to other languages for 
SLPv2 use). 

Please send your comments as inline text, so they survive the email
gremlins...Pete, a reminder, I can't received any attachments...just
inline text in email.

Cheers,
- Ira McDonald (outside consultant at Xerox)
  High North Inc
  PO Box 221
  Grand Marais, MI  49839
  906-494-2434

PS - My wife Nancy and I will be packing up and moving back to 
Rochester (NY) for the winter again in the next two weeks, so I'm going 
to have some interrupted availability (like a week with no email 
contact during our trip).  So your prompt comments would be appreciated 
- thanks.


**********************************************************************
**** Revised 'printer:' template - 21 October 1998 - Ira E McDonald ****
**********************************************************************

* High Level Changes

H1) 'version' was incremented to '0.2' (from '0.1').

H2) 'language = en' was deleted, per the latest draft of
    "Service Templates and service: Schemes", October 1998.

H3) 'ippurl' reference in 'url-syntax' was changed to "IPP Transport
    and Encoding" [9], rather than the (incorrect) [3].

H4) Added a comment to each attribute, w/ the source attribute name in
    IPP (base document), Printer MIB (RFC 1759), or Salutations.

H5) Revised various attribute descriptions for clarity or accuracy.
    (ie, consistency with IPP specs).

* Detail Level Changes

D1) 'uri-supported' (multi-valued and ordered) attribute was added,
    for use with (existing) 'uri-security-supported' - per IPP Model.

D2) 'service-person' was moved up to follow \operator', for clarity
    - per Printer MIB.

D3) 'natural-language-configured' was added (it was already referred to
    to as the language of other attributes in the previous draft),
    and attribute descriptions were revised to clarify which attributes
    are interpreted by 'natural-language-configured' - per IPP Model.

D4) 'charset-configured' was added - per IPP Model.

D5) 'duplex-mode' was revised to collapse to (original) Salutations
    keywords and (overlapping) IPP keywords were added to description.

D6) 'media-supported' was revised to clarify that it contains ONLY the
    ISO 10175 media keywords, in fixed locale of 'en' (English).

D7) 'media-local-supported' was revised to clarify that it contains 
    ONLY the site-specific names, in 'natural-language-configured' 
    locale.

D8) 'color-supported' was revised to clarify that it covers ALL color
    capabilities, including highlight color printing - per IPP Model.

D9) 'print-quality' was renamed to 'print-quality-supported' (could 
    also have become 'print-quality-default', single valued) - per IPP 
    Model.
TH1>>>>  
Its more important to have the list of supported, than the default.
The supported values are ones that can be selected in the Protocol.

D10)'resolution' was renamed to 'resolution-supported' (could also
    have become 'resolution-default', single valued) - per IPP Model.

D11)'copies' was renamed to 'copies-supported' - per IPP Model.
D12)'job-k-octet-supported' was renamed to 'job-k-octets-supported'
    (typo in previous version of template) - per IPP Model.

D13)'finishing' was renamed to 'finishings-supported' (could also have
    (become 'finishings-default') and explicit staple positions were
    removed - per IPP Model.
TH2>>>>  
Its more important to have the list of supported, than the default.
The supported values are ones that can be selected in the Protocol.

(ISSUE - should we import the far more complete set of finishings in
    the latest IETF/PWG Finisher MIB draft?)
TH3>>>>  
No, we have a set of additional enums as an extension to the 
"finishings" attribute that we will process next week, which could be 
added to the SLP template:  saddle-stitch, edge-stitch, staple-top-
left, staple-bottom-left, staple-top-right, staple-bottom-right, 
staple-dual-top, staple-dual-bottom, staple-dual-left, staple-dual-
right, edge-stitch-top, edge-stitch-bottom, edge-stitch-left, edge-
stitch-right.  The coordinate system agrees with the Finisher MIB. 

D14)'delivery-orientation' (from Printer MIB) values of 'face-up' and
    'face-down' had hyphens added for standard style.

D15)'pages-per-minute' was added - per request of Angelo Caruso.

* Corrected References

[3]--change date to June 1998 (latest draft)

[4]--change date to October 1998 (latest draft)

* Additional References

[9]R. Herriot, S. Butler, P. Moore, R. Turner,
"IPP/1.0: Encoding and Transport", Work in progress, June 1998

[10]"Document Printing Application (DPA)", ISO/IEC 10175, June 1996.

[11]IANA Registry of Internet Media Types (also called MIME types):
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types

TH4>>>> 
Where are the references?  Also the reference to [9] below certainly 
shouldn't be to the [9] above.


-------------------- template begins here --------------------
        type = printer

        version = 0.2

        description =
            The printer service template describes the attributes
            supported by network printing devices.  Devices may be
            either directly connected to a network, or connected to a
            printer spooler that understands the a network queuing
            protocol such as IPP, lpr or the Salutation Architecture.
TH5>>>> The device that is directly connected to the network could also 
understand IPP.  So re-write the sentence as two sentences:
                                                    Devices may be
            either directly connected to a network, or connected to a
            printer spooler.  The device or spooler understands a 
            network queuing protocol such as IPP, lpr or the Salutation 
            Architecture.


        url-syntax =
            url-path    = ippurl / lprurl
            ippurl      = url as defined in [9]
TH6>>>> 
[9] should be to RFC 2396, not the IPP PRO document.

            lprurl      = "lpr://" hostport [ "/" qname ]
            hostport    = host [ ":" port ]
            host        = hostname / hostnumber
            hostname    = *( domainlavel "." ) toplabel
            domainlabel = alphanum /
                          alphanum * [alphanum / "-"] alphanum
            toplabel    = alpha / alpha * [alphanum / "-"] alphanum
            hostnumber  = ipv4-number / ipv6-number
            ipv4-number = 1*3digit 3*3("." 1*3digit)
            ipv6-number = 32*hex
            3digit      = digit digit digit
            port        = 1*digit
            alphanum    = alpha / digit
            alpha       = "a" / "b" / "c" / "d" / "e" / "f" / "g" /
                          "h" / "i" / "j" / "k" / "l" / "m" / "n" /
                          "o" / "p" / "q" / "r" / "s" / "t" / "u" /
                          "v" / "w" / "x" / "y" / "z" /
                          "A" / "B" / "C" / "D" / "E" / "F" / "G" /
                          "H" / "I" / "J" / "K" / "L" / "M" / "N" /
                          "O" / "P" / "Q" / "R" / "S" / "T" / "U" /
                          "V" / "W" / "X" / "Y" / "Z"
            digit       = "0" / "1" / "2" / "3" / "4" / "5" / "6" /
                          "7" / "8" / "9"

TH7>>>> 
I'm not conversant with SLPv1 or SLPv2.  What are the maximum lengths 
on STRING?  In IPP we go to great pains to specify the maximum length 
of strings and to require that all implementations support the maximum
length.  IPP 'text' attributes are usually 1023 octets and 'name' are 
usually 255 octets.  A few 'text' and 'name' attributes are limited to 
127 octets, such as "printer-name", "printer-location", "printer-info", 
"printer-make-and-model" which happen to be all of the IPP 'text' and 
'name' attributes which appear in the SLP template.
ISSUE: So should we add a comment that the maximum is 127 octets to each?

        name = STRING
            # IPP 'printer-name'
            # This attribute contains the name of this printer,
            # in the locale specified by 'natural-language-configured'.
            # An administrator determines a printer's name and sets this
            # attribute to that name.  This name may be the last part of
            # the printer's URI or it may be unrelated.  In
            # non-US-English locales, a name may contain characters
            # that are not allowed in a URI.

        description = STRING
            # IPP 'printer-info'
            # This attribute contains the description of this printer,
            # in the locale specified by 'natural-language-configured'.
            # A free form string that can contain any site-specific
            # descriptive information about this printer.
TH8>>>>  
There is a subtle difference between "the description of this printer"
and IPP "printer-info" which says it is "descriptive information about 
this printer".  Descriptive information about includes description of 
this printer, such as "This printer prints duplex and staples".  But 
descriptive information about also includes the examples from IPP.  The 
complete IPP description is:

This Printer attribute identifies the descriptive information about 
this Printer object.  This could include things like: "This printer can 
be used for printing color transparencies for HR presentations", or 
"Out of courtesy for others, please print only small (1-5 page) jobs at 
this printer", or even "This printer is going away on July 1, 1997, 
please find a new printer".

I suggest the following text instead:

        description = STRING
            # IPP 'printer-info'
            # This attribute contains descriptive information about 
            # this printer, in the locale specified by 'natural-
            # language-configured'.  A free form string that can 
            # contain any site-specific descriptive information about 
            # this printer.


        printer-more-info = STRING L O
            # IPP 'printer-more-info'
            # A URI used to obtain more information about
            # this specific printer.  For example, this could
            # be an HTTP type URI referencing an HTML page accessible
            # to a Web Browser.  The information obtained from this
            # URI is intended for end user consumption.  Features
            # outside the scope of IPP can be accessed from this URI.

        uri-supported = STRING L M O
            # IPP 'printer-uri-supported'
            # The ordered list of URI supported by this printer,
            # correlated with the 'uri-security-supported' attribute.

        uri-security-supported = STRING L M O
            none
            # IPP 'uri-security-supported'
            # The ordered list of security supported for each URI
            # listed in the 'uri-supported' attribute for this printer.
            # TLS is one example.  URIs that do not support a security
            # mechanism should specify 'none'.
            none, tls, ssl3

TH9>>>>  
See mail sent on 11/5/1998 proposing combining these two into one 
structured multi-valued attributes, since SLP cannot have ordered 
multi-valued attributes.  I propose to replace uri-supported and 
uri-security-supported with:
        uri-and-security-supported = STRING M
            # IPP 'printer-uri-supported' and 'uri-security-supported'
            # The list of URI supported by this printer with each URI 
            # value followed by one of the security keywords separated 
            # by one SPACE character.  Example value: 
            # http://foo none, http://bar tls, http://baz tls-daa
            # IPP security keywords include:
            # none, daa, tls, tls-daa, ssl3, ssl3-daa


        concrete-protocols = STRING L M
            # The names of the concrete protocol types supported
            # by the printer abstract service type.
            # Example values include 'http' (for IPP/1.0) and 'lpr'

        abstract-protocol = STRING L O
            # The name of the abstract protocol which may be run over
            # any concrete types listed.  For example, the abstract
            # protocol 'ipp' might be run over the concrete types of
            # transport option).
            # in a future version of IPP
            # IPP/1.0 MUST operate over 'http' concrete protocol.
            # LPR MUST operate over 'lpr' concrete protocol.
            # Advertised service URLs MUST contain protocol schemes
            # advertised in the 'concrete-protocol' attribute above.
            lpr, ipp

        make-model = STRING O
            # IPP 'printer-make-and-model'
            # This attribute contains the make/model of this printer,
            # in the locale specified by 'natural-language-configured'.
            # A simple text string defined by the manufacturer.
            # It should provide the name of the vendor and the model
            # name or number
TH10>>>>
Change the name to agree with IPP as make-and-model.
Replace "make/model" in the description which suggests make or model 
and replace with "make and model" to agree with IPP description (or 
"make and/or model"?).

TH11>>>>
ISSUE:  I see that this description and a lot of others contain the 
word "printer", instead of the word "device".  In IPP this attribute 
uses the word "device", as does "printer-location".  Since there is a 
movement to generalize to multi-function devices and since the 
"printer" work has been removed from all of the names of the attributes 
in this template, to use the word "device" in the descriptions, instead 
of the word "printer"?


        location = STRING O
            # IPP 'printer-location'
            # This attribute contains the location of this printer,
            # in the locale specified by 'natural-language-configured'.
            # A free form description of this printer's physical
            # location For example:  '2nd floor, near the fire escape'

        operator = STRING M O
            # Printer MIB 'prtGeneralCurrentOperator'
            # A person, or persons responsible for maintaining a
            # printer on a day-to-day basis.
TH12>>>>
Replace "A person, or persons ..." with 
"The name(s) of the person or persons ..."
to make it clear that it is a name and to agree with the Printer MIB.


        service-person = STRING M O
            # Printer MIB 'prtGeneralServicePerson'
            # A list of service contact names for this printer.
TH13>>>>
ISSUE:  Both Printer MIB 'prtGeneralCurrentOperator' and 
'prtGeneralServicePerson' permit additional information such as a phone 
number.  
Should we also allow more than a name?


        natural-language-configured = STRING L
            # IPP 'natural-language-configured'
            # The configured language in which error and status 
            # messages will be generated (by default) by this printer.
            # Also, the language in which printer string attributes are
            # set by operator or system administrator or manufacturer,
            # including 'name', 'description', 'make-model', 
            # 'location', which are IPP 
            # 'printer-[name|info|location|make-model]'.
            # Legal values of language tags conform to RFC 1766
            # 'Tags for the Identification of Languages' [5].
TH14>>>>
Where is [5]?  Where are the references?


        natural-language-supported = STRING L M
            # IPP 'generated-natural-language-supported'
            # The possible languages in which error and status messages
            # may be generated (if requested) by this printer.
            # Legal values of language tags conform to RFC 1766
            # 'Tags for the Identification of Languages' [5].

        charset-configured = STRING L
            utf-8
            # IPP 'charset-configured'
            # The configured charset in which error and status messages
            # will be generated (by default) by this printer,
            # for example UTF-8, Shift-JIS, or ISO-8859-1 (Latin1).
            # Legal values of charset tags (names/aliases) come from
            # the IANA Registry of Coded Character Sets [6].
TH15>>>>
This attribute is used for more than error and status messages.  It is 
also used for other text and name attributes here in the directory and 
in the IPP Printer object.  I suggest replacing "error and status 
messages" with "text and name attributes, including error and status 
messages"

TH16>>>>
For the charset attribute syntax in IPP, we clarify which charset name 
to use when there are several alises.  I suggest we do the same here.  
So add the sentence:
When a character-set in the IANA registry has more than one name 
(alias), the name labeled as "(preferred MIME name)", if present, MUST 
be used.


        charset-supported = STRING L M
            utf-8
            # IPP 'charset-supported'
            # The possible charsets in which error and status messages
            # may be generated (if requested) by this printer,
            # for example UTF-8, Shift-JIS, or ISO-8859-1 (Latin1).
            # Legal values of charset tags (names/aliases) come from
            # the IANA Registry of Coded Character Sets [6].
TH17>>>>
Repeat of  TH16>>>>


        duplex-mode = STRING L M O
            simplex
            # Salutations 'duplex-mode'
            # (Compare with IPP 'sides')
            # The number of impression sides (one or two) and the
            # two-sided impression rotations supported by this printer.
            # IPP 'one-sided' is equivalent to 'simplex'.
            # IPP 'two-sided-long-edge' is equivalent to 'duplex'.
            # IPP 'two-sided-short-edge' is equivalent to 'tumble'.
            simplex, duplex, tumble
TH18>>>>
Since IPP is an IETF standard, and Salutation is not, I suggest that we 
use the IPP attributes and value names and give the Salutation 
equivalents as comments.
So replace the above with:
        sides = STRING L M O
            one-sided
            # IPP 'sides'
            # (Compare with Salutation's 'duplex-mode')
            # The number of impression sides (one or two) and the
            # two-sided impression rotations supported by this printer.
            # Salutation's 'simplex' == IPP 'one-sided'.
            # Salutation's 'duplex' == IPP 'two-sided-long-edge'.
            # Salutation's 'tumble' == IPP 'two-sided-short-edge'.
            one-sided, two-sided-long-edge, two-sided-short-edge




        priority-levels-supported = INTEGER O
            1
TH19>>>>
            # IPP 'priority-level-supported'

            # Salutations 'priority-levels-supported'
            # The number of priority levels supported by this printer.
            # A value of 1 indicates all jobs have the same priority.
        number-up = INTEGER O
            1
            # IPP 'number-up'
            # Specifies the number of source page-images to impose
            # upon a single side of an instance of a selected
            # medium.

        media-supported = STRING L M O
            # IPP 'media-supported' - only the standard keyword values
            # The standard names/types/sizes (and optional color
            # suffixes) of the media supported by this printer.
            # The values specified are NOT localized according to the
            # value of 'natural-language-configured', but are in a
            # fixed locale of 'en' (English).  For example
TH20>>>>
In IPP, we specify that keywords are 'en-us', not just 'en', so replace 
previous line with:
            # fixed locale of 'en-us' (U.S. English).  For example

            # 'iso-a4' or 'envelope' or 'na-letter-white'.
            # Legal values of this attribute conform to ISO 10175
            # 'Document Printing Application (DPA)' [10].
TH21>>>>
Since IPP is what we are aligning SLP template with, not ISO DPA, and 
since IPP has a superset of the ISO DPA values, and IPP has a 
registration procedure with IANA for additional keywords, we should 
replace the two previous lines with:
            # Legal values of this attribute are any of the keywords 
            # specified for the IPP "media" keyword in the IPP/1.0 
            # Model and Semantics specification [??] and any additional 
            # keyword values that may be registered according to the 
            # procedures in the IPP Model and Semantics specification.


        media-local-supported = STRING M O
            # IPP 'media-supported' - only the site-specific values
TH22>>>> 
The site-specific are 'name' values, so replace the previous line with:
            # IPP 'media-supported' - only the site-specific 'name' 
            # values

            # The site-specific names/types/sizes (and optional color
            # suffixes) of the media supported by this printer,
            # in the locale specified by 'natural-language-configured'.
            # For example 'purchasing-form' (site-specific name)
            # as opposed to 'na-letter' (standard keyword from [10]).

        color-supported = BOOLEAN O
            false
            # IPP 'color-supported'
            # Indicates whether the printer is capable of any type of
            # color printing at all, including highlight color.

        document-format-supported = STRING L M O
            # IPP 'document-format-supported'
            # The possible document formats in which data may be
            # interpreted and printed by this printer.
            # Legal values of document formats (MIME types) come from
            # the IANA Registry of Internet Media Types [11].
TH23>>>>
IPP has document-format-supported REQUIRED for the IPP Printer object 
and we forget to do the same for the directory schema in section 17 of 
the Model document.  The document-format is one of the key attributes about
a printer.  
We will change the IPP Model document.  So remove the "O" from the 
first line above, so that it is REQUIRED here in the template as well.

TH24>>>>
Also the clarification about the 'application/octet-stream' MIME type 
in IPP should be referenced, since it is auto-sense.  I suggest adding 
the sentence:
            # See the 'documentFormat' attribute syntax in IPP Model 
            # and Semantics specification [??].


        paper-output = STRING L M O
            standard
            # Salutations 'paper-output'
            # The mode in which pages output are arranged.
            standard, noncollated sort, collated sort, stack, unknown
TH25>>>>
This attribute is multi-valued, so replace "mode" with "mode or modes".
Also add to the end of the sentence: "by one or more output bins", 
since this attribute is not attempting to indicate which output bins 
have which modes.


        print-quality-supported = STRING L M O
            normal
            # IPP 'print-quality-supported'
            # The possible subjective print quality modes in which
            # documents may be printed by this printer.
            draft, normal, high

        resolution-supported = STRING L M O
            # IPP 'printer-resolution-supported'
            # The possible resolutions in which documents may be
            # printed by this printer (in sets of three values).
            # A string representation of 3 comma (',') separated integers
            # where each integer itself is represented as a string.
            # The 3 integers represent in order:  1) a cross feed
            # direction resolution (positive integer value), 2) a feed
            # direction resolution (positive integer value), and 3)
            # a units value.  In the latter case, a '3' indicates
            # dots per inch and a '4' indicates dots per centimeter.
            # These values are derived from the Printer MIB [6].
TH26>>>>
ISSUE:  Why not use some more user friendly code than "3" and "4", such 
as 'dpi' and 'dpcm'?  Then applications might just display them as 
text?


        copies-supported = INTEGER O
            -1
            # IPP 'copies-supported'
            # The maximum number of copies of a document
            # that may be printed as a single job.
            # A value of -1 indicates there is no limit.
TH27>>>>
Is the -1 convention something that is used in SLP protocol?
ISSUE for IPP Model:
We could add an out-of-band value to IPP, say, 'no-limit'.
Then we could use the string 'no-limit' here to mean no limit.
Or would that violate some data typing in SLP?
Just a thought?
Alternatively, we could say that if this attribute was not present, 
there was no limit?  Or would this make it hard to search for printers 
that had no limit?
Or would the absence of this attribute be for a printer that wasn't 
saying whether it had a limit or not?  In other words, is there a 
difference between a printer that says it has no limit and one that 
doesn't say whether it has a limit or not?


        job-k-octets-supported = INTEGER O
            -1
            # IPP 'job-k-octets-supported'
            # The maximum size, in kilobytes, of a print job that
            # this printer will accept.
            # A value of -1 indicates there is no limit.
TH28>>>>
Repeat of TH27>>>>


        finishings-supported = STRING L M O
            none
            # IPP 'finishings-supported'
            # The possible finishing operations supported by this
            # printer.
            none, staple, punch, cover, bind
TH29>>>
Repeat of TH3>>>> which might add (to be proposed and confirmed next 
week):
saddle-stitch, edge-stitch, staple-top-left, staple-bottom-left, 
staple-top-right, staple-bottom-right, staple-dual-top, staple-dual-
bottom, staple-dual-left, staple-dual-right, edge-stitch-top, edge-
stitch-bottom, edge-stitch-left, edge-stitch-right


        delivery-orientation = STRING L O
            unknown
            # Printer MIB 'prtOutputPageDeliveryOrientation'
            # Orientation of pages as they are printed and ejected from
            # the printer.
            unknown, face-up, face-down
TH30>>>>
Since this attribute can't be describing each output bin, it is 
describing the capabilities of the printer.  So it should be multi-
valued.  So change the name of the attribute to 'delivery-orientations-
supported'
Add "M" to the first line.  Change the sentence to:
            # Supported orientation(s) of pages as they are printed and 
            # ejected from the printer.

        pages-per-minute = INTEGER O
            # IPP 'pages-per-minute' (proposed new attribute)
            # The optimal number of pages per minute which may be
            # generated by this printer (e.g., simplex, black-and-white).
            # This attribute is informative, NOT a service guarantee.
TH31>>>>
ISSUE:  Would the word "nominal", instead of "optimal", be better.  
Else some may put very high numbers because their printer goes very 
fast when there is no information to be printed.

TH32>>>>
I also suggest tying the number to "that used in marketing literature 
to describe the printer".

TH33>>>>
There has been a lot of e-mail discussion about this attribute and/or 
having two so that color speed could be indicated in addition to black-
and-white.
These attributes should be added to the IPP Model as well.
I would think that having two separate attributes is simpler because 
there would be no need for multi-field values.  In IPP they would be 
simple integers.
Also non-color printers would not have the "pages-per-minute-color" 
attribute at all.
I suggest that the two complete specifications be:
        pages-per-minute = INTEGER O
            # IPP 'pages-per-minute' (proposed new attribute)
            # The nominal number of pages per minute which may be
            # generated by this printer that is used in its marketing 
            # literature to describe the device (e.g., simplex, black-
            # and-white).
            # This attribute is informative, NOT a service guarantee.
        pages-per-minute-color = INTEGER O
            # IPP 'pages-per-minute-color' (proposed new attribute)
            # The nominal number of pages per minute which may be
            # generated by this printer that is used in its marketing 
            # literature to describe the device (e.g., simplex, color).
            # This attribute is informative, NOT a service guarantee.



-------------------- template ends here ----------------------




More information about the Ipp mailing list