Subject: A question about SLPv1 compatibility

From: Ganesan Rajagopal <[email-masked]>
Date: Fri, 4 Aug 2000 21:44:34 +0530 (IST)

RFC 2608 doesn't mention whether SLPv2 DAs should bind to SLPv1 DA
Discovery Multicast address (and probably do passive SLPv1 DA advertisement
too). Considering that DAs are central to backward compatibility, this
seems to be a reasonable requirement. 

I'm considering the possibility of adding SLPv1 compatibility to
OpenSLP (http://www.openslp.org). What's your opinion on this?

Ganesan

-- 
R. Ganesan ([email-masked])       | Ph: 91-80-5721856 Ext: 2149
Novell India Development Center.       | #include <std_disclaimer.h>

---

From: Erik Guttman <[email-masked]>
Date: Mon, 7 Aug 2000 12:50:52 +0200 (MET DST)

> OpenSLP (http://www.openslp.org). What's your opinion on this?

The v2 DA would only bind to the v1 address if it were backwardly 
compatible.  RFC 2608 says:

   A SLPv2 implementation SHOULD support SLPv1 [22].  This support
   includes:

    1. SLPv2 DAs are deployed, phasing out SLPv1 DAs.

    2. Unscoped SLPv1 requests are considered to be of DEFAULT scope.
       SLPv1 UAs MUST be reconfigured to have a scope if possible.

    3. There is no way for an SLPv2 DA to behave as an unscoped SLPv1
       DA. SLPv1 SAs MUST be reconfigured to have a scope if possible.

    4. SLPv2 DAs answer SLPv1 requests with SLPv1 replies and SLPv2
       requests with SLPv2 replies.

    5. SLPv2 DAs use registrations from SLPv1 and SLPv2 in the same
       way.  That is, incoming requests from agents using either version
       of the protocol will be matched against this common set of
       registered services.

    6. SLPv2 registrations which use Language Tags which are greater
       than 2 characters long will be inaccessible to SLPv1 UAs.

    7. SLPv2 DAs MUST return only service type strings in SrvTypeRply
       messages which conform to SLPv1 service type string syntax, ie.
       they MUST NOT return Service Type strings for abstract service
       types.

    8. SLPv1 SrvRqsts and AttrRqsts by Service Type do not match Service
       URLs with abstract service types.  They only match Service URLs
       with concrete service types.

Point 4 above implies that the DA joins the SLPv1 group (or else it would
not receive the SLPv1 messages).

Erik

---

From: Ganesan Rajagopal <[email-masked]>
Date: 08 Aug 2000 09:52:30 +0530

>>>>> "Erik" == Erik Guttman <[email-masked]> writes:
...
>       requests with SLPv2 replies.
...
> not receive the SLPv1 messages).

Thanks for the clarification. If the v1 UAs are statically (or using DHCP)
configured with the DA's address, the DA would still get unicast SLPv1
messages. The implication that SLPv2 DAs SHOULD respond to DA discovery on
the the SLPv1 DA Discovery multicast address isn't obvious from point 4
IMHO. Can you please make the requirement more explicit in RFC2608bis?
Thanks a lot.

Ganesan