I'm a member of the IPP (Internet Printing Protocol) Working Group.
I have recently begun updating the SLPv2 abstract service 'printer:'
template for alignment with the June 1998 drafts of IPP/1.0.
I forwarded this work to the IPP WG this week and we first discussed
it in some detail at out Wednesday telecon (1-3 EST, regularly)
this week.
The IPP/1.0 Model and Semantics spec defines an abstract protocol.
This is the reference in the 'printer:' template to 'abstract-protocol'.
The IPP/1.0 Encoding and Transport spec defines one concrete binding
for the IPP/1.0 abstract protocol (over HTTP/1.1, with 'http:'
concrete URLs). But other work-in-progress within the PWG
(Printer Working Group industry consortium) is addressing possible
bindings of IPP/1.0 abstract protocol over other transports,
so it is appropriate for a printer to register and declare
(at some future date) 'abstract-protocol=ipp' and
'concrete-protocols=http, tcp' (for example).
Also, the IPP Printer object defines the attributes
'uri-supported' (the full list of all URI supported
by this printer system) and 'uri-security-supported'
(the list of security methods supported by this
printer system). Through an oversight the
'uri-supported' was omitted from the March 1998
draft of the 'printer:' template - it has now been
added back.
IPP printers don't have to register ALL of their supported
URI separately - they just need to declare them
in 'uri-supported'.
I asked members of the IPP WG to cross-post comments
and discussion of the printer template to the Service
Location Protocol WG list. The intent was to finish
a coarse alignment with the latest IPP specs (the
primary source of attributes for the printer template)
and THEN to forward the revised template to the SLP WG.
Cheers,
- Ira McDonald (outside consultant at Xerox)
High North Inc
906-494-2434
------------------------------------
[in reply to...]
Return-Path: <owner-srvloc@srvloc.org>
Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1)
id AA15937; Fri, 30 Oct 98 07:43:31 EST
Received: from lysithea.eastgw.xerox.com by zombi (4.1/SMI-4.1)
id AA25842; Fri, 30 Oct 98 07:34:45 EST
Received: from wicked.neato.org (wicked.neato.org [198.70.96.252])
by lysithea.eastgw.xerox.com (8.9.1a/8.9.1) with ESMTP id HAA18808
for <imcdonal@eso.mc.xerox.com>; Fri, 30 Oct 1998 07:34:51 -0500 (EST)
Received: from localhost (daemon@localhost)
by wicked.neato.org (8.8.5/8.8.5) with SMTP id EAA19786;
Fri, 30 Oct 1998 04:34:23 -0800 (PST)
Received: by wicked.neato.org (bulk_mailer v1.5); Fri, 30 Oct 1998 04:32:23 -0800
Received: (from majordom@localhost)
by wicked.neato.org (8.8.5/8.8.5) id EAA19684
for srvloc-outgoing; Fri, 30 Oct 1998 04:32:06 -0800 (PST)
Received: from roma.axis.se (roma.axis.se [193.13.178.2])
by wicked.neato.org (8.8.5/8.8.5) with ESMTP id EAA19664
for <srvloc@srvloc.org>; Fri, 30 Oct 1998 04:32:00 -0800 (PST)
Received: from lundap.axis.se (lundap.axis.se [193.13.178.113])
by roma.axis.se (8.8.8/8.8.6) with ESMTP id NAA14086;
Fri, 30 Oct 1998 13:31:33 +0100 (MET)
Received: by lundap.axis.se with Internet Mail Service (5.5.2232.9)
id <45A43HLB>; Fri, 30 Oct 1998 13:31:29 +0100
Message-Id: <F576E429ACE8D111BE1500A0C9AA8CA18C2776@exchange.axis.se>
From: Mikael Pahmp <mikael.pahmp@axis.com>
To: "'Pete.StPierre@Eng.Sun.COM'" <Pete.StPierre@Eng.Sun.COM>,
srvloc@srvloc.org
Subject: SLP Printer Service Template
Date: Fri, 30 Oct 1998 13:31:22 +0100
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-srvloc@srvloc.org
Status: R
Looking at the proposed Printer Service Template, I have a
question regarding the use of the 'concrete-protocols' attribute.
The 'abstract-protocols' attribute is explained to be:
# The name of the abstract protocol which may be run
over
# any concrete types listed. For example, the
abstract
# protocol 'ipp' may be run over the concrete types of
http
# or 'mailto'
This makes sense since different network printing protocols may
use the same concrete protocol. By the way, it seems as another
abstract level of service types is needed - e.g.
'printer:ipp:http:' .
The 'concrete-protocols' attribute:
# The names of the concrete protocol types supported
# by the printer abstract service type. Example
values
# include http and lpr
Q: Why is this attribute there?
A printer supporting multiple concrete protocols should advertise
them as separate services. Anyone searching for services of the
abstract 'printer' type would receive all concrete printer
services and therefor know of all the available conrete protocols
supported.
/MiP
------------------------------------