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