Printer Services Mail Archive: PS> SLP (srvloc) discussion o

PS> SLP (srvloc) discussion on sourceforge

From: Zehler, Peter (PZehler@crt.xerox.com)
Date: Wed Jan 08 2003 - 07:44:25 EST

  • Next message: BERKEMA,ALAN C (HP-Roseville,ex1): "PS> [PSI]: minutes 01/07/03"

    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@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@Sun.COM]
    Sent: Wednesday, January 08, 2003 5:34 AM
    To: Mayer, Jim
    Cc: 'Erik Guttman'; Dan Nuffer; mdday@us.ibm.com;
    srvloc-discuss@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@lists.sourceforge.net
    https://lists.sourceforge.net/lists/listinfo/srvloc-discuss



    This archive was generated by hypermail 2b29 : Wed Jan 08 2003 - 07:44:36 EST