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@eso.mc.xerox.com (Ira Mcdonald x10962)
Message-Id: <9810281514.AA15079@snorkel.eso.mc.xerox.com>
To: Pete.StPierre@eng.sun.com, hastings@cp10.es.xerox.com,
imcdonal@eso.mc.xerox.com, ipp@pwg.org, robert.herriot@eng.sun.com
Subject: IPP> DIR - Revised text for SLP 'printer:' template
Sender: owner-ipp@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@eng.sun.com>
Tom Hastings <hastings@cp10.es.xerox.com>
Bob Herriot <robert.herriot@eng.sun.com>
Ira McDonald <imcdonal@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 ----------------------