Hi,
VERY interesting new work on a next generation Service Discovery
protocol and framework, heavily based on SLPv2 (RFC 2608).
Much more sophisticated (load balancing, GUID service IDs rather
than mere URI for unique services, etc.) than any service
discovery protocol I've ever seen. If this advances in IETF,
it will be a force to be reckoned with in the future.
Recommended reading.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com
-----Original Message-----
From: Manuel Urueña [mailto:muruenya at it.uc3m.es]
Sent: Thursday, March 25, 2004 11:35 AM
To: srvloc-discuss at lists.sourceforge.net
Subject: [Srvloc-discuss] FYI: eXtensible Service Discovery Framework
(XSDF)
Hi all,
I've been working on a evolution of the SLP protocol called XSDF and I
am very interested in the feedback from the SLP community, as most of
the ideas, including the architecture itself, are owed from it.
I've started to think about an enhanced SLP after reading Guttman
serviceid draft, which identifies the problems derived from identifying
a Service by its URL. Also related to this, I started believing that SLP
service model was too simple to represent certain services, for example
when multiple network/transport/application protocols are available.
That led to define a new Service model and a compact binary encoding to
serialize XSDF messages. That new service model defines a set of
standard attributes, for example to enable load balancing when multiple
servers are found (from Rserpool WG requirements).
As I was designing a new protocol to overcome these issues, I also
wanted to integrate some optional capabilities defined for SLP, which
are very interesting. For example Zhao et al. remote DA discovery, mSLP;
and Kempf et al. Notification & Subscription.
However, the protocol became so big that I did prefer to split it in
several ones. For example XSLP is employed to query SAs/DAs for
services, SAs employ XSRP to register their services in DAs (if any),
and XSSP and XSTP are employed to keep DAs from the same Realm in sync.
At last, I have been able to bring all together and I've just submitted
several drafts that define XSDF:
http://www.ietf.org/internet-drafts/draft-uruena-xsdf-overview-00.txthttp://www.ietf.org/internet-drafts/draft-uruena-xsdf-common-00.txthttp://www.ietf.org/internet-drafts/draft-uruena-xslp-00.txthttp://www.ietf.org/internet-drafts/draft-uruena-xsrp-00.txthttp://www.ietf.org/internet-drafts/draft-uruena-xssp-00.txthttp://www.ietf.org/internet-drafts/draft-uruena-xstp-00.txthttp://www.ietf.org/internet-drafts/draft-uruena-xbe32-00.txt
The xsdf-overview draft resumes the whole thing in just 20 pages.
If you are interested in a particular protocol, they are specified in
separate drafts, while xsdf-common contains the elements and procedures
shared by all of them. At last, the xbe32 one defines the binary
encoding for XSDF messages.
Thank you very much for your time !
Best regards,
--Manuel
--
Manuel Uruen~a - Universidad Carlos III de Madrid
GPG FP: 68A1 164B EE28 52C9 87CB EBF9 616E 52B5 451A B6B2