Subject: Re: separation of service ids and service locators

From: James Kempf <[email-masked]>
Date: Tue, 2 Jan 2001 09:57:28 -0800 (PST)

Hi Erik,

Thanx for the reply.

>I see why my text confused you.
>
>The basic idea does allow you to query for a specific type.
>
>The request looks exactly the same as it would in current SLPv2:
>
>  service-type=service:printer
>  scope=whatever
>  filter=(&(duplex-mode=true)(etcetra=342))
>
>This returns the instance 
>
>  service:id://3456789.  
>
>You get the attributes for this service in order to discover how to 
>contact it, for example:
>
>AttrRqst:
>
>  URL = "service:id://3456789"
>  scope = whatever
>  tag-list = service-location
>
>Returns:
>
>  service-location=ipp://142.42.42.42:8295/foo
>
>This is what you want.  So you get both properties (1) deregistration
>by ID, even if the same IPP service, for example, has multiple URLs by 
>which it can be accessed.  (2) Identification, even if the service 
>changes locations.  
>

I guess I still don't see what this buys you. I though the purpose
of identifying the service by an id as opposed to by a service
access point was to allow requests by id rather than by service
type. In this scheme, you are still required to request by type,
unless you are also advocating putting the id into an attribute.

>Finding out about a gateway (say HTTP) service which really supports 
>several service types (via proxy) would be hard - that is something 
>that SLP doesn't do very well in any case.  That is the reason for my
>arcane 'service:generic:' text above.  Let's forget I said that.  
>
>In the case that you have a service which actually supports several
>types of service, you could just register each service with a 
>different service:id and service-type pair.
>

I think this would be a good thing to support.

Here is one possible scheme for supporting request by id. Suppose
we use an abstract type scheme that encodes the actual service type
as the abstract type and the id as the concrete type. Here is
an example advertisement:

	service-url=service:printer:345676://color-guy.kinko.com
	protocols=ipp,lpr,smb
	<attributes here>
	
A query could now be made that would contain the id, so you would get
exactly the printer you want. Here's the SrvRqst:

	service-type=service:printer:345676
	scopes=<scope-list>
	query=<empty>
	
Perhaps a similar trick could be used for gateways. Something like:

	service:http-gateway:ipp://129.143.42.42
	service:http-gateway:lpr://129.143.42.42
	service:sip-gateway:call-forwarding://forwarder.sprint.com
	
This would be a naming convention in which the gateway type name
followed the ABNF:

	gateway-abstract-type = gateway-protocol "-gateway"

I think both the scheme you have proposed and what I am proposing above
require no change in the basic protocol, service type definition
scheme, or API, and I think this is something we should aim for. A 
BCP or something like that which defines how to do this would be 
the right way to go. Therefore I think we ought to separate it from
the SLPv2bis discussion, since I don't think it will have much of
an impact on the protocol or API.

		jak

---

From: Matt Peterson <[email-masked]>
Date: Tue, 02 Jan 2001 17:14:37 -0700

Erik Guttman wrote:
> 
> There are 3 things which are somewhat conflated in SLP:
> 
> 1 - Service Type - used for searches (a wildcarding technique)
> 2 - Service Locator - the URI of the service
> 3 - Service Instance - the unique id of the service
> 
> In SLP, we use 2 to mean both 2 and 3.  1 is simply used as a search
> key.  We use 1 only where
> 
>  - we are registering (to put the new service entry in the right index)
>  - updating (reregistering) to make sure that we are updating the right
>    indexes - if a subsequent SrvReg has an inconsistent service type
>    field we return a INVALID_UPDATE error
>  - SrvRqst message uses the service type string to access the right
>    service index
>  - SrvTypeRqst gathers all the service type string index fields (useful
>    only for top level browsers)
> 
> Why is the locator also the unique service ID?
> 
>     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.  As a developer, why would you ever want to use an ambiguous
Service URL?   Remember, somewhere some SA must register a service URL. 
Who in their right mind would write an SA that would register an Service
URL that would not be clear to the UA needing to locate a service? 
Given the current SLP spec, this is possible, but utterly absurd. 
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 am trying to understand Erik's example of a "gateway" where one
Service URL could represent several services.  In practice I do not
think this is a possiblity.  True, many services can be offered via an
HTTP gateway (mail, administrative tools, etc...), but the fact still
remains that even services available via an HTTP gateway (embedded
server, cgi or php backend) still have canonical URLs.  Either the path
or port portions of the URL must be unique or the URL would be ambiguous
even to the HTTP servers and browsers.  

Let me illustrate with the following example:

Perhaps you are familiar with webmin a tool that enables web based host
administration (http://webmin.com/webmin/).  All webmin modules (nut and
bolt pieces that perform actual configuration tasks) use generated http
content so that administration can be performed via a web browser. 
Numerous webmin modules exist but do not necessarily have to be
installed.  Modules exist for adminstration of mySQL, Apache, Bind,
Squid, and even OpenSLP.  This is a classic example of an HTTP gateway
-- Webmin itself is a service but so are each of it's modules that
perform a particular administrative task.   

Suppose that Caldera, Inc writes an integrated administration tool based
on Webmin and SLP. I would want to locate webmin services via SLP. But
wait, I should have problems doing this because Webmin is a gateway,
right?   Wrong.  Webmin and every other application layer gateway I can
conceive is conspicuously written so as to NOT ambiguate URLs.

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.   

Each gatewayed service (webmin module) still has its own URL which can
be queried by type and located with out ambiguity. I can't think of any
application layer gateways where this would not be the case. Can you?

With regard to services that have multiple locations (case #2 in Eriks
quoted message above).  We are talking about something like a
multi-homed machine or a service farm, right?  Why is this a problem for
SLP?  It is not a problem for HTTP, DNS or TCP.  Don't you think that
developers of services will be aware that they need to register a
service URL such that each interface is locatable?  Don't you think that
they are smart enough to de-register all registrations?

What if a single service is supplied from multiple machines?  It's not
like this is anything new.  Load balancing appliances (that sit between
network and servers) have been around for some time that transparently
handle requests for web server farms and etc...   Any "farm service"
that expects to likewise operate with transparency would either need
special network, or transport protocols or special load balancing
hardware.  In either case the developer of the service would be aware of
how SLP registrations need to be made.

>     This complicates the following operations:
> 
>       - Deregistration: Deregister all the locations of a service
>         irrespective of its location (URLs)
>
>      - Identification: Find the same service again even if its
>        location changes.
>
>       - Gateway service inquiry: Find out the attributes of a
>         service offered by a gateway (that is, several services
>         accessible through a single location).

Can you please offer examples of where any of the above would be a
problem (something real like my webmin example above)?

> What can we do about this?
> 
>  a. Nothing.
> 
>     In this case, the three problems above are not addressed, and SLP
>     has to be used bearing its limitations in mind.

I do not see any limitations that could not be overcome by usage of
existing SLP protocol and API.  In fact I believe that this and other
"limitations" are problems for developers to resolve, not RFC 2608
 
>  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
 
>  c. We could create a SLPv2 SID (Service ID) extension, to be
>     used optionally.  If present, Deregistration, Identification
>     and Gateway service inquiry could be keyed off of the SID not
>     the URL - which is what we want.
> 
>     In order to accompany the SrvRply, which can hold multiple
>     service entries, a clever encoding would have to be used
>     in the SID extension.  Or they would have to be in the
>     same order as the URL entries (which is not a good idea,
>     hence this approach was not used in the Attrlist Extension.)
> 
>     If it accompanies a SrvReg it overrides the locator as the
>     uniquifier.  In that case, a SrvDereg or an AttrRqst with
>     this SID extension would delete or get the attributes for
>     the service registered with the SID.  There are several
>     interoperability issues to consider for those SLP agents
>     which don't support the SID.
> 
>      (1) If a SA w/ SID support registers with a DA w/ SID
>          support, should that prevent that registration from
>          being re/de/registered by a SA without SID support?
> 
>      (2) If a DA w/ SID support receives registrations from
>          SAs w/o SIDs, should it 'create' them?  No - since
>          these would be inconsistent between DAs and this
>          would lead to all sorts of problems.  So, some
>          services would have SIDs, others not.
> 
>      (3) A DA w/o SID support would not be able to use these
>          for managing services.  Thus SAs would have to be
>          able to use URLs for unique service identification
>          *anyway* (to maintain compatibility with existing DAs)...

An complex solution, something suitable for *optional* implementation.
 
>  d. We could define a special attribute 'SERVICE-ID.'
> 
>      If a service has multiple locations, it could be registered
>      N times, each with a unique URL, but all sharing a common
>      SERVICE-ID attribute.
> 
>      If a single gateway has several services that it is a gateway
>      for, it could register several service-id attribute values.
>      If these SIDs were structured so as to be coupled with service
>      types, a client could list them and see what kind they are,
>      as well as that they are a unique instance.  For example,
>      a http gateway to several services could have the service-id
>      attribute:
> 
>         (service-id=
>           SID-service:pointcast:http-10A9-8F3C-2019-B832-AA10-9D81,
>           SID-service:mailtunnel-a932-195b-2834-12DD-001f-9152)
> 
>      This would help solve two of the three problems:
> 
>      Identification:  The client could add Service-ID attribute
>      of a previously discovered service to the SrvRqst predicate.
>      Gateway service inquiry:  A UA discovering the http server
>      would acquire its list of service-ids.  Examining them, it would
>      see, for example, service:pointcast:http and service:mailtunnel
>      service types.  The UA could issue a SrvRqst with
> 
>   service-type = service:pointcast:http
>   predicate    = (SID-service:pointcast:http-10A9-8F3C-2019-B832-AA10-9D81)
> 
>      Having found the service, the UA can get its attributes (either
>      using an Attrlist extension on the SrvRply or an AttrRqst/AttrRply).

Why define a special attribute when "service id" information for
gatewayed services can always be encoded (and probably is already
encoded) in URLs
 
>   e. We define a new "service:id" service type and use this for
>      de/registration, and an attribute of each services which is
>      SERVICE-LOCATION.
> 
>      This would make solving Identification and  Deregistration easy,
>      but make solving Gateway Service Inquiry hard, unless the service
>      type were registered as an Attribute instead of as the 'Service-Type'
>      field in the query.  In effect, all service registrations for 'gateway'
>      type services under this suggestion would have the same service type
>         string, say "generic".
> 
>      This seriously mucks with the way the protocol is used right now.
>      Instead of registering an {identifier-location,type} tuple, we would
>      register an {identifier,generic} tuple, and force the use of
>      attributes for searching for services of a given type.  This would
>      require two requests for services of type "service:foo" -
> 
>        service-type = "service:foo"
>        predicate    = (some=query)
> 
>        service-type = "service:generic"
>        predicate    = (&(service-type=service:foo)(some=query))

This is an SLP usage solution suitable for deployment, but is not
something that should be specified -- recommended perhaps, but not
specified.  Regardless, it does not seem like something that belongs in
RFC 2608 as it does not affect the protocol, only the usage of it as it
is currently specified.

In conclusion, please know that I am not trying to be rudely critical. 
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.
 
-- 
Matthew Peterson
Sr. Software Engineer
Caldera Systems, Inc
[email-masked]
PGP Key: 9641 4E9B 8433 FC3E B899  A09E E12B 0490 8F8B C331

---

From: "McDonald, Ira" <[email-masked]>
Date: Wed, 3 Jan 2001 09:59:59 -0800

Hi Erik and Matt,

What constitutes SAME 'service instance' (even though both network
name and network address have changed) in this discussion thread?

Something as simple as a (large) integer 'service-id' attribute
doesn't seem likely to be useful as such a 'service instance'
unique identifier.  As Matt has observed, how could an advertising
service instance possibly create one know to be unique?

(Possible answer - The IEEE EUI-64 format used in Interface IDs
in IPv6 addresses in RFC 2373 would be a REAL safe prefix, if
a rebootable process-id was concatenated with it.)

I think I'm mostly in Matt's camp.  Do we want to address/solve
this (hypothetical?) problem in SLP 'standards track' specs?

Cheers,
- Ira McDonald, consulting architect at Sharp and Xerox
  High North Inc

-----Original Message-----
From: Erik Guttman [mailto:[email-masked]]
Sent: Wednesday, January 03, 2001 5:07 AM
To: Matt Peterson; Erik Guttman
Cc: [email-masked]
Subject: Re: separation of service ids and service locators

Matt,

Thanks for your thoughtful reply.  My comments follow.

>services.
...
>necessary to register a service with an ambiguous URL (case #1 of Erik's

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.

>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.

>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!

>SLP need not try and solve this and every other little problem in the

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