Subject: Re: proposed changes to RFC2614

From: James Kempf <[email-masked]>
Date: Tue, 27 Jun 2000 07:16:26 -0700

Erik,

I think DEPRECATED would be better than NO_LONGER_SUPPORTED. 

Also, I don't think we could have the API return this for stuff like
queries unless it was a return code for the protocol as well. Otherwise,
the API would have to parse queries to find out if they were OK.

		jak
>
>"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: Erik Guttman <[email-masked]>
Date: Tue, 27 Jun 2000 17:21:45 +0200 (MET DST)

> the API would have to parse queries to find out if they were OK.

Is it better to issue bogus queries to the network and rely on answers
from various remote devices or to do parameter checking?

Erik