Subject: RE: SVRLOC WG IMPORTANT: SLPv2 next step?

From: Mikael Pahmp <[email-masked]>
Date: Fri, 1 Sep 2000 10:20:25 +0200

Erik,

We support rechartering to pursue Draft Standard. We will definitely review the work and Axis want to be part of iop testing.

I will send you our opinion on the change list, soon.

/MiP

> -----Original Message-----
> From: Erik Guttman [mailto:[email-masked]]
> Sent: Wednesday, August 30, 2000 6:26 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: SVRLOC WG IMPORTANT: SLPv2 next step?
> 
> 
> 
> I posted mail 3 weeks ago requesting feedback on whether we
> should recharter the WG to move SLPv2 to draft standard.
> See http://www.srvloc.org/hypermail/0670.html
> 
> I have so far received no response.  We will not pursue 
> broadening the charter unless there is a clear positive
> response.
> 
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!!!!!!!!!
> 
>          ***Please*** respond to the following three questions:
> 
>          ONE:   Do you support rechartering the SVRLOC WG to
>                 pursue advancing SLPv2 to Draft Standard?
> 
>          TWO:   Will you actively work on reviewing drafts of 
>                 SLPv2bis as they appear?
> 
>          THREE: If Yes, what is your opinion of the change list in
>           
>   
> ftp://ftp.ietf.org/internet-drafts/draft-guttman-svrloc-slpv2b
> is-01.txt
> 
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!!!!!!!!!
> 
> We can still work on advancing SLPv2 to draft standard
> without the SVRLOC WG.  What is needed is:
> 
>  (1) Reworking RFC 2608, as per
> 
>      
> ftp://ftp.ietf.org/internet-drafts/draft-guttman-svrloc-slpv2b
is-01.txt 

 (2) Interoperability testing showing that every feature in the
     updated document is interoperable between at least two 
     independent implementations.  This has to be written up as
     a formal interoperability report.

 (3) Writing a SLPv2 MIB and submitting it for advancement to
     RFC

It will be useful to revise the SLP API (RFC 2614) for consistency
with the SLPv2 after revision of RFC 2608, so that any change to 
the protocol will be surfaced at the API.  It is not clear whether
any change will be necessary at this time (for backward compatibility).

***If*** there is sufficient interest, Jim Kempf and I will publish
an internet draft with a full update to RFC 2608.  

Separately, ***if*** there is sufficient interest, I will pursue
rechartering SVRLOC to complete this work.  

In my opinion, the current discussion on the mailing list does not 
show interest in rechartering SVRLOC, though it has been responsive 
to revising RFC 2608.

Erik

---

From: "McDonald, Ira" <[email-masked]>
Date: Wed, 20 Sep 2000 13:46:12 -0700

Hi Evan,

Right - you guys have shown good reasons for both
'|' (OR) and '!' (NOT).

While I want to support Erik's effort to simplify
SLPv2 where possible to increase adoption, I actually
prefer that SLPv2 adopts full LDAP filters, because
we're looking at filters for the IPP 'Get-Jobs'
operation and for JOBS there are lot's of cases
where '|' is useful.

I wonder about this simplification:

The '!' can only appear at the top-level (left end
of the whole search expression)?

Cheers,
- Ira McDonald, consulting architect at Xerox and Sharp
  High North Inc

-----Original Message-----
From: Evan Hughes [mailto:[email-masked]]
Sent: Wednesday, September 20, 2000 9:18 AM
Cc: [email-masked]
Subject: RE: SVRLOC WG IMPORTANT: SLPv2 next step?

On Tue, 19 Sep 2000, McDonald, Ira wrote:
...
> And I agree that '!' is of dubious value.

The following are three examples (off the top of my head) of the
usefulness of the '|' and '!' operators. 

   Consider the situation where I wish to print to one of a set of 
printers. My calendar app tells me that there are meetings going on in
rooms A, B, and C. How do I find the printers that are in nonbusy rooms?

   Consider the situation where an attribute has a set of allowed values.
The only way a UA can query for more than one of those allowed values in a
given attribute is to reissue the same request with different attribute
values in each. (ie, if we're interested in all services in which
attribute "a" is either 1, 3, 8, or 9, we have to issue four seperate
requests "(&(a=1)...)", "(&(a=3)...)", "(&(a=8)...)", and "(&(a=9)...)").

   The situation worsens when we want to find services for which a given
attribute does _not_ have a certain value. As an example, consider the
tn3270 template. The Ciphersuites attribute has nine defined values, if a
UA doesn't want one of them (say that one of them is no longer considered
secure), it must either:
  a) Request all known types individually (see prev. paragraph). 
  b) Request all servers and the attributes of those servers, and then
weed out bad responses. 

 Ten of the 17 templates listed in the repository have attributes that
have allowed values as discussed above, making this a potentially common
problem. 

e