All,
Here is one of the notes from the SLP conversation on co-resident services.
At the end is the URL to where you can join or look through the archive.
Pete
Peter Zehler
XEROX
Xerox Architecture Center
Email: PZehler at crt.xerox.com
Voice: (585) 265-8755
FAX: (585) 265-8871
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-30E
Webster NY, 14580-9701
-----Original Message-----
From: Erik Guttman [mailto:Erik.Guttman at Sun.COM]
Sent: Wednesday, January 08, 2003 5:34 AM
To: Mayer, Jim
Cc: 'Erik Guttman'; Dan Nuffer; mdday at us.ibm.com;
srvloc-discuss at lists.sourceforge.net; Matt Peterson
Subject: RE: [Srvloc-discuss] Re: your view on
draft-guttman-svrloc-servic eid-02.txt
On Mon, 6 Jan 2003, Mayer, Jim wrote:
> One of the issues that the serviceid scheme was (I thought) going to help
> address was the proliferation of service advertisements.
For folks using SLP to contact management devices, it was simpler to
group attributes by the access point. The only thing they required was
to know, definitively, that a set of service access points were in fact
accessing the same service, over time, irrespective of change in address
and independent of access mechanism.
Once we start down the path of a general service record, we have to
seriously bend the text based SLP attribute mechanism. Either we
should *break AttrRply* and allow record based attributes, or I believe
we should stick with the simpler approach of adding a serviceid
attribute for collating different service replies.
> The multiplexing is necessary because the URI, transport, and security
> protocol may all be tightly associated with each other.
Either by
(a) separate responses (my current proposal)
Simple to explain and use, a bit heavy on the network
(b) complex attribute lists embedded in attributes (serviceid-02)
Which is really nasty to explain and use
(c) breaking attribute lists, changing SLP itself, etc
Will take a long time to get adopted, if it gets adopted.
> I would really like to avoid having to make a seperate advertisement for
> every possible combination of transport and access security, which is
where
> the proposal seems to be going.
I understand that, but there is a trade-off of complexity given SLP's
constraints and verbosity.
> Things I'd like to be discoverable for a multi-function device include:
>> 1) Find me the adminstration service for the device that supports this
> printer (or scanner, etc.)
> 2) Find me the services supported by this device.
> 3) Find me the printer(s) (scanner(s), etc.) supported by this device.
>> Perhaps "device" should be generalized to multple "groups"? Just a
thought.
A fruitful direction would be to define a device advertisement. One
could list device characteristics, even serviceids of services the
device supports. Anyone want to take a stab at that template?
Some will view this as going pretty far down the road of using SLP
as a management protocol, but so what.
Erik
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Srvloc-discuss mailing list
Srvloc-discuss at lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/srvloc-discuss