I've added my comments to Ira's message below.
-Hugo
>>>>> Ira McDonald <imcdonal at sdsp.mc.xerox.com> 01/10/99 11:17AM >>>
>>>>Hi Hugo, Sunday (10 January 1999)
>>>>My replies are imbedded in your note below. Thanks for your thoughtful
>>review of this draft 'printer:' template.
>>>>I would also like your opinion. Should we have two separate printer
>>speed attributes (one for nominal black-and-white and one for nominal
>>color speed)?
I'm in favor of adding the color speed attribute as optional.
>>>>Tom Hastings has also asked whether SLPv1 supports 'presence' filters on
>>attributes. The answer is no. Both SLPv1 and SLPv2 do have support for
>>default values on optional attributes. I suggest that we demote as many
>>mandatory attributes to optional as possible, then give them all default
>>values of 'unknown' (string or enum) or '-1' (integer).
I agree 100% with Ira's comment.
>>>>Cheers,
>>- Ira McDonald (outside consultant at Xerox)
>> High North Inc
>> 716-461-5667
>>>>>-----------------------------------------------------------------------
>>> To: <ipp at pwg.org>, <srvloc at srvloc.org>
>>> Cc: "Hugo Parra" <HPARRA at novell.com>,
>>> "Dale Bethers" <DBETHERS.PRV-MAIL1.PROVO at novell.com>,
>>> "Mark Killgore" <MKILLGORE.PRV-MAIL1.PROVO at novell.com>
>>> Subject: IPP> SLP 'printer:' template comments
>>>>>> I'd like to propose the following changes to the SLP 'printer:' template
>>> spec recently distributed by Ira.
>>>>>> 1. The template-url-syntax needs to include definitions for NDPS and TCP
>>> printers. The NDPS flavor would look as follows,
>>> ndpsurl = "ndps://" hostport [ nds-name / pa-name ]
>>> nds-name = "/nds/" fqn
>>> fqn = /* fully qualified NDS printer name */
>>> pa-name = "/pa/" printer-name
>>> printer-name = /* NDPS printer agent name */
>>>>Agree. We should add this NDPS URL and we should also add Port 9100 for
>>raw TCP printing. What about adding PServer URLs for NetWare SPX/IPX
>>protocol environments (see below)?
Currently in NetWare, any SLP advertising of IPX-based services is automatically handled by the CMD Migration Agent. The Agent already uses a special URL for this purpose. I don't think separate IPX URLs are needed for PServer or NDPS.
>>>>Probably a dumb question, but does NDPS only run over Internet TCP/IP or
>>does it also run over SPX/IPX? As you are probably aware, SLPv2 permits
>>both NetWare and AppleTalk addresses to be specified in registered SLP
>>'service:' URLs. So we might want an 'ndpsipxurl' syntax as well?
NDPS supports both IP and IPX natively but relies on the CMD Migration Agent to advertise IPX addresses through SLP.
>>> 2. uri-security-supported, add 'nds-sec' to legal values.
>>>>Could you state a document name for 'nds-sec' for the References section
>>of the 'printer:' template? Would 'nds-sec' add extra parameter(s) to
>>an 'ndps:' URL?
The security mechanism used by NDPS is NDS-based and different levels are negotiable at run-time without the need of extra parameters. There aren't documents publicly available on NDS- or NDPS-security that I know of. If this is a requirement for adding a legal value to the template, I'd like to propose that the legal value "other" be added instead. NDPS Clients know how to negotiate the security level once they know they're talking to an NDPS printer, which they can get from the printer's URL.
>>>>> 3. printer-location, make it optional. Very few administrators set this
>>> up today and it's optional in IPP.
>>>>Agree. And make the default value "unknown".
>>>>> 4. printer-current-operator, make it multi-valued. PServer and NDPS
>>> support multiple operators.
>>>>Agree. And make the default value "unknown".
>>Should we change this attribute name to plural?
Yes.
>>>>> 5. printer-service-person, make it multi-valued.
>>>>Agree. And make the default value "unknown".
>>Should we change this attribute name to plural?
Yes.
>>>>> 6. natural-language-configured, add 'client-dependent' to legal values.
>>> NDPS returns error and status info in the form of OIDs. Clients
>>> translate those OIDs to localized strings.
>>>>Disagree. The registered value of 'natural-language-configured' states
>>the actual language of 'printer-description' and other attributes is NOT
>>merely information about the print service. In addition, the syntax of
>>'natural-language-configured' in IPP/1.0 is an RFC 1766 'language tag',
>>where 'client-dependent' would be an illegal value.
>>>>> 7. natural-language-supported, add 'client-dependent' to legal values.
>>>>Disagree. See above.
Let me reinstate to make sure I understand it. The 'natural-language-configured' attribute in the SLP "printer:" template doesn't necessarily tells a user the natural language the printer is configured with, but the natural language in which string values in the template itself are written (which in many cases will coincide with the printer's configured natural language if the printer supports such a thing). If this is right, does the 'natural-language-supported' attribute in the "printer:" template tells a user the different natural languages in which string values could be populated in the template? How is that useful to a user searching for a printer.
Going back even a little farther. In practice, how does knowing the natural language configured for a printer helps a user make better use of a 'location' of 'description' string? Will users filter out of their searches printers that have 'descriptions' or 'locations' in a language they don't like? I'd suspect not. I agree this information may be useful in some cases, when available, but not critical. So I'd still like these two attributes to be optional (forget the 'client-dependent' value, I agree that doesn't make much sense either).
>>>>> 8. document-format-supported, make it optional. It's not always
>>> available to print servers front-ending legacy printers.
>>>>Agree. And make the default value "unknown".
>>>>> 9. color-supported, add 'unknown' as legal value.
>>>>Agree. And make optional with default value "unknown".
>>>>> 10. sides-supported, consider making optional.
>>>>Agree. And make the default value "unknown".
>>>>> 11. media-supported, make optional.
>>>>Agree. And make the default value "unknown".
>>>>> 12. media-local-supported, make optional.
>>>>Agree. And make the default value "unknown".
>>>>> 13. print-quality-supported, consider removing. Print quality is so
>>> printer-specific that I question the benefit of having it as an SLP
>>> search criteria.
>>>>Agree. This attribute is much fuzzier than nominal printer speed.
>>>>> 14. copies-supported, rename to max-copies-supported. For
>>> clarification.
>>>>Agree. And make default value "-1" mean unknown, not unlimited.
>>>>> 15. job-k-octets-supported, rename to max-job-k-octets-supported.
>>>>Agree. And make default value "-1" mean unknown, not unlimited.
>>>>> 16. printer-mechanism-types, consider adding.
>>>>As Tom already asked, what are the details of this attribute? Is this
>>printer technologies (e.g., inkjet versus laser)?
>>If so, both versions of the Printer MIB have the mandatory attribute
>>'prtMarkerMarkTech' with a rich list of marking technologies.
Yes, it is semantically the same as the Printer MIB's 'prtMarkerMarkTech'. Per the discussion at the beginning of this message, adding this attribute is probably just adding overhead, so I'd be happy to retract my initial proposal to have this attribute added.
>>>>>>>This is my first shot a this. If there are strong reasons for doing
>>> things differently, let's hear them.
>>>>>> -Hugo
>>>>>>>Thanks for this excellent first shot. If other folks could comment on
>>this template so thoroughly, it would be a big help - Ira
>>>-----------------------------------------------------------------------