Subject: Re: separation of service ids and service locators

From: Erik Guttman <[email-masked]>
Date: Tue, 2 Jan 2001 14:12:18 +0100 (MET)

> Erik,
> 
> >  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))
> >
> 
> I don't quite understand how this would solve the problem. Is the idea to 
> register an advertisement something like this;
> 
> 	service:id://3456789
> 	service-location=142.42.42.42
> 	service-type=service:printer
> 	
> I guess I don't see how that could solve the problem, since you still can't
> query for a specific service which is what you want to do.

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.  

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.

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: Tue, 02 Jan 2001 17:14:42 -0700

> different service:id and service-type pair.

Commenting on Erik's proposal for service id's and service locators...

Definitely not a good idea.  Let me explain my perspective:

First, the method proposed above for locating a service (the primary
function of SLP) at best requires *twice* the amount of network
traffic.  Using Erik's example:

Pretend you are an SLP developer(writing an SLP implementation or using
the RFC 2614 API)...  What if the above SrvRqst elicits several
responses -- say 10 printers respond.  Now the API has to either return
completely undescriptive "service:ids" to the caller of SLPFindSrvs() or
make calls through the AttrRqst code to return an actual URI that the
caller will be able to understand.  With out the existence of a DA this
would represent a unacceptable increase in broadcast or multicast
traffic -- not to mention delay for the caller. 

Second, for embedded, UAs, using service:ids effectively doubles the
amount of code needed to simply locate a service (again, the primary
function of SLP).  UA's would be required to encode ATTRRQST and decode
ATTRRPLY messages that are otherwise not needed for simple SLP usage.  

Third, service:id effectively adds a layer of abstraction and complexity
to SLP.  From a developer and user perspective it lengthens the path
from "information I have" to "information I want".

Fourth, who determines the service ID and how is it guaranteed to be
unique among registered services?  A unique Service ID can not be
generated by the developer because there is no way of knowing which
service:id's are already in use.  The API could not determine the
service:id either because (with out an API change) there would be no way
of telling the caller of SLPReg() what the service:id is so that it can
be used in SLPDereg().  

Finally, with out service ids, it is easy for developers and users to
think of SLP as a mechanism for equating service types to Service URLs. 
Adding a layer of abstraction (the service id) is not a good idea. 
Mucking with even with current SLP usage patterns will be very bad for
SLP's adoption as a standard.  

The SLP spec need not be concerned with locating specific daemon
instances.  Location of specific daemon instances is beyond the scope
RFC 2608 and should instead be a task of the software developer.  As
suggested by Erik's service:id proposal, creative developers will be
able to do many things with SLP, but SLP should be very careful to
dictate too much. 

In other words, developers should be free to use Erik's solution or one
or their own depending on what is best for them.  Location of specific
service instances is a perfect example of a specific problem that can be
solved by SLP developers in a way that is optimized for a specific
application or application framework.  SLP should be very careful not to
mandate SLP usage patterns for this and other application specific
problems.  RFC 2608 should be primarily concerned with standards that
will effect interoperability between *SLP implementations*.  It should
probably not be concerned with differences in the usage of SLP.  

In case there is a question as to the validity of the claim that service
instance location is a developer problem and not an SLP problem,
consider the ease with which Erik was able to come up with a proposed
solution involving only a modified usage of the existing SLP standard. 
Likewise, I can think of at least 2 alternative solutions which solve
the problem of service instance location that do not in anyway change
the underlying SLP implementation or SLP API.   An obvious rule would be
to not change RFC 2608 unless the change is directly related to SLP
internals.  The proposal by Erik is an SLP usage change only and does
not belong in RFC2608bis.  

In special cases (like service templates) SLP usage standardization
should be regulated via separate RFCs, but in most cases, I do not think
any regulation of SLP usage is necessary or appropriate.  Given
differences in platforms (embedded and otherwise), operating systems and
network environments it is a very long shot at best to expect that SLP
implementors will come together on a "global" standard for
identification of service instances.  (Remeber we're talking about
daemon PIDs here!)  On the other hand, in cases where identification of
actual service instances are considered to be very important for a
particular application or application suite.  In this case, developers
will solve the problem in a way that is optimized particular
application.  

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