IPP Mail Archive: IPP> FW: A proposal for SLP evolution [no attributes?]

IPP> FW: A proposal for SLP evolution [no attributes?]

Ira McDonald (imcdonal@sdsp.mc.xerox.com)
Sat, 23 Jan 99 18:45:47 EST

Hi folks, Saturday (23 January 1999)

The following message just appeared on the IETF SLP WG mailing list,
proposing that SLP be reduced to 'discovery' only, and all 'attributes'
be removed from the SLP protocol.

I confess that I'm unable to imagine how you could build 'discovery',
which was useful in the real world, without 'attributes'. I'll forward
the thread (or excepts) if anything interesting comes of this proposal.

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

> ----------------------------------------------------------------------
> From: Peter Ford <peterf@microsoft.com>
> To: "'srvloc@srvloc.org'" <srvloc@srvloc.org>
> Subject: A proposal for SLP evolution
> Date: Fri, 22 Jan 1999 21:10:07 -0800
>
> In discussing discovery with people with wildly different products we have
> discovered that most have one requirement in common (discovery) and have
> many other requirements in a common area (directory). Unfortunately, their
> requirements in directory are divergent.
>
> SLP was originally designed when there were few (if no) options in directory
> and one result is that SLP now has quite a bit of directory functionality.
> Today, we have established, IETF working group documents for directory
> functionality (e.g. LDAP, ...). Specifically, people have established
> other ways to obtain 'attribute' information and don't need yet another
> protocol for this. E.g. several companies are using simple HTTP based
> operations for directory functionality, others are using LDAP, etc.
>
> We would like to propose that the discovery and directory functionality of
> SLP be separated with the result being a single base protocol for discovery
> with the expectation that there will be more than one solution/protocol for
> directory access of attributes. This would entail dropping attribute
> request/response from SLP and service type request/response. This one
> document would specify: UA & SA Service Request, Service Reply; SA & DA
> Service Register & Deregister; UA & DA Service Request, Service Reply
> ; as well as DA and SA discovery.
>
> We believe this proposal makes SLP simpler, smaller in implementation which
> is important for embedded devices, and meets the requirements that customers
> have.
>
> Peter Ford
> Ye Gu
> Microsoft Corporation
>
> // standard disclaimers apply //
> ----------------------------------------------------------------------