Subject: separation of service ids and service locators

From: Erik Guttman <[email-masked]>
Date: Fri, 22 Dec 2000 17:52:49 +0100 (MET)

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

 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.

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

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

Analysis

  a. Is where we are today.  I believe we should find a solution to
     this problem.

  b. Is really a non-starter.  SLPv2 has been standard for 18 
     months and its adoption has been gradual.  We do not want
     to further slow it down.

  c. Has numerous problems with interoperation between hosts 
     which support the SID extension and those that do not.
     Since many won't, this solution doesn't really address
     the problems of SLPv2.

  d. This is a hack and it isn't clear that it handles the
     case of a single service location gatewaying several
     services well.  

  e. This seems to address all the problems by whacking the 
     basic notion of the service URL.  The one thing that it
     loses is its basic meaning - it is impossible to use a
     service:id URI to actually access a service.  To do so,
     one would have to use the service-location attribute.
     For services with multiple locations and multiple types,
     but one serivce:id this could get pretty complicated.
     There is a lot to work this out, but I think its the
     most promising approach.

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

---

From: Matt Peterson <[email-masked]>
Date: Fri, 22 Dec 2000 10:12:06 -0700

Before I comment further, can you offer a few quick clarifications...

Erik Guttman wrote:
> [snip...]
>     the http or mail service is actually a *gateway.*  

What do you mean by gateway here?  Can you give an example

>     (2) One service can have multiple locations, like a server which
>     has multiple addresses (hence multiple URLs). This complicates 
>     the following operations:

Are you talking about a multi-homed machine here or something more
complex?
 
>         accessible through a single location).

I think I know what you mean by a gateway (a proxy?)  Can you give an
example?

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