Yes, I agree with all of you, but I think that my reply to Carl-Uno has been
misinterpreted and a non-issue has become the central point of discussion
while my original point has not been discussed at all.
I repeat my main point below, namely eliminating 'printer-uri-supported' and
changing the meaning of 'uri-security-supported' in the SLP printer template
proposed by Ira.
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
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
determined by finding all URI's containing a 'printer-name' with a
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.
At 08:02 PM 1/4/99 , Randy Turner wrote:
>>What difference does it make whether or not two SLP entries point to the same
>output device? This seems like an administrator issue. If the administrator
>wants two entries to point to the same output device, even across directory
>contexts (or within directory-local context) then we can support him. On the
>other hand, if the administrator wants to uniquely identify all output devices
>that are advertised, then he can do that too.
>>I'm trying to identify why we care if two different entries point to the same
>output device? All we have to do is give the administrator the "ability" to
>create uniqueness if they wish. I don't think we need to specify what is
>and what isn't. With respect to a directory entry, the "printer-name" is human
>understandable, as opposed to the URI string which may or may not be
>understandable to a human, but is definitely understandable by client
>>>>>At 06:44 PM 1/4/99 -0800, Robert Herriot wrote:
>>>> I agree that there is no guarantee that "printer-name" values are unique
>> even within a domain, but they should be unique as a practical matter so
>> that a user can uniquely identify a printer by its "printer-name" instead
>> the URL, at least in a local context.
>>>> There remains the issue of how does anyone determine if two separate SLP
>> entries (with different URLs) represent the same output device. I am
>> suggesting using a convention that a "printer-name" qualified by a domain
>> name and SLP scope uniquely identifies a printer.
>>>>>> Bob Herriot
>>>> At 05:02 PM 1/4/99 , Manros, Carl-Uno B wrote:
>> >I welcome this attempt to get a simpler SLP solution and in practice I
>> >we will find few printers that have more than one URI.
>> >However, your assumption in a) that you could use 'printer-name' to find
>> >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).
>> >-----Original Message-----
>> >From: Robert Herriot [mailto:robert.herriot at Eng.Sun.COM]
>> >Sent: Monday, January 04, 1999 4:38 PM
>> >To: Ira McDonald; imcdonal at sdsp.mc.xerox.com; ipp at pwg.org;
>srvloc at srvloc.org>> >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
>> >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
>> >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
>Sharp Laboratories of America
>rturner at sharplabs.com>-------------- next part --------------
An HTML attachment was scrubbed...