Subject: RE: IPP> SLP 'printer:' template comments

From: "Hastings, Tom N" <[email-masked]>
Date: Fri, 8 Jan 1999 15:26:07 -0800

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:[email-masked]]
>Sent: Thursday, January 07, 1999 16:24
>To: [email-masked]; [email-masked]
>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
>

---

From: Ira McDonald <[email-masked]>
Date: Sat, 9 Jan 99 16:45:20 EST

Hi Hugo and Tom,

I read your two notes.  I want to think about some of the
points a bit more, before replying.  I do think that a 
(smaller) set of Mandatory attributes with well-known
empty values (e.g., 'unknown' in all strings and '-1'
in all integers) is an attractive idea.  I also think
we need to avoid adding too many (optional or mandatory)
attributes to the base 'printer:' abstract template,
or we rapidly reduce useful interworking based on
directory entries (in SLP and LDAP directories with
the 'printer:' template/schema).

Hugo, I believe there's something funny is saying
that 'natural-language-configured' (which in a printer
that also supported the Printer MIB MUST agree with
the 'prtGeneralCurrentLocalization in my opinion)
could be 'client-dependent'.  If NDPS has any strings
at all that the SA configures on a server, then the
default language for those strings should be
exported via 'natural-language-configured'.

Separately, in the actual 'printer:' template,
'natural-language-configured' tells the user
what the language of the strings in actual 
attributes of a template instance (ie, a service
registration) is.  This isn't an informational
attribute in the template - it's a normative
attribute for reading the contents of a template
instance.

Cheers,
- Ira McDonald
  High North Inc
  716-461-4667
  (oops, 716-461-5667 that is)

---

From: Ira McDonald <[email-masked]>
Date: Sun, 10 Jan 99 13:17:53 EST

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)?

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).

Cheers,
- Ira McDonald (outside consultant at Xerox)
  High North Inc
  716-461-5667

>-----------------------------------------------------------------------
> To: <[email-masked]>, <[email-masked]>
> Cc: "Hugo Parra" <[email-masked]>,
>     "Dale Bethers" <[email-masked]>,
>     "Mark Killgore" <[email-masked]>
> 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,

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)?

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?

> 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?

> 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?

> 5. printer-service-person, make it multi-valued.

Agree.  And make the default value "unknown".
Should we change this attribute name to plural?

> 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.

> 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

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.

> 
> 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
>-----------------------------------------------------------------------

---

From: "Hugo Parra" <[email-masked]>
Date: Tue, 12 Jan 1999 16:02:03 -0700

I've added my comments to Ira's message below.
-Hugo

>>>>> Ira McDonald <[email-masked]> 01/10/99 11:17AM >>>
>>

I'm in favor of adding the color speed attribute as optional.

>>values of 'unknown' (string or enum) or '-1' (integer).

I agree 100% with Ira's comment.

>>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. 

>>'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.

>>of the 'printer:' template?  Would 'nds-sec' add extra parameter(s) to

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.

>>Should we change this attribute name to plural?

Yes.

>>Should we change this attribute name to plural?

Yes.

>>> 7. natural-language-supported, add 'client-dependent' to legal values.

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).

>>'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.

---

From: James Kempf <[email-masked]>
Date: Tue, 12 Jan 1999 16:45:23 -0800 (PST)

>Let me comment on 'natural-language-configured'.  Like ALL of
>the IPP-derived attributes in the SLP 'printer:' template, it
>is meant to accurately reflect the actual configuration of
>the IPP Printer object.  However, since SLP (and LDAP) don't
>have any standard base datatype 'textWithLanguage', the
>'natural-language-configured' attribute does double duty
>to specify the language of SLP (and IPP Printer object)
>attributes with 'textWithLanguage' or 'nameWithLanguage'
>(such as site-administered media names, which are very
>important in enterprise printing environments).
>
>This is conformant with RFC 2277 (IETF Policy on Charsets
>and Languages) which MANDATES that all application protocols
>which transfer text shall explicitly convey the language
>of that text.  It is NOT optional for an IETF standards-track
>document to put language-tags on text attributes.  It is 
>a requirement to stay on the Internet 'standards track'.
>

Don't know if this is relevant to the discussion, but each SLP protocol
request includes a language tag that indicates which natural language the
attributes of the sought-after advertisements should be in. If the directory 
agent supports the service type but not in the language of the request, then it 
returns a LANGUAGE_NOT_SUPPORTED error. According to Erik Guttman, this makes
SLP conformant to RFC 2277.

In addition, draft-ietf-svrloc-service-scheme-13.txt, the standards
document describing how SLP service templates are standardized,
states that a service template must be submitted with an indication
of the natural language with which the template was composed. The
language does not show up in the template itself because the language
is part of the service advertisement when registered.

That said, there is no way to browse the set of languages 
supported by the DA. Nor can a client find out from the set of
attributes what their natural language is. So if that kind of information
is important for the attributes (say for a Web search engine that
returns results in different languages) then it should by all means
be included in the attributes.

		jak

---

From: erik guttman <[email-masked]>
Date: Tue, 12 Jan 1999 16:43:58 -0600

Ira and others,

SLP service de/registrations and requests are all language tagged.
This means that the attributes and other strings which are transported
by SLP are always explicitely language specific.  This is in full
conformance with RFC 2277.  There is no need to include an attribute
identifying the language of the other attributes since there is an
explicit language tagging used in every SLP message.  This language
tag is exactly that specified by RFC 1766. 

Erik

Ira McDonald wrote:
> 
> Hi Hugo,
> 
> Thanks for the quick and thorough response.
> 
> We COULD have a separate attribute for the language
> of the SLP 'printer:' template text and site-name
> attributes, but it seems an entirely reasonable simplification
> to presume that a system administrator would: 1) install
> a network printer (connectivity setup); 2) set the
> 'natural-language-configured' of that printer; and 3) set
> various site-specific info attributes of that printer.
> So the current SLP 'printer:' template makes sense.
> 
> What do you think?
> 
> Cheers,
>   716-461-5667 (w/ voice mail)

-- 
--------------------------------------------------------------------------
Erik Guttman                                     Germany: +49 7263 911 701
Sun Microsystems - Advanced Network Development  USA:      +1 650 786 5992

---

From: erik guttman <[email-masked]>
Date: Tue, 12 Jan 1999 16:43:58 -0600

Ira and others,

Erik

---

From: "Hugo Parra" <[email-masked]>
Date: Wed, 13 Jan 1999 01:21:35 -0700

Thank you Ira for clarifying how we  intent to use 'natural-language-configured' in the 'printer:' template.

James and Erik beat me to where I was heading.  As an SLP_API user, I know that a natural language must be specified with each SLP registration and request, independently of the type of service being registered/searched.  It seems to me then that both SLP and IPP have already conformed with RFC 2277; SLP by requiring the natural language associated with each SLP request/query (regardless of the template being used) and IPP by supporting 'natural-language-configured' in its object model.

It would appear then that the reason for having 'natural-language-configured' and 'natural-language-supported' in the 'printer:' template is mostly for convenience, so users can get to that information without making an additional request to the printer (and as I indicated in my previous message, I question how useful that feature really is).

OK so here are some options I'd like you to consider (1 being my first choice and 3 my last):

1. Do away with both attributes 'natural-language-configured' and 'natural-language-supported' in the 'printer:' template.

2. Keep both attributes but make them optional.

3. Keep both attributes as mandatory but add 'unknown' as a legal value.

Any takers?
-Hugo