Subject: proposed changes to RFC2614

From: Erik Guttman <[email-masked]>
Date: Tue, 27 Jun 2000 11:28:48 +0200 (MET DST)

"McDonald, Ira" <[email-masked]> wrote:

> I agree that the best current I-D would just be a _short_
> document of deltas.  I suggest they each be labelled, so
> that their 'status' can be easily discussed on the SLP
> mailing list.

I agree with Ira.  I include in this email a list of all the changes
I suggest become a part of the deltas draft we should produce.

---------------------------------------------------------------------------
The proposals we've seen so far on the SVRLOC list:

 - SLPAttrCallback() called only once if attributes for a URL is requested.  
   That is because there will only be one reply (there will be no need to
   aggregate multiple replies.

 - SLPFreeURL() should be SLPFree() 

 - SLPGetProperty() should change to:

   SLPError SLPGetProperty(const char* propertyName, 
                           char** propertyValue); 

   /* memory is allocated by the library but freed with SLPFree() by the 
      caller */ 

   This will improve memory management and also reduce the chance of
   concurrency problems (when multiple threads are reading and writing
   the same properties).
   
   Error codes that could be returned:  SLP_OK, 
   SLP_MEMORY_ALLOC_FAILED or SLP_NOT_IMPLEMENTED. 
   SLP_PARAMETER_BAD (if a user attempts to change a 'read-only property'
   or Get a nonexistent property.)

---------------------------------------------------------------------------
I want to suggest that we combine the update to RFC 2614 with update
of RFC 2608.

Please see draft-guttman-svrloc-slpv2bis-00.txt

I believe this would result in the following changes [section # from 
the slpv2bis draft]

 a - Introduce a new error type:  NO_LONGER_SUPPORTED.  An alternative
     is to return PARAMETER_BAD in which case old API clients can
     continue to use the same error codes.

 b - Search filters may only be a single term '(a=b)' or a sequence
     of terms conjoined together '(&(a=b)(c=d)(e=f))'.  '!', '|' and
     multiple nesting is not supported.  If search filters do not
     conform, the API SHOULD return a NO_LONGER_SUPPORTED error.
     [3.1.1]

 c - Eliminate wild cards in queries. '(x=y*y)' would return a
     NO_LONGER_SUPPORTED error from the API. [3.1.3]

 d - Eliminate attribute request by service type. Requests for incomplete
     service URLs (ie. only a service type) returns a NO_LONGER_SUPPORTED
     error from the API.  [3.2.1]
    
 e - Eliminate support for wildcards in attribute list requests.
     Return a NO_LONGER_SUPPORTED error from the API if this is 
     requested. [3.2.2]

 f - Eliminate support for wildcards in the tag list for selective
     attribute deregistration.  Return a NO_LONGER_SUPPORTED error
     from the API. [3.6.1]

 g - Eliminate the requirement to elide white space in requests and
     all string comparison (scope lists, tag lists, etc.)  This
     would simplify implementation of the API and underlying SLP
     libraries. [3.7.1]

The following are *controversial* changes suggested in the slpv2bis
draft:

 h - Search filters with other than '=' as comparison operations in 
     filter terms are no longer supported.  In this case,
     NO_LONGER_SUPPORTED is returned.  [3.1.2]

     This is controversial, since a filter like (a<=13) is useful
     for load balancing, finding the 'optimal' server, etc.

 i - An alternative to d and e above would be completely dropping
     support for AttrRqst and AttrRply messages in SLP.  These
     would be replaced by Attribute List Extensions - whose support
     would be RECOMMENDED. [3.2.3]

     See draft-guttman-svrloc-attrlist-ext-03.txt

     Deprecating AttrRqst and AttrRply messages would not effect 
     the API per se, but would require notes be added in the 
     implementation section.  If the APIs returning attributes
     are supported, then the underlying SLP implementation would
     have to send an Attribute List extension with SrvRqst messages.

 j - Eliminate support of previous responders lists.  UAs and SAs
     never add them.  SAs and DAs ignore them.  This simplifies the
     protocol since headers are now fixed length and there is more
     room for request payloads.  The complication for the API is
     that there will be more duplication to suppress.  Since PR
     lists weren't perfect - APIs had to do this anyway, so this is
     not a strong argument in favor of PR lists.  For more discussion
     see draft-guttman-svrloc-slpv2bis-00.txt, section [3.4.1]

---------------------------------------------------------------------------

Erik

---

From: Kevin Arnold <[email-masked]>
Date: Thu, 29 Jun 2000 10:24:00 -0700

This is mostly a response to your email Erik about what features are vital
to individual's company's.  Currently Apple is using a subset of the SLPv2
spec in its implementation of a UA and SA on MacOS 8.5 -> 9.x  Since NSL
(Network Services Location) has a slimmer feature set for doing service
queries across many different protocols (SLP being one of them), there
wasn't a good fit for utilizing the attribute feature of the SLP spec.

On Mac OS X, we have better support for attributes due to our starting with
the mslp reference implementation, but still don't expose these through our
NSL APIs.  So any changes to the attributes work is of little consequence to
us, except in making changes such that our UA/SA/DA implementation on Mac OS
X supports these changes.

Kevin

--Kevin Arnold
--Senior Software Engineer
--Network Services Location (NSL) Technical Lead,
--Service Location Protocol (SLP) products,
--NetFinder, and Personal NetFinder products
--Service Discovery Group,
--Apple Computer

> From: Erik Guttman <[email-masked]>
> Reply-To: Erik Guttman <[email-masked]>
> Date: Tue, 27 Jun 2000 11:28:48 +0200 (MET DST)
> To: [email-masked]
> Cc: [email-masked]
> Subject: proposed changes to RFC2614
> 
>