>>>>> Ira McDonald <imcdonal@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@pwg.org>, <srvloc@srvloc.org>
>>> Cc: "Hugo Parra" <HPARRA@novell.com>,
>>> "Dale Bethers" <DBETHERS.PRV-MAIL1.PROVO@novell.com>,
>>> "Mark Killgore" <MKILLGORE.PRV-MAIL1.PROVO@novell.com>
>>> Subject: IPP> SLP 'printer:' template comments
>>>=20
>>> I'd like to propose the following changes to the SLP 'printer:' =
template
>>> spec recently distributed by Ira.
>>>=20
>>> 1. The template-url-syntax needs to include definitions for NDPS and =
TCP
>>> printers. The NDPS flavor would look as follows,
>>> ndpsurl =3D "ndps://" hostport [ nds-name / pa-name ]
>>> nds-name =3D "/nds/" fqn
>>> fqn =3D /* fully qualified NDS printer name */
>>> pa-name =3D "/pa/" printer-name
>>> printer-name =3D /* 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.=20
>>
>>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-confi=
gured' 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.
>>
>>>=20
>>This is my first shot a this. If there are strong reasons for doing
>>> things differently, let's hear them.
>>>=20
>>> -Hugo
>>>=20
>>
>>Thanks for this excellent first shot. If other folks could comment on
>>this template so thoroughly, it would be a big help - Ira
>>>-----------------------------------------------------------------------