The only issue/question I have is whether making more attributes OPTIONAL is
a good idea, versus keeping them MANDATORY with unknown as the default. In
fact, we might want to make more attributes MANDATORY with unknown as the
default value.
The answer to which depends on the search filter mechanism in SLPv1 and
SLPv2 and whether you can specify a 'not-present' as part of the filter in
both or not. If you can, then not present is the same as being present with
an unknown value and we can have few MANDATORY and many OPTIONAL attributes.
However, if you can't specify 'not-present' in a filter in SLPv1, then
there is real advantage to having the unknown value, to making many
attributes MANDATORY, and to have the SLP server default the value to
unknown, if the device doesn't include the attribute in its registration.
See my other comments below.
Tom
>-----Original Message-----
>From: Hugo Parra [mailto:HPARRA at novell.com]
>Sent: Thursday, January 07, 1999 16:24
>To: ipp at pwg.org; srvloc at srvloc.org>Cc: Dale Bethers; Mark Killgore
>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 */
>2. uri-security-supported, add 'nds-sec' to legal values.
>3. printer-location, make it optional. Very few
>administrators set this up today and it's optional in IPP.
>4. printer-current-operator, make it multi-valued. PServer
>and NDPS support multiple operators.
>5. printer-service-person, make it multi-valued.
>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.
>7. natural-language-supported, add 'client-dependent' to legal values.
>8. document-format-supported, make it optional. It's not
>always available to print servers front-ending legacy printers.
>9. color-supported, add 'unknown' as legal value.
I think we agreed to add "unknown" to many of the attributes. All the
attributes?
>10. sides-supported, consider making optional.
>11. media-supported, make optional.
>12. media-local-supported, make optional.
>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.
I agree.
>14. copies-supported, rename to max-copies-supported. For
>clarification.
Good idea. So the attribute is the maximum number of copies, not min and
max
as in IPP. So since it is a different attribute than IPP, its better to
have a different (and clearer name).
>15. job-k-octets-supported, rename to max-job-l-=octets-supported.
I assume you meant: max-job-k-octets-supported. I agree for the same
reason.
>16. printer-mechanism-types, consider adding.
What is the semantics of this attribute?
>>This is my first shot a this. If there are strong reasons for
>doing things differently, let's hear them.
>>-Hugo
>