Subj: SLP Printer Template From: Ira McDonald with collected comments added Date: 11/8/1998 File: slp-printer-template-th.txt .pdf TH0>>>> Here are my numbered comments on the SLP Printer template Each preceded by THn>>>> ended by a blank line. Updated with mail received 11/06/98. Changes since the first posting: a. Reworked the pages-per-minute attribute b. Instead of a new out-of-band value for a device that has no limit on number of octets, just use the existing IPP 'no-value' which says that the administrator has not configured a value. I would like to process these comments on the 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 Tom Hastings Bob Herriot Ira McDonald 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", , 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 TH9alternative>>>> See mail sent on 11/6/1998 proposing to use the > character to separate ordered value within a single-valued string. uri-supported = STRING L O # IPP 'printer-uri-supported' # The ordered list of URI supported by this printer, # correlated with the 'uri-security-supported' attribute. # Each URI value is separated by greater-than ('>') uri-security-supported = STRING L 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'. # Each security value is separated by greater-than ('>') 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 (Issue 1.53). 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 reprentation 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]. TH26alternate>>>> See the mail sent 11/06/98 to make this ordered values as a single valued string with each value separated by greater-than ('>'). So replace the above with: resolution-supported = STRING L 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 greater-than ('>') 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, 'dpi' indicates dots per inch and # 'dpcm' indicates dots per centimeter. # These values are derived from the Printer MIB [6]. 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 use the existing IPP 'no-value' out-of-band value which means that the system administrator has not configured a value. Then we could use the string 'no-value' 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 (eg, simplex, black-and-white). # This attribute is informative, NOT a service guarantee. TH31>>>> ISSUE: Would the word "nonimal", 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 specifiations be: pages-per-minute = INTEGER O # IPP 'pages-per-minute' (proposed new attribute) # The nominal number of pages per minute to the nearest # whole number which may be generated by this printer # (e.g., simplex, black-and-white). # This attribute is informative, NOT a service guarantee. # Generally, it is the value used in the marketing # literature to describe the device pages-per-minute-color = INTEGER O # IPP 'pages-per-minute-color' (proposed new attribute) # The nominal number of pages per minute to the nearest # whole number which may be generated by this printer # (eg, simplex, color). For purposes of this attribute, # "color" means the same as for the "color-supported" # attribute, namely, the device is capable of any type of # color printing at all, including highlight color. # This attribute is informative, NOT a service guarantee. # Generally, it is the value used in the marketing # literature to describe the device. # Black and white only printers do not have this attribute. # If this attribute is present, then the color-supported # attribute MUST be present and have a 'true' value. -------------------- template ends here ---------------------- Need to add references 1 1