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

From: "Caruso, Angelo" <[email-masked]>
Date: Mon, 04 Jan 1999 15:23:26 -0500

Ira,

Thanks for the update. I have two questions:

1) Why was 'pages-per-minute-color' not added? I thought that we had reached
a rough consensus on this proposed new attribute on the IPP mail list, so I
am surprised to see it was not added. It seems like a pretty harmless
addition.

2) Shouldn't we propose a syntax for the representation of ordered lists as
part of the general SLP template syntax? It seems like a hack to invent a
new syntax for ordered lists just for the sake of the printer template.
Please note that I am not trying to intentionally delay progress on the
printer template, but it just seems like ordered list capability is pretty
fundamental and that printers are not the only networked services that might
benefit from ordered list attributes. My apologies if this has already been
discussed on the SLP mail list (of which I am not a member).

Thanks,
Angelo

---

From: James Kempf <[email-masked]>
Date: Mon, 4 Jan 1999 12:39:11 -0800 (PST)

>discussed on the SLP mail list (of which I am not a member).

The problem is that ordered lists are not supported by directory services
in general. LDAP does not have them. Since SLP is attempting to be
compatible with LDAP, SLP does not have them either.

If applications seem to feel that ordered multivalued attributes are
important for directory services, then perhaps a proposal for an
LDAP extension or addition is in order. 

		jak

---

From: Ira McDonald <[email-masked]>
Date: Mon, 4 Jan 99 17:18:31 EST

Hi Angelo,

Thanks to James for answering (2), that most existing directory
services don't have ordered multi-valued attributes, so of course
SLP is consistent and doesn't have them.  Also, to add such a
basic string syntax extension now to SLPv2 would be to leave
the SLPv1 environment still with the same problem (which wouldn't
please either the IETF IPP WG or the Open Group's NCMG Print WG).

To (1), why didn't I add 'pages-per-minute-color', my answer:
a) I was tired and wan't to get this thing out for review, like
   I promised to do about three weeks ago;
b) The 'pages-per-minute' black-and-white speed attribute
   is still just a proposal (and I don't think a formal one
   yet?) for IPP/1.0 itself;
c) I was unclear whether a lot of mostly silence on the IPP
   list with respect to 'pages-per-minute-color' and the SLP
   'printer:' template in general could be construed as
   assent to the two speed attributes (in Tom Hastings
   comments on the template from around the first week of
   December).

ISSUE:  Do IPP folks want two speed attributes (one for
nominal black-and-white speed and one for any form of 
color speed, highlight, two-color, four-color, whatever)?

Please state your opinions.

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

---

From: "Manros, Carl-Uno B" <[email-masked]>
Date: Mon, 4 Jan 1999 17:02:54 -0800

Bob,
 
I welcome this attempt to get a simpler SLP solution and in practice I think
we will find few printers that have more than one URI.
However, your assumption in a) that you could use 'printer-name' to find out
whether a printer has several URIs does not
seem correct. There is no guarantee that "printer-name' values are unique,
even within the same domain (at least not according to IPP).
 
Carl-Uno

-----Original Message-----
From: Robert Herriot [mailto:[email-masked]]
Sent: Monday, January 04, 1999 4:38 PM
To: Ira McDonald; [email-masked]; [email-masked]; [email-masked]
Subject: Re: IPP> Revised SLP 'printer:' template for comments

At our Tucson meeting, the IPP group agreed with James Kempf that there 
should be a separate SLP entry for each URI and that the URI associated with

the entry would be the printer's URI.  Ira, I know that you disagreed with 
this direction.

If we stay with this decision, it implies to me that there is 
   a)  no need for the 'printer-uri-supported' attribute in the template. It
can be 
        determined by finding all URI's containing a 'printer-name' with a
particular value.
   b)  'uri-security-supported' contains the security supported for the
associated URI and
        not for other URIs associated with a printer.
   c)  the complexity of two parallel attributes is eliminated.

Bob Herriot

---

From: "Zehler, Peter" <[email-masked]>
Date: Tue, 05 Jan 1999 03:38:36 -0800

Ira,
I am in favor of the two attributes in both the SLP printer: template and
the IPP model. 
Pete

				Peter Zehler
				XEROX
				Networked Products Business Unit
				Email: [email-masked]
				Voice:    (716) 265-8755
				FAX:      (716) 265-8792 
				US Mail: Peter Zehler
				        Xerox Corp.
				        800 Phillips Rd.
				        M/S 111-02J
				        Webster NY, 14580-9701

-----Original Message-----
From: Ira McDonald [mailto:[email-masked]]
Sent: Monday, January 04, 1999 5:19 PM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: RE: IPP> Revised SLP 'printer:' template for comments

Hi Angelo,

Cheers,

---

From: "Hugo Parra" <[email-masked]>
Date: Tue, 05 Jan 1999 11:30:47 -0700

At our Tucson meeting, James Kempf indicated that one important feature of the new version of SLP is that templates support inheritance.  The template associated with one scheme (e.g., printer.ipp:) can thus inherit standard attributes from another more basic template (e.g., printer:) and extend it with the mandatory and optional attributes that are only relevant to IPP printers.  I suspect (and in some cases I know for a fact) that a variety of printers (besides those supporting IPP and lpr) will want to use the printer: template (or a derivative thereof) to advertise their existence on the network.  

Is this effort the definition of the basic printer template or of the IPP extensions to that basic template?  I don't think they are one and the same as attributes that are mandatory in IPP may be optional or non-existent in other protocols and thus cannot be mandatory in the printer: template.

-Hugo

---

From: Ira McDonald <[email-masked]>
Date: Tue, 5 Jan 99 19:45:00 EST

Hi Hugo,

I haven't read the rest of this interesting thread yet, but I wanted
to answer your question (to whit, is this a general 'printer:'
template or an IPP template?).  Notwithstanding James Kempf's
presentation in Tuscon, the word 'inherit' does NOT occur in
the current SLPv2 Schemes draft (xxx-13) and I see no provision
in SLPv2 for inheritance (and certainly not in SLPv1 either).

Almost ALL of the attributes in the current draft have been there
for two years, since Pete St. Pierre (principal author) put them
there - the 'printer:' abstract service template is meant to
encompass IPP and LPR (and other print protocols by future
extensions).  The fact that a given protocol doesn't 
support a given capabilities attribute (like 'media-supported')
in the in-band protocol is not relevant.  The abstract
print service can be expected to support a few common
capabilities attributes (there aren't very many Mandatory
attributes in the 'printer:' template).

No doubt the rest of this thread poses equally interesting
questions.  I'll read it before our IPP Telecon tomorrow
(10-12 PST / 1-3 EST).

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

---

From: James Kempf <[email-masked]>
Date: Wed, 6 Jan 1999 08:54:12 -0800 (PST)

>Notwithstanding James Kempf's

Ira is correct that the word "inherit" does not appear in 
draft-ietf-srvloc-service-scheme-13.txt. However, the example at the
end of the document includes an illustration of how concrete types
inherit the attributes from abstract type templates.

Logically, since an abstract type without any concrete type cannot be 
registered, the attributes for the abstract type have no
meaning unless they are inherited by the concrete type template.
We should probably make this explicit in the specification, however.

		jak

---

From: Ira McDonald <[email-masked]>
Date: Wed, 6 Jan 99 12:39:45 EST

Hi James,

Thanks for straightening us out here.  I'll have to go look
at the example in '...Schemes' about concrete templates
inheriting from an abstract template.  One of my continuing
concerns is to get the 'printer:' abstract template to settle
down in content, so that we can look at making SLPv1-compatible
concrete templates for each of the print protocols (LPR, IPP,
'raw-tcp', etc), because there's a fair amount of SLPv1
deployed, but not much SLPv2 yet, and anyway interworking
with SLPv1 Directory Agents is a pretty high priority
(from the myopic perspective of the printer community
- I could be all wet on this one too...).

Cheers,

---

From: "Hugo Parra" <[email-masked]>
Date: Wed, 06 Jan 1999 11:14:36 -0700

Ira,

Though it is true that most of the attribute in he current draft have been there for some time now, they were mostly marked as optional.  In the latest draft, around ten of these attributes were changed to mandatory and that's what prompted me to  bring up this issue.

As I see it, we can take one of two approaches:

(a) Use inheritance (or whatever we want to call the new capability in SLP to use attributes defined by another, more basic template).  With this approach the IPP template can be very specific about what attributes MUST be present and what attributes MAY be included.

(b) Define a single printer: template with attributes provided or needed by IPP, LPR and others and make them all but a very basic few optional.

Can someone think of an additional approach?
-Hugo

>>> Ira McDonald <[email-masked]> 01/05/99 05:45PM >>>

---

From: "Hugo Parra" <[email-masked]>
Date: Wed, 06 Jan 1999 11:22:00 -0700

Ira,