Subject: Re: separation of service ids and service locators

From: "Erik Guttman" <[email-masked]>
Date: Wed, 3 Jan 2001 14:07:14 +0100

Matt,

Thanks for your thoughtful reply.  My comments follow.

>>     It seemed simpler at the time.  In retrospect we created a number
>>     of problems.  (1) One locator (like a http: or mailto: url) can
>>     be used for many 'services'.   This is commonly the case when
>>     the http or mail service is actually a *gateway.*  (2) One service
>>     can have multiple locations, like a server which has multiple
>>     addresses (hence multiple URLs).
>
>In practice, the only problem we need to address is idea that one
>service URL (like http: or mailto: url) can or should be used for many
>services.
...
>Someone, please give me one example of where it would be beneficial or
>necessary to register a service with an ambiguous URL (case #1 of Erik's
>quoted message above).

I can't see a benefit of an ambiguous URL per se - but I can see that
some services function as gateways, so they are by their nature multi-
purpose.  A single URL could be ambiguous.

>Here is what would happen. I would probably instrument Webmin code so
>that it registers a service-type=webmin with a service URL of
>service-url = http://<host>:<port>.  My administration console (nothing
>more than an SLP enhanced web browser) would query for all services of
>service-type = webmin.
>
>What if I only wanted only to make changes to configuration of all of
>the hosts running mySQL?  Well, I would also have to have each webmin
>module register their URL like service-type=webmin.mysql
>service-url=http://<host>:<port>/mySQL for the mySQL webmin module or
>service-type=webmin.apache service-url=http://<host>:<port>/apache for
>the Apache Webmin module.

I do not like this solution - it uses a naming authority (with incorrect
syntax
and against guidelines).  If we want interoperability, we need to have a
service type which complies with a registered template.  For instance, we
could create service type:

   service:webmin:
   service:webmin:mysql
   service:webmin:apache

etc.  Then we could find the webmin services in general, or only thos for
mysql, or whatever.

I accept that this solves the 'gateway' problem.   I also agree with your
point that any host which registers services can deregister them - so
the need to do deregistrations of all service locations doesn't require
a service id.

What is not solved by the existing mechanisms is the ability to relocate
the same server after its address/name changes.

>>  b. We could change the format of SrvReg, SrvDereg and AttrRqst and
>>     URL Entries  to include service UIDs.  We would have to change
>>     the semantics as well as the on-the-wire protocol.  This would
>>     require us to create SLPv3 and cycle it at proposed standard.
>
>Definately do not do this
>

I *totally* agree.

>In conclusion, please know that I am not trying to be rudely critical.

It was very constructive, to the contrary!

>My intent is to try to reveal my perspective of SLP usage patterns and
>start conversation that will help me to change my view if I am overly
>conservative.  It obvious that I don't think separation of service IDs
>and service locators is a good idea for a generalized SLP specification
>(RFC 2608).  It might be appropriate for specialize applications which
>is best addressed by the application developer.  From my point of view
>SLP need not try and solve this and every other little problem in the
>SLP spec.

I suggest that the best way to achieve rediscovery of the same service
is to register an attribute 'service-id' which will remain the same across
reboots, renumberings and renamings of a server.  A UA which wishes
to rediscover the same service, it can include this ID in subsequent
search filters.

Erik

---

From: Matt Peterson <[email-masked]>
Date: Wed, 03 Jan 2001 10:43:28 -0700

> purpose.  A single URL could be ambiguous.

I agree that a single URL *could be* ambiguous, but so can an IP address
if two machines are configured to use the same one.  My point is that
even though URLs *can be* ambiguous in gateway situations, they are
usually *not*.  I don't think SLP needs to address the related problems
in RFC 2608 because hopefully common sense will prevail and developers
have not and will not write application layer gateway software that
ambiguates URLs.

> etc.  Then we could find the webmin services in general, or only thos for

Actually this does look a little better.  Sorry for slaughtering the
naming authority spec ;-{
 
> to rediscover the same service, it can include this ID in subsequent

Right.  This is a good solution and I agree that re-location of the same
service instance (one with a specific configuration, state, or whatever)
would be an important facility in some application frameworks.  However,
I do not think that it is something that deserves special attention in
RFC 2608. As you mentioned above, the problem can be solved using SLP as
it currently exists.  As you suggest, all the developer has to do is
make creative use of the existing flexibility of SLP and this and many
other problems can be solved with out any change to RFC 2608 or RFC
2614.

Don't you agree that the above mentioned problem is an SLP *usage*
problem not an SLP *internals* problem?  As such, I think the discussion
of the solution (and possibly many others) belongs in the forum of an
"SLP Programmers Guide" not in the Service Location Protocol spec.  

Regards,

-- 
Matthew Peterson
Sr. Software Engineer
Caldera Systems, Inc
[email-masked]

---

From: Erik Guttman <[email-masked]>
Date: Wed, 3 Jan 2001 21:34:45 +0100 (MET)

...
> > reboots, renumberings and renamings of a server. 
> 
...
> problem not an SLP *internals* problem? 

I do - but I really wanted to explore the issue publicly before jumping
to that conclusion.

Erik

._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
E r i k   G u t t m a n         SHORT msgs: [email-masked]
Sr Staff Engineer, Sun Microsystems       Email: [email-masked]
Eichhoelzelstr. 7, 74915 Waibstadt Germany    Phone: +49 172 865 5497