Subject: The final plan for SLPv2 documents

From: Erik Guttman <[email-masked]>
Date: Thu, 04 Feb 1999 12:30:09 +0100

I am going to submit a draft 12 of SLPv2 and draft 14 of the service
scheme documents.  I will ask that these go forward for IESG balloting.

The only changes made to SLPv2 and the service scheme documents will be 
those which arose out of IETF last call.  The reason that I have waited
to the very last minute in order to submit this to the WG list is that
I have been attempting to understand the last call comments and reach
an accord over them which will allow us to proceed.  I believe I have
done that.

The changes to SLPv2 draft 11 are:

  1.  UTF8 is now written as UTF-8.

  2.  The INVALID_LIFETIME error is now REFRESH_REJECTED.  The two
      attributes which DAs could advertise "min-lifetime-interval"
      and "max-lifetime-interval" have been replaced by a single
      attribute "min-refresh-interval".  The problem with the two
      attributes were (a) What to do when "min" was greater than "max"?
      (b) If a service registered a service with the SLP API for time
      25 and there were two DAs, one with min=10, max=20, another with
      min=30, max=40, what interval should be returned to the service 
      to use to keep the service continuously refreshed?  What lifetime
      should the SA use for the registrations?  

      By using only one attribute and declaring that this is the minimum
      *refresh* interval, the SA can always choose a lifetime and refresh
      interval greater than the largest minimum supported by all the DAs 
      and simply and correctly propogate registrations to all DAs.  
      Similarly, the SLP API can expose this as the minimum lifetime.

      The way draft-11 was written, it was unclear what to do.  This 
      tightens the language and simplifies the requirements.

  3.  The bibliography has been cleaned up.

  4.  An appendix will be added that describes how SLP would function if
      SAs only advertised services without attributes.  Namely:  Language
      Tags, overflow and TCP, predicate handling, attribute request and
      attribute list registration would not be necessary.  This would 
      limit discovery of services advertised by these service agents to
      'by service type and scope' only.

  5.  An appendix will be added to clarify what to do with DAAdverts
      which contain URLs which are not understood by UAs or SAs.  Currently
      the spec is silent about what to do when an unsolicited DAAdvert is
      received in passive DA discovery if the DAAdvert contains a URL other
      than a 'service:directory-agent:' scheme URL.  Such other URLs might
      be multicasted by a different directory service to inform UAs and SAs
      to use a different directory access protocol:  For instance LDAP or
      JINI or something else we haven't invented.

      UAs and SAs which receive URLs they can't use in DAAdverts silently
      discard  the DAAdvert.

      The only legitimate reason to multicast DAAdverts is by services 
      which act as directories - aggregating service information and serving
      client systems which wish to discover those resources.  Initially we
      believed that everyone would employ the SLP directory access protocol 
      (SLP UA to DA and SA to DA interaction), but it is already clear that
      others are using LDAP and JINI for this purpose.  It is therefore only
      right that we allow for these other mechanisms to advertise their 
      presense.  We will *NOT* require their use, nor even *DEFINE HOW* to use
      these URLs.  We will simply ignore them and allow for future documents
      to describe how they are used.

      This in no way negatively impacts correct SLPv2 UA and SA implementations
      which will discover and use SLPv2 DAs.

These changes make no modification of the protocol (save point 2 which
is only a small change of the names of some fields and their interpretation).
So we will not go back through WG or IETF last call for these documents.

The changes to the service scheme document from draft 13 to 14 are:

  1. I removed the 'lpr service template' reference, since this template
     has not been worked on in some time.  The use of this example is now
     self contained to this document.

  2. References to UTF8 have been changed to UTF-8.

  3. The document implied, but did not explicitely state, that concrete
     service types inherit all attributes defined by abstract service
     type templates.  This has been clarified in draft 14.

  4. The bibliography has been cleaned up.
 
There have been no changes to the content of the document so neither WG
nor IETF last call are required before submitting this document to the
IESG for balloting.

Please let me know if you have any concerns about any of this.

Erik Guttman
SVRLOC WG Chair

---

From: Ira McDonald <[email-masked]>
Date: Thu, 4 Feb 99 10:19:53 EST

Hi Erik,

All these clarifications seem reasonable and clear.  Thanks
for the good summary.  I approve of all the clarifications.

Cheers,
- Ira McDonald (outside consultant at Xerox)
  High North Inc
  716-461-5667

---

From: "Todd Rupper" <[email-masked]>
Date: Thu, 04 Feb 1999 11:17:37 -0700

Erik,

One last concern.  On page 23, Section 8.5 Directory Agent Advertisement.  It states that "the error code is set to 0 unless the DAADVERT is begin returned due to a SrvRqst without the MCAST request flag set."

We will unicast a directory agent service request when we discover a DA via static config or DHCP.  This is the only way we know of determining if the  DA really exists or is alive.  It's a ping type mechanism.  I have found that this is very important.  The above statement implies that a unicast send is not valid.  

Todd.

>>> Erik Guttman <[email-masked]> 02/04/99 04:30AM >>>

 

Erik Guttman
SVRLOC WG Chair