>From owner-srvloc at srvloc.org Fri Oct 16 10:55:51 1998
Return-Path: <owner-srvloc at srvloc.org>
Received: from zombi.eso.mc.xerox.com by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1)
id AA10882; Fri, 16 Oct 98 10:55:50 EDT
Received: from alpha.xerox.com by zombi.eso.mc.xerox.com (4.1/SMI-4.1)
id AA24916; Fri, 16 Oct 98 10:47:22 EDT
Received: from wicked.neato.org ([198.70.96.252]) by alpha.xerox.com with SMTP id <52674(5)>; Fri, 16 Oct 1998 07:47:15 PDT
Received: from localhost (daemon at localhost)
by wicked.neato.org (8.8.5/8.8.5) with SMTP id HAA08250;
Fri, 16 Oct 1998 07:45:34 -0700 (PDT)
Received: by wicked.neato.org (bulk_mailer v1.5); Fri, 16 Oct 1998 07:44:14 -0700
Received: (from majordom at localhost)
by wicked.neato.org (8.8.5/8.8.5) id HAA08171
for srvloc-outgoing; Fri, 16 Oct 1998 07:44:04 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by wicked.neato.org (8.8.5/8.8.5) with SMTP id HAA08144
for <srvloc at srvloc.org>; Fri, 16 Oct 1998 07:43:58 -0700 (PDT)
Received: from Germany.Sun.COM ([129.157.168.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA25533 for <srvloc at srvloc.org>; Fri, 16 Oct 1998 07:42:30 -0700
Received: from sun-ffm by Germany.Sun.COM (SMI-8.6/SMI-SVR4-sd.fkk205)
id QAA19669; Fri, 16 Oct 1998 16:42:27 +0200
Received: from sun.com by sun-ffm (SMI-8.6/SMI-SVR4-se.fkk202)
id QAA06866; Fri, 16 Oct 1998 16:42:25 +0200
Message-Id: <36275C62.794C1F24 at sun.com>
Date: Fri, 16 Oct 1998 07:46:58 PDT
From: Erik Guttman <Erik.Guttman at Sun.COM>
Reply-To: Erik.Guttman at Sun.COM
Organization: Sun Microsystems
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4m)
Mime-Version: 1.0
To: srvloc at srvloc.org
Subject: Notice: SLP Interoperability test #5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-srvloc at srvloc.org
Status: R
I would like to find out who is planning to come to the
fifth SLP interoperability test. It is being held in
Menlo Park on Dec. 2-5.
Please send me the following information:
Name :
Company :
Email Contact:
Number coming:
SLP version to test:
If you are going to bring a SLPv2 implementation to test,
what draft version did you implement? Ours (at Sun) is
currently at draft 6 status, but will soon be draft 9
compliant. Please note that draft 9 will most likely be
the draft which becomes an RFC. We are currently in
WG last call and will go to IESG last call if nothing
comes up in the next two weeks.
Schedule:
Wednesday
Set up
Run automatic tests to get a matrix of pass/fail
Thursday
Debug failed tests
Run tests which benefit from having a protocol
analyzer and verify traces.
Friday
Debug and attempt to get a full matrix of pass
Saturday
As Friday - if we want to keep working.
Test plan:
SLPv1
(1) SAs will be preregistered with services.
SrvRqst, AttrRqst, SrvTypeRqsts will be
sent exercising Naming Authority, Scope,
Escape Characters, Wildcards, Whitespace
folding and Language selectors, as appropriate.
UAs will request the services, using
multicast/convergence.
This will exercise results coallescing and
failover to TCP on overflow.
Broadcast instead of multicast will be tested
if the Agent supports it.
(2) DAs will be turned on (before and after)
to verify appropriate advertising forwarding
behavior and DADiscovery behavior.
UAs will request the services, using
unicast. This will test all features (1)
tests.
Do the registrations time out?
Does selective reregistration and deregistration work?
(3) The following things will NOT be tested since these
features are not in SLPv2 and are not encouraged in
SLPv1.
a. Monolingual bit
b. v1 Fresh bit handling
c. different character encodings (only ASCII)
d. unscoped DAs, UAs or SAs
e. proper handling of the IANA naming authority string
f. list style SrvRqst query handling
g. 'range of multicast address' multicasting to SAs
based on the string hash of the service type
h. IPv6 operation
i. DHCP configuration
j. SLP Authentication
SLPv2
(4) SAs will be set up to register a set of predetermined
services.
UAs will issue service requests to SAs using multicast
convergence.
We will test Naming authorities, Scopes, Abstract Service
type matching, wildcards in queries, search filters,
escaped characters, white space eliding, language and
dialect matching.
Broadcast configuration will be tested, if it is supported.
(5) DAs will be set up. Does DA discovery (active & passive)
work? Does SA registration forwarding work?
Do UAs properly unicast requests to DAs when present?
This will test all the functions above.
(6) We will not be testing any optional features:
a. AttrRqst and SrvRqst
b. Options
c. Authentication
d. DA min and max lifetime attributes
e. Unicasting to SLPv2 SA works ok
Details will follow.
The basic philosophy is that each participant will come with
an SA which has a predetermined set of registrations and a UA
preprogrammed with a set of queries.
For participants with embedded products which use SLP, we will
need to know in advance so we can preprogram a set of requests
which will exercise their internal set of attributes and
service types.
That is, I will supply a set of registrations to every participant
to program their SAs with. If this is impossible, we will have to
expand our test suite to include the services which are hard-wired
(say in an embedded thin server which advertises its services, but
not arbitrary services.)
So, if you have such an SA which cannot advertise arbitrary
services, please INFORM ME RIGHT AWAY.
I will have a preliminary test plan out by Monday.
Regards,
Erik