From owner-srvloc@wicked.neato.org Sun Oct 10 12:41:32 1999 Received: from wicked.neato.org (wicked.neato.org [198.70.96.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04573 for ; Sun, 10 Oct 1999 12:41:31 -0400 (EDT) Received: from localhost (daemon@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) with SMTP id BAA28181; Sun, 10 Oct 1999 01:34:43 -0700 (PDT) Received: by wicked.neato.org (bulk_mailer v1.5); Sun, 10 Oct 1999 01:34:43 -0700 Received: (from majordom@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) id BAA28172 for srvloc-outgoing; Sun, 10 Oct 1999 01:34:33 -0700 (PDT) X-Authentication-Warning: wicked.neato.org: majordom set sender to owner-srvloc@srvloc.org using -f Received: from poptart.corp.home.net (poptart.svr.home.net [24.0.26.24]) by wicked.neato.org (8.9.1b+Sun/8.9.1) with ESMTP id BAA28168 for ; Sun, 10 Oct 1999 01:34:31 -0700 (PDT) From: craig33@s1.viag2.com Received: from zipcode.corp.home.net ([24.0.26.58]) by poptart.corp.home.net (Netscape Messaging Server 3.54) with ESMTP id AAA42 for ; Sun, 10 Oct 1999 01:34:59 -0700 Received: from mx-corp.home.net (root@mx-corp.home.net [24.0.30.25]) by zipcode.corp.home.net (8.9.3/8.9.3) with ESMTP id BAA19700 for ; Sun, 10 Oct 1999 01:34:59 -0700 (PDT) Received: from balandra.uabcs.mx (balandra.uabcs.mx [192.100.161.128]) by mx-corp.home.net (8.8.5/8.8.5-AtHome) with ESMTP id BAA11616 for ; Sun, 10 Oct 1999 01:34:57 -0700 (PDT) Received: from super (1Cust152.tnt10.alameda.ca.da.uu.net [63.10.112.152]) by balandra.uabcs.mx (8.8.5/8.8.5) with SMTP id CAA29319; Sun, 10 Oct 1999 02:45:45 -0700 (PDT) Message-Id: <199910100945.CAA29319@balandra.uabcs.mx> Subject: Message From Juliana Date: Wed, 14 Jul 1999 00:46:47 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_25B5_000070A3.00005BD2" X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-srvloc@wicked.neato.org To: undisclosed-recipients:; ------=_NextPart_000_25B5_000070A3.00005BD2 Content-Type: text/html; IS YOUR J.O.B TAKING YOU
WHERE YOU WANT TO GO?

Take 2 minutes of your time to hear about an exciting new WEALTH BUILDING
program that could net you a 6-figure income in the next 4-6 months part-time, and
enable you to leave the job thats's taking you nowhere.


Learn for Yourself

* How to create a 6-figure income within 4-6 months


* How to achieve true freedom with your own home-based business


This is not a get rich quick scheme. It takes desire and work to achieve. However,
This is more powerful and more profitable than any multi-level, direct sales, franchise
or investment opportunity in existence today.


BREAK FREE
from your past financial limitations and call today.

TOLL FREE 2 MINUTE OVERVIEW
800-575-0447













To be removed from future mailings reply to this email

IS YOUR J.O.B TAKING YOU

WHERE YOU WANT TO GO?


------=_NextPart_000_25B5_000070A3.00005BD2-- From owner-srvloc@wicked.neato.org Tue Oct 12 07:19:48 1999 Received: from wicked.neato.org (wicked.neato.org [198.70.96.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09102 for ; Tue, 12 Oct 1999 07:19:47 -0400 (EDT) Received: from localhost (daemon@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) with SMTP id DAA06889; Tue, 12 Oct 1999 03:56:22 -0700 (PDT) Received: by wicked.neato.org (bulk_mailer v1.5); Tue, 12 Oct 1999 03:56:22 -0700 Received: (from majordom@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) id DAA06880 for srvloc-outgoing; Tue, 12 Oct 1999 03:56:12 -0700 (PDT) X-Authentication-Warning: wicked.neato.org: majordom set sender to owner-srvloc@srvloc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by wicked.neato.org (8.9.1b+Sun/8.9.1) with ESMTP id DAA06876 for ; Tue, 12 Oct 1999 03:56:10 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08160; Tue, 12 Oct 1999 06:56:32 -0400 (EDT) Message-Id: <199910121056.GAA08160@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: srvloc@srvloc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-svrloc-ipv6-07.txt Date: Tue, 12 Oct 1999 06:56:31 -0400 Sender: owner-srvloc@wicked.neato.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Location Protocol Working Group of the IETF. Title : Service Location Protocol Modifications for IPv6 Author(s) : E. Guttman Filename : draft-ietf-svrloc-ipv6-07.txt Pages : 7 Date : 11-Oct-99 The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using IP based networks no longer need so much static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant of or less able to fulfill the demands of network administration. The Service Location Protocol, Version 2 is well defined for use over IPv4 networks [3]: This document defines its use over IPv6 networks. Since this protocol relies on UDP and TCP, the changes to support its use over IPv6 are minor. This document does not describe how to use SLPv1 [2] over IPv6 networks. There is at the time of this publication no implementation or deployment of SLPv1 over IPv6. It is RECOMMENDED that SLPv2 be used in general, and specifically on networks which support IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-svrloc-ipv6-07.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-svrloc-ipv6-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-svrloc-ipv6-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991011110803.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-svrloc-ipv6-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-svrloc-ipv6-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991011110803.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-srvloc@wicked.neato.org Fri Oct 15 06:53:53 1999 Received: from wicked.neato.org (wicked.neato.org [198.70.96.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03922 for ; Fri, 15 Oct 1999 06:53:52 -0400 (EDT) Received: from localhost (daemon@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) with SMTP id DAA19001; Fri, 15 Oct 1999 03:33:29 -0700 (PDT) Received: by wicked.neato.org (bulk_mailer v1.5); Fri, 15 Oct 1999 03:33:29 -0700 Received: (from majordom@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) id DAA18992 for srvloc-outgoing; Fri, 15 Oct 1999 03:33:19 -0700 (PDT) X-Authentication-Warning: wicked.neato.org: majordom set sender to owner-srvloc@srvloc.org using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by wicked.neato.org (8.9.1b+Sun/8.9.1) with ESMTP id DAA18988 for ; Fri, 15 Oct 1999 03:33:18 -0700 (PDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA03570 for ; Fri, 15 Oct 1999 03:33:40 -0700 (PDT) Received: from spider (spider [129.157.47.80]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with SMTP id MAA11568 for ; Fri, 15 Oct 1999 12:33:38 +0200 (MET DST) Date: Fri, 15 Oct 1999 12:33:38 +0200 (MET DST) From: Erik Guttman X-Sender: erikg@spider To: srvloc@srvloc.org Subject: service templates Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-srvloc@wicked.neato.org Dear SVRLOC WG members, I am in the process of closing out the WG directory. I have a list of templates which are active in the I-D directory. Some service template internet drafts have expired. If this is the case, please . Issue a new internet draft (but NOT as a SVRLOC WG draft). That is, instead of draft-ietf-svrloc issue the template as draft--svrloc. . Please send mail to the svrloc mailing list. Eventually we will have a mailing list for template registrations (as per RFC 2609: will point to a mailing list *IN THE FUTURE.* We don't have a mailing list host for service template discussion yet. Announce your service template on the srvloc@srvloc.org list for now, please. . I am the designated expert who will process the templates and make sure they are in proper form to be submitted to the IANA svrloc repository. I will encourage review of the template by people with domain expertise in the area the service template covers. The templates I currently have are: draft-guttman-svrloc-da-scheme-00.txt draft-guttman-svrloc-sa-scheme-00.txt draft-ietf-svrloc-ldap-scheme-02.txt draft-ietf-svrloc-naming-directory-scheme-01.txt draft-ietf-svrloc-nis-scheme-00.txt draft-ietf-svrloc-nrsm-scheme-00.txt draft-ietf-svrloc-printer-scheme-03.txt draft-ietf-svrloc-rawtcp-printer-scheme-01.txt draft-ietf-svrloc-wpad-template-00.txt draft-ietf-tn3270e-service-loc-03.txt If you have any others, please let me know. Erik Guttman SVRLOC WG chair From owner-srvloc@wicked.neato.org Fri Oct 15 07:14:19 1999 Received: from wicked.neato.org (wicked.neato.org [198.70.96.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04506 for ; Fri, 15 Oct 1999 07:14:19 -0400 (EDT) Received: from localhost (daemon@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) with SMTP id DAA19076; Fri, 15 Oct 1999 03:52:54 -0700 (PDT) Received: by wicked.neato.org (bulk_mailer v1.5); Fri, 15 Oct 1999 03:52:54 -0700 Received: (from majordom@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) id DAA19067 for srvloc-outgoing; Fri, 15 Oct 1999 03:52:44 -0700 (PDT) X-Authentication-Warning: wicked.neato.org: majordom set sender to owner-srvloc@srvloc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by wicked.neato.org (8.9.1b+Sun/8.9.1) with ESMTP id DAA19063 for ; Fri, 15 Oct 1999 03:52:43 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03827; Fri, 15 Oct 1999 06:53:12 -0400 (EDT) Message-Id: <199910151053.GAA03827@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: srvloc@srvloc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-svrloc-template-conversion-05.txt Date: Fri, 15 Oct 1999 06:53:12 -0400 Sender: owner-srvloc@wicked.neato.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Location Protocol Working Group of the IETF. Title : Conversion of LDAP Schemas to and from SLP Templates Author(s) : J. Kempf, R. Moats, P. St. Pierre Filename : draft-ietf-svrloc-template-conversion-05.txt Pages : 26 Date : 14-Oct-99 This document describes a procedure for mapping between SLP service advertisments and LDAP descriptions of services. The document covers two aspects of the mapping. One aspect is mapping between SLP service type templates and LDAP directory schema. Because the SLP service type template grammer is relatively simple, mapping from service type templates to LDAP types is straightforward. Mapping in the other direction is straightforward if the LDAP schema is restricted to the set of attribute types defined in RFC 2252. If arbitrary ASN.1 types occur in the schema, then the mapping is more complex and may even be impossible. The second aspect is representation of service information in an LDAP directory. The recommended representation simplifies interoperability with SLP by allowing SLP directory agents to backend into LDAP directory servers. The resulting system allows service advertisements to propagate easily between SLP and LDAP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-svrloc-template-conversion-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-svrloc-template-conversion-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-svrloc-template-conversion-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991014125301.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-svrloc-template-conversion-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-svrloc-template-conversion-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991014125301.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-srvloc@wicked.neato.org Fri Oct 15 09:55:37 1999 Received: from wicked.neato.org (wicked.neato.org [198.70.96.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11259 for ; Fri, 15 Oct 1999 09:55:36 -0400 (EDT) Received: from localhost (daemon@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) with SMTP id GAA19296; Fri, 15 Oct 1999 06:34:36 -0700 (PDT) Received: by wicked.neato.org (bulk_mailer v1.5); Fri, 15 Oct 1999 06:34:36 -0700 Received: (from majordom@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) id GAA19287 for srvloc-outgoing; Fri, 15 Oct 1999 06:34:26 -0700 (PDT) X-Authentication-Warning: wicked.neato.org: majordom set sender to owner-srvloc@srvloc.org using -f Received: from poptart.corp.home.net (poptart.svr.home.net [24.0.26.24]) by wicked.neato.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA19283 for ; Fri, 15 Oct 1999 06:34:12 -0700 (PDT) From: NetMarketing@recyclermail.com Received: from zipcode.corp.home.net ([24.0.26.58]) by poptart.corp.home.net (Netscape Messaging Server 3.54) with ESMTP id AAA52A1 for ; Fri, 15 Oct 1999 06:34:41 -0700 Received: from mx-corp.home.net (root@mx-corp.home.net [24.0.30.25]) by zipcode.corp.home.net (8.9.3/8.9.3) with ESMTP id GAA15955 for ; Fri, 15 Oct 1999 06:34:41 -0700 (PDT) Received: from kedah.gov.my (mail.kedah.gov.my [202.184.166.1]) by mx-corp.home.net (8.8.5/8.8.5-AtHome) with SMTP id GAA12610 for ; Fri, 15 Oct 1999 06:34:38 -0700 (PDT) Received: from 202.184.166.1 by kedah.gov.my (SMI-8.6/SMI-SVR4) id WAA02155; Fri, 15 Oct 1999 22:11:58 +0800 Message-Id: <199910151411.WAA02155@kedah.gov.my> To: NetMarketingSystom@excite.com Date: Fri, 15 Oct 99 05:22:06 EST Subject: Here's Your Marketing Kit Reply-To: NetRemomes@bigfoot.com Sender: owner-srvloc@wicked.neato.org "How to Promote Virtually Any Business, Product, Or Service On the Internet" Dear Friend, If you are a small business owner trying to sell your products, services, or opportunity on the internet, here's some important news! Not only can you slash your marketing costs to the bone, start receiving orders within 24 hours of all of your advertising, and keep in contact with all of your customers for pennies...but using the technology that is available right this minute, you can set your entire business on auto-pilot with machines doing 95% of the work for you. If you would love to learn how to: * Develop a 100% Risk Free Marketing System by using an almost completely forgotten secret marketing techniques developed decades ago by some of the top millionaires in direct mail! * How You Can Unconditionally Guarantee to Get Your Web Site Listed in the Top 20 of the Major Search Engines to bring your web counter to its knees! * Use Email Marketing Techniques that create leads and makes sales every single day of the week without bulk email and Without Spamming! * Write Online Ad Copy that holds people on the edge of their seats and to practically line up and beg you to take their money! * 15 different dirt cheap strategies for driving traffic to your web site! I can help you discover the most advanced ideas and dirty little tricks that guarantee you will be successful in your marketing efforts. I have written this Special Report to help you discover all of the tricks of the trade... For Your Free Copy of this Internet Marketing Secrets Special Report: Email us at: mailto:specialreport1@bigfoot.com?subject=Special-Report! Yours in Success, Michael Burgess Financial Systems *************************************************************** If you have received this message in error, please accept our apology as a responsible e-mailer, and reply with the word REMOVE in the subject line. *************************************************************** From owner-srvloc@wicked.neato.org Fri Oct 15 13:22:13 1999 Received: from wicked.neato.org (wicked.neato.org [198.70.96.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18047 for ; Fri, 15 Oct 1999 13:22:12 -0400 (EDT) Received: from localhost (daemon@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) with SMTP id KAA19853; Fri, 15 Oct 1999 10:04:36 -0700 (PDT) Received: by wicked.neato.org (bulk_mailer v1.5); Fri, 15 Oct 1999 10:04:36 -0700 Received: (from majordom@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) id KAA19844 for srvloc-outgoing; Fri, 15 Oct 1999 10:04:26 -0700 (PDT) X-Authentication-Warning: wicked.neato.org: majordom set sender to owner-srvloc@srvloc.org using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by wicked.neato.org (8.9.1b+Sun/8.9.1) with ESMTP id KAA19840 for ; Fri, 15 Oct 1999 10:04:24 -0700 (PDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA03189 for ; Fri, 15 Oct 1999 10:04:52 -0700 (PDT) Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.93.37]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id KAA21180 for ; Fri, 15 Oct 1999 10:04:51 -0700 (PDT) Received: from suntana by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA23862; Fri, 15 Oct 1999 10:04:50 -0700 Message-Id: <199910151704.KAA23862@hsmpka.eng.sun.com> Date: Fri, 15 Oct 1999 10:09:19 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Rules for Configuring SLP Scopes To: srvloc@srvloc.org Cc: James.Kempf@eng.sun.com MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Swarm_of_Insects_115_000 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Sender: owner-srvloc@wicked.neato.org --Swarm_of_Insects_115_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 7I6JH/C5lXqot5IXWswKtQ== Mikael Pahmp, Roger Holm and I came up with the attached draft describing how to configure SLP scopes. The intent of the draft is to make no changes to RFC 2608, 2610, or 2614, but rather to clarify what procedures to use when configuring an agent. The basic foundation in the draft comes from the email thread initiated by Mikael several weeks ago.The rules in the existing RFCs are ambiguous in some cases, and in others there is no guidance. Because of the SrvLoc Group's immanent demise, we've submitted the draft as an individual contribution, however, we would really like comment from people. I have volunteered to work the draft through the IETF process as a BCP or Informational contribution, whichever our area directors think is most appropriate. jak --Swarm_of_Insects_115_000 Content-Type: TEXT/plain; name="draft-kempf-scope-rules.txt"; charset=us-ascii; x-unix-mode=0664 Content-Description: draft-kempf-scope-rules.txt Content-MD5: MbYm0zgL3jx8162at3TXLQ== Service Location Working Group James Kempf INTERNET DRAFT Sun Microsystems, Inc Mikael Pahmp Axis Communications Roger Holm Novell, Inc. 22 October 1999 SLP Scope and DA Configuration draft-kempf-scope-rules-00.txt Status of This Memo This document is a submission by the Service Location Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the srvloc@srvloc.org mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract RFC 2608, RFC 2610, and RFC 2614 provide rules for configuring SLP agents with scopes and DAs from the protocol, DHCP, and API viewpoints, respectively. The rules presented in these three documents, while not in conflict, are ambiguous in certain cases. There are also cases that fall into the cracks between the three documents. For example, if the mandatory byte is off in DHCP for scopes and there are no statically configured scopes, but Kempf,Pahmp,Holm Expires 22 March 2000 [Page i] Internet Draft SLP and DA Scope Configuration 22 October 1999 there are DHCP scopes, should an agent use the DHCP scopes or not? This document specifies a sequence of steps that interoperable implementations of SLP must follow in order to obtain a clear and unambiguous scope and DA configuration. Kempf,Pahmp,Holm Expires 22 March 2000 [Page ii] Internet Draft SLP and DA Scope Configuration 22 October 1999 Contents Status of This Memo i Abstract i 1. Introduction 1 2. Terminology 1 3. Ambiguities in Scope and DA Configuration 2 3.1. Are Scopes Configured Through DA Scopes? . . . . . . . . 2 3.2. Interpretation of the Mandatory Flag . . . . . . . . . . 3 4. Scope and DA Configuration Procedure 4 5. Resolution of Specific Ambiguities 10 5.1. Are Scopes Configured Through DA Scopes? . . . . . . . . 10 5.2. Interpretation of the Mandatory Flag for DHCP Option 78 . 10 5.3. Interpretation of the Mandatory Flag for DHCP Option 79 . 10 6. Security Considerations 11 7. Full Copyright Statement 12 1. Introduction The RFCs specifying the design of the Service Location Protocol (SLP) contain descriptions about how to configure an SLP agent with scopes and DAs. These descriptions contain ambiguities and cases in which the procedure to follow in order to obtain a scope and DA configuration is inconsistent between the RFCs or missing. This document clarifies the scope and DA configuration policy for SLP, by specifying a sequence of steps that implementations of SLP must follow for an interoperable configuration procedure. 2. Terminology In this section, some terms used later in the document are defined and related to definitions in RFCs 2608 [1], 2610 [2], and 2614 [3]. [Dynamic scope discovery] Dynamic scope discovery is equivalent to user scope configuration as defined in RFC 2608. The UA performs Kempf,Pahmp,Holm Expires 22 March 2000 [Page 1] Internet Draft SLP and DA Scope Configuration 22 October 1999 active DA discovery or, if there are no DAs, active SA discovery. The scopes from the returned DAAdverts or SAAdverts are used. Dynamic DA discovery is equivalent to active DA discovery as defined in RFC 2608. The agent performs active DA discovery and uses the returned DAs. Dynamic DA discoveryDA scopesDA scopes are scope names obtained from DAAdverts returned in response to an active DA discovery, or in response to a unicast request for a DAAdvert. DHCP scopes DHCP scopes are scope names contained in DHCP Option 79. Static config or static configuration For scopes, these terms indicate the value of the net.slp.useScopes property. For DAs, the terms indicate the value of the net.slp.DAAddresses property. These properties are defined in RFC 2614. 3. Ambiguities in Scope and DA Configuration In this section, the major ambiguities pertaining to SLP scope and DA configuration are discussed. 3.1. Are Scopes Configured Through DA Scopes? The SLP protocol specification, RFC 2608 [1], states that UAs and SAs are configured with a list of scopes according to the following prioritized rules: 1. The scopes are set with DHCP. 2. The scopes are set with a static configuration file. The specification also states that the static configuration may be explicitly set to "no scope" for UAs, if the user selectable scope model (i.e. dynamic scope discovery) is desired. 3. If there is no configuration information, the agent's scope is "DEFAULT". RFC 2608 additionally states that when dynamic scope discovery is not used for UAs, if a system administrator wants SAs and UAs to use a scope other than the default, the scopes are configured, and can be configured automatically by DHCP options 78 or 79 (described in RFC 2610 [2]). Finally, RFC 2608 says this about DHCP configuration [1]: Kempf,Pahmp,Holm Expires 22 March 2000 [Page 2] Internet Draft SLP and DA Scope Configuration 22 October 1999 DHCP options 78 and 79 may be used to configure SLP. If DA locations are configured using DHCP, these SHOULD be used in preference to DAs discovered actively or passively. One or more of the scopes configured using DHCP MUST be used in requests. The entire configured MUST be used in registration and DA configuration messages. This discussion does not specify what scopes should be used if there is no scope configuration information from any source but there is DA configuration information, and the scopes of the DAs are not "DEFAULT". Should the agent get its scope information from the DAs or not? This question comes up in relation to the API specification, RFC 2614 [3], because the section on scope configuration implies that agents may, in fact, obtain scope configuration from configured DAs, rather than having the scopes configured directly. RFC 2614 has this to say about scope configuration in the API library: Scopes configured by DHCP and scopes of DAs configured by DHCP have first priority (in that order) and must be returned if they are available. The net.slp.useScopes property has second priority, and scopes discovered through the net.slp.useScopes property must be returned if this property is set and there are no scopes available from DHCP. If scopes are not available from either of these sources and the net.slp.DAAddresses property is set, then the scopes available from the configured DAs must be returned. The implication here is that scopes from DAs configured by DHCP can be used even if there are no scopes directly configured through DHCP, and similarly for statically configured scopes and DAs. 3.2. Interpretation of the Mandatory Flag The DHCP configuration option specification for SLP, RFC 2610 [2], specifies that option 78 (DA configuration) and option 79 (scope configuration) have a mandatory byte. The mandatory byte has different effect depending on whether it is in option 78 or option 79. RFC 2610 states the following for the mandatory flag in option 78: Kempf,Pahmp,Holm Expires 22 March 2000 [Page 3] Internet Draft SLP and DA Scope Configuration 22 October 1999 The 'MANDATORY' flag in the Directory Agent option may be set to either 0 or 1. If it is set to 1, the SLP User Agent or Service Agent so configured MUST NOT employ either active or passive multicast discovery of Directory Agents. This statement says nothing about what should occur if the mandatory flag is not set and static configuration information is present for DAs. Should the UA or SA use the static configuration information exclusively? Should it use the static configuration information and also perform dynamic DA discovery? Should it ignore the static configuration information and only perform DA discovery? RFC 2610 states the following for the mandatory flag in option 79: The 'MANDATORY' byte determines whether SLP Agents override their static configuration for scopes with the Scope List string provided by the option. This allows DHCP administrators to implement a policy of assigning a set of scopes to Agents for service provision. If the MANDATORY byte is 0, static configuration takes precedence over the DHCP provided scope list. If the MANDATORY byte is 1, the Scope List provided in this option MUST be used by the SLP Agent. Again, this statement is not clear about certain cases. What happens if the mandatory byte is not set, and there is a list of scopes in option 79 but there is no static configuration information? Should the agent use the DHCP-provided information, should it configure the scopes as "DEFAULT", or should it use scopes advertised by DAs discovered with dynamic DA discovery? 4. Scope and DA Configuration Procedure This section specifies how an interoperable SLP agent must configure its scope and DA lists. Scope configuration always preceeds DA configuration, unless dynamic discovery is performed. UAs derive scope information from dynamically discovered DAs (or dynamically discovered SAs if no DAs are discovered) only if the UAs have not been configured with scopes. DA and SA scopes must always be configured, in accordance with RFC 2608. When performing dynamic scope discovery, a UA first performs DA configuration to determine whether configured DAs are available and, if so, which configured DAs to use. If DAs are configured, the UA contacts the DAs using unicast and uses the returned DA scopes in the Kempf,Pahmp,Holm Expires 22 March 2000 [Page 4] Internet Draft SLP and DA Scope Configuration 22 October 1999 user scoping model of RFC 2608. If no DAs are configured, the UA performs active DA discovery and uses the returned scopes. If no DAs are discovered from active discovery, the UA performs SA discovery and uses the returned scopes. If no SAs are discovered, the UA's scope is DEFAULT. Figure 1 contains the flow chart for scope configuration and Figure 2 contains the flow chart for DA configuration. Kempf,Pahmp,Holm Expires 22 March 2000 [Page 5] Internet Draft SLP and DA Scope Configuration 22 October 1999 Figure 1 - Flow Chart for Scope Configuration ______________ YES __/DHCP Option 79"__ NO _ " available? / _ _ -------------- _ _ ^ _________ / " YES __/Mandatory"__ NO /GO " _ " byte 1?/ _ " TO/ _ --------- _ "2/ _ _ v ^ ^ / " / " /GO " /GO " " TO/ " TO/ "1/ "4/ v v ^ / " "1/ v _ _______ / DHCP " YES __/ Option "__ NO _ " has / _ _ "scopes?/ _ _ ------- _ ________ _ _Use DHCP_ _ _ scopes._ _ -------- _ _ _ _ ^ / " /GO " " TO/ "2/ v Kempf,Pahmp,Holm Expires 22 March 2000 [Page 6] Internet Draft SLP and DA Scope Configuration 22 October 1999 ^ / " "2/ v _ __________ / scope " YES __/ static "__ NO _ " config / _ _ "available?/ _ _ ---------- _ __________ _ _Use static_ _ _ config. _ _ ---------- _ _ _ ^ / " /GO " " TO/ "3/ v ^ / " "3/ v _ _________ YES __/Agent is "__ NO _ "DA or SA?/ _ _ --------- _ ____________ __________ _Use DEFAULT._ _ Perform _ ------------ _ dynamic _ _ scope _ _discovery._ ---------- Kempf,Pahmp,Holm Expires 22 March 2000 [Page 7] Internet Draft SLP and DA Scope Configuration 22 October 1999 ^ / " "4/ v _ __________ / scope " YES __/ static "__ NO _ " config / _ _ "available?/ _ _ ---------- _ __________ _ _Use static_ _ _ config. _ _ ---------- _ _ _______ / DHCP " YES __/ Option "__ NO _ " has / _ _ "scopes?/ _ _ ------- _ ________ _ _Use DHCP_ _ _ scopes._ _ -------- _ ^ / " /GO " " TO/ "3/ v Kempf,Pahmp,Holm Expires 22 March 2000 [Page 8] Internet Draft SLP and DA Scope Configuration 22 October 1999 Figure 2 - Flow chart for DA configuration ______________ YES __/DHCP Option 78"__________________________________ NO _ " available? / * * _ _ -------------- * * _ _ * * _ _________ * * _ YES __/Mandatory"___________________ NO _ _ " byte 1?/ _ * * _ _ --------- _ * * _ _ _ * * _ ______ ______ _ / DHCP " / DHCP " _ YES __/ Option "__ NO YES __/ Option "________ NO _ _ " has / _ _ " has / _ * * _ _ " DAs? / _ _ " DAs? / _ * * _ _ ------ _ _ ------ _ * * _ ________ _____________ _ _ _ _Use DHCP_ YES __/Static config"__ NO _ _ _ _ DAs. _ _ " available? / _ _ _ _ -------- _ ------------- _ _ _ * * _ _ _ _ _ * * _ __________ __________ _ _ _ _Use static_ _ Perform __ _ _ _ config. _ _ dynamic __ _ _ ---------- _ DA __ _ * * _ _discovery.__ _ _ ---------- _ _ _ _______________ _____________ _ YES __/Static config"__ NO YES __/Static config"__ NO _ _ " available? / _ _ " available? / _ _ _ ------------- _ _ ------------- _ * * _ ___________ ___________ ____________ __________ _ _Merge DHCP,_ _Merge DHCP _ _ Merge _ _ Perform __ _static, and_ _ and _ _ static and _ _ dynamic __ _dynamically_ _dynamically_ _ dynamically_ _ DA __ _discovered _ _discovered _ _ discovered _ _discovery.__ _ DAs. _ _ DAS. _ _ DAs. _ --------* *-- _ ----------- ----------- ------------ _ * * _ * * _ * * _ * * _ * * _ * * _ _-------------------------------------_ _ _ Kempf,Pahmp,Holm Expires 22 March 2000 [Page 9] Internet Draft SLP and DA Scope Configuration 22 October 1999 _____________ YES __/Static config"__ NO _ " available? / _ _ ------------- _ _ _ __________ __________ _Use static_ _ Perform _ _ config. _ _ dynamic _ ---------- _ DA _ _discovery._ ---------- 5. Resolution of Specific Ambiguities In this section, we discuss the resolution of ambiguities raised in Section 3. 5.1. Are Scopes Configured Through DA Scopes? From Figure 1, the answer is that scopes are never configured through DA scopes, unless the agent is a UA and there are no DHCP or statically configured scopes. 5.2. Interpretation of the Mandatory Flag for DHCP Option 78 From Figure 2, if the mandatory flag is not set and static configuration information is present for DAs, the agent uses the static configuration information even if DHCP information is available. This allows a system administrator or power user to override a global, DHCP supplied configuration on an individual host basis. 5.3. Interpretation of the Mandatory Flag for DHCP Option 79 From Figure 1, if the mandatory flag is not set and static configuration information is present for scopes, the agent uses the static configuration information even if DHCP information is present. As with DA configuration, this allows a system administrator or power user to override a global, DHCP supplied configuration on an individual host basis. Kempf,Pahmp,Holm Expires 22 March 2000 [Page 10] Internet Draft SLP and DA Scope Configuration 22 October 1999 6. Security Considerations Dynamic discovery of scopes and DAs are subject to the security considerations discussed in RFC 2608. Scopes and DAs discovered with DHCP are subject to the security considerations associated with DHCP. Kempf,Pahmp,Holm Expires 22 March 2000 [Page 11] Internet Draft SLP and DA Scope Configuration 22 October 1999 7. Full Copyright Statement Copyright (C) The Internet Society (1997). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Kempf,Pahmp,Holm Expires 22 March 2000 [Page 12] Internet Draft SLP and DA Scope Configuration 22 October 1999 References [1] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service Location Protocol. RFC 2608. June 1999. [2] C. Perkins and E. Guttman DHCP Options for Service Location Protocol. RFC 2610 June 1999. [3] J. Kempf and E. Guttman An API for Service Location. RFC 2614 June 1999. Authors' Addresses Questions about this memo can be directed to: James Kempf Mikael Pahmp Roger Holm Sun Microsystems Axis Communications Novell, Inc. 901 San Antonio Rd. Scheelev. 16 122 East 1700 South UMPK15-214 S-223 70 Lund Provo, UT, 84606-6194 Palo Alto, CA, 94043 Sweden USA USA +1 650 786 5890 +46 46 270 1881 +1 801 861 7000 james.kempf@sun.com mikael.pahmp@axis.com rholm@novell.com Kempf,Pahmp,Holm Expires 22 March 2000 [Page 13] --Swarm_of_Insects_115_000-- From owner-srvloc@wicked.neato.org Mon Oct 18 11:53:49 1999 Received: from wicked.neato.org (wicked.neato.org [198.70.96.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10732 for ; Mon, 18 Oct 1999 11:53:48 -0400 (EDT) Received: from localhost (daemon@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) with SMTP id IAA00778; Mon, 18 Oct 1999 08:31:02 -0700 (PDT) Received: by wicked.neato.org (bulk_mailer v1.5); Mon, 18 Oct 1999 08:31:02 -0700 Received: (from majordom@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) id IAA00769 for srvloc-outgoing; Mon, 18 Oct 1999 08:30:52 -0700 (PDT) X-Authentication-Warning: wicked.neato.org: majordom set sender to owner-srvloc@srvloc.org using -f Received: from lysithea.eastgw.xerox.com (lysithea.xerox.com [208.140.33.22]) by wicked.neato.org (8.9.1b+Sun/8.9.1) with ESMTP id IAA00765 for ; Mon, 18 Oct 1999 08:30:50 -0700 (PDT) Received: from hydra.sdsp.mc.xerox.com (hydra.sdsp.mc.xerox.com [13.231.132.34]) by lysithea.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id LAA18056; Mon, 18 Oct 1999 11:31:15 -0400 (EDT) Received: from appsrv1.sdsp.mc.xerox.com (appsrv1 [13.231.132.102]) by hydra.sdsp.mc.xerox.com (8.8.7/8.8.7) with SMTP id LAA01770; Mon, 18 Oct 1999 11:31:11 -0400 (EDT) From: Ira Mcdonald Received: by appsrv1.sdsp.mc.xerox.com (SMI-8.6/client-1.3) id LAA15746; Mon, 18 Oct 1999 11:31:11 -0400 Date: Mon, 18 Oct 1999 11:31:11 -0400 Message-Id: <199910181531.LAA15746@appsrv1.sdsp.mc.xerox.com> To: Erik.Guttman@germany.sun.com, srvloc@srvloc.org Subject: Re: service templates Sender: owner-srvloc@wicked.neato.org Hi Erik, I *think* there is probably a minor tweak to be done to 'printer:' to align it with IPP/1.1 after the dust cleared. I planned to look at this in November. I'm guessing we would want a 'backwards compatibility' rule for any that are registered with IANA? So that a newer (updated) registration wouldn't remove any former attribute or attribute value (like an enumeration)? Cheers, - Ira McDonald High North Inc From owner-srvloc@wicked.neato.org Mon Oct 18 12:02:43 1999 Received: from wicked.neato.org (wicked.neato.org [198.70.96.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11001 for ; Mon, 18 Oct 1999 12:02:42 -0400 (EDT) Received: from localhost (daemon@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) with SMTP id IAA00820; Mon, 18 Oct 1999 08:34:43 -0700 (PDT) Received: by wicked.neato.org (bulk_mailer v1.5); Mon, 18 Oct 1999 08:34:43 -0700 Received: (from majordom@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) id IAA00811 for srvloc-outgoing; Mon, 18 Oct 1999 08:34:33 -0700 (PDT) X-Authentication-Warning: wicked.neato.org: majordom set sender to owner-srvloc@srvloc.org using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by wicked.neato.org (8.9.1b+Sun/8.9.1) with ESMTP id IAA00807 for ; Mon, 18 Oct 1999 08:34:32 -0700 (PDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA25178; Mon, 18 Oct 1999 08:34:53 -0700 (PDT) Received: from vayne (remote-nl-21.Holland.Sun.COM [129.159.209.103]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with SMTP id RAA17269; Mon, 18 Oct 1999 17:34:48 +0200 (MET DST) Date: Mon, 18 Oct 1999 17:41:50 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: service templates To: Ira Mcdonald Cc: Erik.Guttman@germany.sun.com, srvloc@srvloc.org In-Reply-To: "Your message with ID" <199910181531.LAA15746@appsrv1.sdsp.mc.xerox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-srvloc@wicked.neato.org > Hi Erik, > > I *think* there is probably a minor tweak to be > done to 'printer:' to align it with IPP/1.1 after > the dust cleared. I planned to look at this > in November. I'm guessing we would want a > 'backwards compatibility' rule for any that > are registered with IANA? So that a newer > (updated) registration wouldn't remove any > former attribute or attribute value (like > an enumeration)? > > Cheers, > - Ira McDonald > High North Inc > Yes, there is backward compatibility. There are revision numbers (major and minor). Minor numbers just add, major numbers remove or change. Everything which enters the repository will be '1.0' for the first time. Erik From owner-srvloc@wicked.neato.org Tue Oct 19 04:04:12 1999 Received: from wicked.neato.org (wicked.neato.org [198.70.96.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07434 for ; Tue, 19 Oct 1999 04:04:11 -0400 (EDT) Received: from localhost (daemon@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) with SMTP id AAA03403; Tue, 19 Oct 1999 00:43:07 -0700 (PDT) Received: by wicked.neato.org (bulk_mailer v1.5); Tue, 19 Oct 1999 00:43:07 -0700 Received: (from majordom@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) id AAA03394 for srvloc-outgoing; Tue, 19 Oct 1999 00:42:57 -0700 (PDT) X-Authentication-Warning: wicked.neato.org: majordom set sender to owner-srvloc@srvloc.org using -f Received: from poptart.corp.home.net (poptart.svr.home.net [24.0.26.24]) by wicked.neato.org (8.9.1b+Sun/8.9.1) with ESMTP id AAA03390 for ; Tue, 19 Oct 1999 00:42:56 -0700 (PDT) Received: from zipcode.corp.home.net ([24.0.26.58]) by poptart.corp.home.net (Netscape Messaging Server 3.54) with ESMTP id AAA546A for ; Tue, 19 Oct 1999 00:43:23 -0700 Received: from mx-corp.home.net (root@mx-corp.home.net [24.0.30.25]) by zipcode.corp.home.net (8.9.3/8.9.3) with ESMTP id AAA27440 for ; Tue, 19 Oct 1999 00:43:23 -0700 (PDT) Received: from firewall.mercantile.co.za (firewall-user@gauntlet.mercantile.co.za [196.34.250.130]) by mx-corp.home.net (8.8.5/8.8.5-AtHome) with ESMTP id AAA05883 for ; Tue, 19 Oct 1999 00:43:02 -0700 (PDT) Received: by firewall.mercantile.co.za; id JAA04836; Tue, 19 Oct 1999 09:42:33 +0200 (SAT) Received: from unknown(168.81.222.241) by firewall.mercantile.co.za via smap (3.2) id xma004477; Tue, 19 Oct 99 09:41:39 +0200 Received: from Default (unverified) by mimesweeper.mercantile.co.za (Content Technologies SMTPRS 4.0.1) with SMTP id ; Tue, 19 Oct 1999 09:35:52 +0200 Date: Tue, 19 Oct 1999 09:35:52 +0200 To: cefa56@mail.qeliz.ac.uk From: cefa56@mail.qeliz.ac.uk (Fine Viewing!) Comments: Authenticated sender is Subject: Premium Cable TV Stations ....No Extra Charge! Message-Id: <199910192184TAA22865@Kloonwells.mercantile.co.za> Sender: owner-srvloc@wicked.neato.org This is really COOL! ENHANCE Your Cable TV! EASY to assemble plans for only $7.00 ! GET THE MOST out of your cable TV by using this SIMPLE "Fine Tuning" device! YOU WILL HAVE GREAT RESULTS! YOU will be enjoying enhanced cable viewing in just a few days! This Cable TV FINE TUNING DEVICE will make your viewing experince MUCH MORE ENJOYABLE! There is one problem though. It may accidentally receive stations that NORMALLY are offered by your cable provider for an additional fee. This would include: BOX OFFICE HIT MOVIES! PREMIUM SPORTING EVENTS! SPECIAL INTEREST PROGRAMING! And even ADULT ENTERTAINMENT! You can EASILY assemble a cable fine tuner in less than 30 minutes! You have probably seen many advertisments for similar plans......... BUT OURS are BETTER! We have compared it to all the others and have actually IMPROVED the quality and SIMPLIFIED the design !!! ** We even include PHOTOS! ** OUR PLANS ARE BETTER! We have NEW, EASY TO READ,EASY to assemble plans for only $7.00! We have seen them advertised for as much as $29.00 and you have to wait weeks to receive them! WHAT THE OTHERS SAY IS TRUE! Parts are available at "The TV HUT" or any electronics store. Trademark rights do not allow us to use a national electronics retail chains' name but there is one in your town! Call and ask them BEFORE you order! They are very familiar with these plans! You will need these easy to obtain parts : 270-235 mini box 271-1325 2.2k ohm resistor 278-212 chasis connectors RG59 coaxial cable #12 copper wire Variable capacitor They may have to special order the variable capacitor, But WHY WAIT for a special order? WE have them! WE have secured a supply of the capacitors directly from the manufacturer and We WILL include one with your plans for an ADDITIONAL $10.00 only! All you need now is the EASY TO ASSEMBLE plans to show you how to assemble this educational device in 30 MINUTES! It is LEGAL, providing of course you use these plans for EDUCATIONAL PURPOSES only. See first hand and LEARN how this SIMPLE circuitry works! If you intend to use these plans for any other purpose DO NOT ORDER them. IT'S FUN TO BUILD! We're sure you'll enjoy this project! This is a unique opportunity for hobbiest of ANY skill level to learn simple circuitry! Learn how easy "Fine Tuning" is! $ 7.00 for plans only $10.00 for variable capacitor only $17.00 for The easy to assemble plans and one variable capacitor! Please send check or money order payable to: FINE TUNING PMB #287 99 Park Ave. New York, N.Y. 10016 WE pay postage and handling! Please allow 10 days for delivery. Thank You ?| |? From owner-srvloc@wicked.neato.org Wed Oct 20 05:05:00 1999 Received: from wicked.neato.org (wicked.neato.org [198.70.96.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22055 for ; Wed, 20 Oct 1999 05:04:59 -0400 (EDT) Received: from localhost (daemon@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) with SMTP id BAA07451; Wed, 20 Oct 1999 01:48:38 -0700 (PDT) Received: by wicked.neato.org (bulk_mailer v1.5); Wed, 20 Oct 1999 01:48:38 -0700 Received: (from majordom@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) id BAA07442 for srvloc-outgoing; Wed, 20 Oct 1999 01:48:28 -0700 (PDT) X-Authentication-Warning: wicked.neato.org: majordom set sender to owner-srvloc@srvloc.org using -f Received: from poptart.corp.home.net (poptart.svr.home.net [24.0.26.24]) by wicked.neato.org (8.9.1b+Sun/8.9.1) with ESMTP id BAA07438 for ; Wed, 20 Oct 1999 01:48:26 -0700 (PDT) Received: from zipcode.corp.home.net ([24.0.26.58]) by poptart.corp.home.net (Netscape Messaging Server 3.54) with ESMTP id AAA4692; Wed, 20 Oct 1999 01:48:56 -0700 Received: from mx-corp.home.net (root@mx-corp.home.net [24.0.30.25]) by zipcode.corp.home.net (8.9.3/8.9.3) with ESMTP id BAA16497; Wed, 20 Oct 1999 01:48:55 -0700 (PDT) Received: from mail.globalynk.net (03-142.006.popsite.net [206.132.214.142]) by mx-corp.home.net (8.8.5/8.8.5-AtHome) with SMTP id BAA01241; Wed, 20 Oct 1999 01:13:50 -0700 (PDT) Message-ID: <2612.66008@mail.globalynk.net> From: "merchant@mailcity.com" Subject: Increase Your Sales Immediately! (73707) Date: Wed, 20 Oct 1999 00:36:27 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-srvloc@wicked.neato.org To: undisclosed-recipients:; Content-Transfer-Encoding: 7bit ACCEPT CREDIT CARDS OVER THE INTERNET Regardless of Your Credit Rating! Limited Time Offer ZERO SETUP FEES!! We've Helped 1000's of Businesses INCREASE PROFITS DRAMATICALLY! Give us Quick Call and PUT YOUR BUSINESS ON THE FAST TRACK! >>>>> CALL 1(800) 263-4721 <<<<< This message is sent in compliance of the new email bill section 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this email may be stopped at no cost to you. TO REMOVE CLICK ON mailto:remove1@stones.com?subject=remove ****************************************************************************** 79896 From owner-srvloc@wicked.neato.org Thu Oct 21 06:10:08 1999 Received: from wicked.neato.org (wicked.neato.org [198.70.96.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13345 for ; Thu, 21 Oct 1999 06:10:07 -0400 (EDT) Received: from localhost (daemon@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) with SMTP id CAA11590; Thu, 21 Oct 1999 02:48:56 -0700 (PDT) Received: by wicked.neato.org (bulk_mailer v1.5); Thu, 21 Oct 1999 02:48:56 -0700 Received: (from majordom@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) id CAA11580 for srvloc-outgoing; Thu, 21 Oct 1999 02:48:46 -0700 (PDT) X-Authentication-Warning: wicked.neato.org: majordom set sender to owner-srvloc@srvloc.org using -f Received: from orion.lnec.pt (orion.lnec.pt [193.136.104.22]) by wicked.neato.org (8.9.1b+Sun/8.9.1) with ESMTP id CAA11576 for ; Thu, 21 Oct 1999 02:48:40 -0700 (PDT) Received: from cygnus.lnec.pt (root@cygnus.lnec.pt [193.136.104.25]) by orion.lnec.pt (8.9.1a/8.9.1) with ESMTP id KAA22816 for ; Thu, 21 Oct 1999 10:49:01 +0100 Received: from rfelix (rfelix.lnec.pt [193.136.104.37]) by cygnus.lnec.pt (8.9.1a/8.9.1) with SMTP id KAA27770 for ; Thu, 21 Oct 1999 10:48:51 +0100 From: "RFelix" To: Subject: Service Discovery on Internet Date: Thu, 21 Oct 1999 10:51:14 +0100 Message-ID: <000101bf1ba9$d1263bb0$256888c1@rfelix.lnec.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Content-Transfer-Encoding: 7bit Sender: owner-srvloc@wicked.neato.org Content-Transfer-Encoding: 7bit Dear SVRLOC WG members, I've been studying SLP and i have the following question: Besides ADs, scopes are the main mechanism for scaling SLP. However the definition of groups of services is free and I understand that this task can be easy to do in enterprise networks. What I consider difficult is how can I define scopes in services on the Internet, in a wide-area network that doesn't have a common administration, with plenty of heterogeneous services and users? thanks in advance, Rui Pereira From owner-srvloc@wicked.neato.org Thu Oct 21 06:49:29 1999 Received: from wicked.neato.org (wicked.neato.org [198.70.96.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13523 for ; Thu, 21 Oct 1999 06:49:28 -0400 (EDT) Received: from localhost (daemon@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) with SMTP id DAA11688; Thu, 21 Oct 1999 03:33:01 -0700 (PDT) Received: by wicked.neato.org (bulk_mailer v1.5); Thu, 21 Oct 1999 03:33:01 -0700 Received: (from majordom@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) id DAA11678 for srvloc-outgoing; Thu, 21 Oct 1999 03:32:52 -0700 (PDT) X-Authentication-Warning: wicked.neato.org: majordom set sender to owner-srvloc@srvloc.org using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by wicked.neato.org (8.9.1b+Sun/8.9.1) with ESMTP id DAA11674 for ; Thu, 21 Oct 1999 03:32:50 -0700 (PDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA01618; Thu, 21 Oct 1999 03:33:15 -0700 (PDT) Received: from vayne (remote-nl-43.Holland.Sun.COM [129.159.209.125]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with SMTP id MAA18326; Thu, 21 Oct 1999 12:33:12 +0200 (MET DST) Date: Thu, 21 Oct 1999 12:40:13 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: Service Discovery on Internet To: RFelix Cc: srvloc@srvloc.org In-Reply-To: "Your message with ID" <000101bf1ba9$d1263bb0$256888c1@rfelix.lnec.pt> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-srvloc@wicked.neato.org > > Dear SVRLOC WG members, > > I've been studying SLP and i have the following question: > > Besides ADs, scopes are the main mechanism for scaling SLP. However the > definition of groups of services > is free and I understand that this task can be easy to do in enterprise > networks. What I consider difficult is how > can I define scopes in services on the Internet, in a wide-area network that > doesn't have a common administration, > with plenty of heterogeneous services and users? > > thanks in advance, > Rui Pereira > The applicability statement for SLP is that it is used in a network with common administration. SLP is not a wide-area service discovery protocol. Wide-area service discovery is an unsolved problem, but you could say there are a number of different ways that it is done, with some degree of success: - centralized directories (either formal, like a listing of all universities, from which you can access individual directories, or informal, as based on a random collection of web page links) - well known servers participating in a mesh (like IRC) - guesswork with common names (www..com) - search engines (hit or miss) None of this is particularly satisfying or answers the real need which is that there should be some mechanism for finding services that really exist (not just that have an entry in some directory) in the Internet. We held a BOF on this at IETF 41 and there are extensive notes at the following URL: http://www.bell-labs.com/mailing-lists/wasrv/ In particular, I draw your attention to a requirements draft which I coauthored, at: http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-wasrv-arch-00.txt Erik From owner-srvloc@wicked.neato.org Fri Oct 22 09:43:15 1999 Received: from wicked.neato.org (wicked.neato.org [198.70.96.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13219 for ; Fri, 22 Oct 1999 09:43:14 -0400 (EDT) Received: from localhost (daemon@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) with SMTP id GAA15941; Fri, 22 Oct 1999 06:26:27 -0700 (PDT) Received: by wicked.neato.org (bulk_mailer v1.5); Fri, 22 Oct 1999 06:26:27 -0700 Received: (from majordom@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) id GAA15930 for srvloc-outgoing; Fri, 22 Oct 1999 06:26:18 -0700 (PDT) X-Authentication-Warning: wicked.neato.org: majordom set sender to owner-srvloc@srvloc.org using -f Received: from pasiphae.eastgw.xerox.com (pasiphae.xerox.com [208.140.33.23]) by wicked.neato.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA15897 for ; Fri, 22 Oct 1999 06:25:56 -0700 (PDT) Received: from hydra.sdsp.mc.xerox.com (hydra.sdsp.mc.xerox.com [13.231.132.34]) by pasiphae.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id JAA15180; Fri, 22 Oct 1999 09:26:25 -0400 (EDT) Received: from appsrv1.sdsp.mc.xerox.com (appsrv1 [13.231.132.102]) by hydra.sdsp.mc.xerox.com (8.8.7/8.8.7) with SMTP id JAA02336; Fri, 22 Oct 1999 09:26:25 -0400 (EDT) From: Ira Mcdonald Received: by appsrv1.sdsp.mc.xerox.com (SMI-8.6/client-1.3) id JAA04339; Fri, 22 Oct 1999 09:26:24 -0400 Date: Fri, 22 Oct 1999 09:26:24 -0400 Message-Id: <199910221326.JAA04339@appsrv1.sdsp.mc.xerox.com> To: ipp@pwg.org, srvloc@srvloc.org Subject: Posted new 'printer:' template (v0.4) - 22 October 1999 Sender: owner-srvloc@wicked.neato.org Hi folks, I just sent this on to Cynthia Clark (the I-D Editor) this morning and posted it for immediate access to the PWG's server in the IPP section at: ftp://ftp.pwg.org/pub/pwg/ipp/new_SLP as: (Sorry that URL was too long for one line) This update aligns the 'printer:' template (last revised in February 1999) with the final form of IPP/1.1 Model (June 1999), Appendix E 'Generic Directory Schema'. Tom Hastings helped point out the necessary updates. Copy of my note to Cynthia follows. Cheers, - Ira McDonald High North Inc (co-editor of SLP 'printer:' template) -------------------------------------------------------------- Copies: "Internet Drafts Editor" "Pete St. Pierre" "Ira McDonald" I-D Editor, Thursday (21 October 1999) SVRLOC: Please place this document in the Internet-Drafts repository named: (October 1999) It replaces the previous: (February 1999) This draft has been updated to conform to RFC 2609, June 1999. [IPP WG - This draft has also been updated to be a conforming superset of Appendix E in the IPP/1.1 Model, (work-in-progress), June 1999, now in the RFC Editor's queue.] Thanks very much, - Ira McDonald (SVRLOC WG and IPP WG member) High North Inc imcdonal@sdsp.mc.xerox.com -------------------------------------------------------------- From owner-srvloc@wicked.neato.org Wed Oct 27 09:11:15 1999 Received: from wicked.neato.org (wicked.neato.org [198.70.96.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10411 for ; Wed, 27 Oct 1999 09:11:14 -0400 (EDT) Received: from localhost (daemon@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) with SMTP id FAA06569; Wed, 27 Oct 1999 05:49:24 -0700 (PDT) Received: by wicked.neato.org (bulk_mailer v1.5); Wed, 27 Oct 1999 05:49:23 -0700 Received: (from majordom@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) id FAA06560 for srvloc-outgoing; Wed, 27 Oct 1999 05:49:14 -0700 (PDT) X-Authentication-Warning: wicked.neato.org: majordom set sender to owner-srvloc@srvloc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by wicked.neato.org (8.9.1b+Sun/8.9.1) with ESMTP id FAA06556 for ; Wed, 27 Oct 1999 05:49:12 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09380; Wed, 27 Oct 1999 08:49:44 -0400 (EDT) Message-Id: <199910271249.IAA09380@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: srvloc@srvloc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-svrloc-printer-scheme-04.txt Date: Wed, 27 Oct 1999 08:49:43 -0400 Sender: owner-srvloc@wicked.neato.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Location Protocol Working Group of the IETF. Title : Definition of printer: URLs for use with Service Location Author(s) : P. St. Pierre, S. Isaacson, I. McDonald Filename : draft-ietf-svrloc-printer-scheme-04.txt Pages : 21 Date : 26-Oct-99 This document is a submission to the Service Location Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the srvloc@srvloc.org mailing list. This document defines the 'printer:' service type and the attributes associated with it. This 'printer:' service template is designed to be used in conjunction with the Service Location Protocol, Version 2 (SLPv2) [13], but may be used with any directory service which supports attribute/value pair registration, such as Lightweight Directory Access Protocol, Version 3 (LDAPv3, RFC 2251). The 'printer:' service type is specified as an abstract service type. It is expected that printers advertised with the 'printer:' service type may be accessible by one or more protocols. IPP [3] and LPR [2] are two examples of printing protocols that may be used to perform the actual printing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-svrloc-printer-scheme-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-svrloc-printer-scheme-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-svrloc-printer-scheme-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991026150256.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-svrloc-printer-scheme-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-svrloc-printer-scheme-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991026150256.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-srvloc@wicked.neato.org Wed Oct 27 18:20:23 1999 Received: from wicked.neato.org (wicked.neato.org [198.70.96.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13465 for ; Wed, 27 Oct 1999 18:20:22 -0400 (EDT) Received: from localhost (daemon@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) with SMTP id PAA07607; Wed, 27 Oct 1999 15:00:16 -0700 (PDT) Received: by wicked.neato.org (bulk_mailer v1.5); Wed, 27 Oct 1999 15:00:16 -0700 Received: (from majordom@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) id PAA07598 for srvloc-outgoing; Wed, 27 Oct 1999 15:00:07 -0700 (PDT) X-Authentication-Warning: wicked.neato.org: majordom set sender to owner-srvloc@srvloc.org using -f Received: from krakatoa.rapidlogic.com ([170.1.81.2]) by wicked.neato.org (8.9.1b+Sun/8.9.1) with SMTP id OAA07594 for ; Wed, 27 Oct 1999 14:59:57 -0700 (PDT) Received: from BLINKY (BLINKY [170.1.81.111]) by krakatoa.rapidlogic.com (NTMail 3.02.13) with ESMTP id xa060967 for ; Wed, 27 Oct 1999 14:56:07 -0700 From: "Joseph Campolongo" To: Subject: SPI Question Date: Wed, 27 Oct 1999 15:00:16 -0700 Message-ID: <000901bf20c6$a6a6b5a0$6f5101aa@rapidlogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-srvloc@wicked.neato.org Content-Transfer-Encoding: 7bit I'm wondering exactly what and SPI is. In RFC 2608 (SLPv2), it states that the Security Parameters Index (SPI) string identifies the key length, algorithm parameters and keying material to be used by agents to verify the signature data in the Structured Authentication Block. The SLP SPI string has the same grammar as the defined in section 6.4.1. Also, SLP SPI's deployed in a stie MUST be unique. And, The SA supplies a SLP SPI in each authentication block indicating the SLP SPI configuration required to verify the digital signature. From what I can tell, the SPI is just an arbitrary string that acts as a key value to identify which Block Structure Descriptor to use. What is confusing is that this cannot be the case, or else the SPI would just be the BSD, and wouldn't be some string. Also, the SPI is supposed to identify the "key length, algorithm parameters and keying material", although I have no idea how. Could somebody please give me a hand here? Joseph Campolongo jvc@rapidlogic.com From owner-srvloc@wicked.neato.org Thu Oct 28 07:10:22 1999 Received: from wicked.neato.org (wicked.neato.org [198.70.96.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14165 for ; Thu, 28 Oct 1999 07:10:21 -0400 (EDT) Received: from localhost (daemon@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) with SMTP id DAA11249; Thu, 28 Oct 1999 03:50:07 -0700 (PDT) Received: by wicked.neato.org (bulk_mailer v1.5); Thu, 28 Oct 1999 03:50:07 -0700 Received: (from majordom@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) id DAA11240 for srvloc-outgoing; Thu, 28 Oct 1999 03:49:58 -0700 (PDT) X-Authentication-Warning: wicked.neato.org: majordom set sender to owner-srvloc@srvloc.org using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by wicked.neato.org (8.9.1b+Sun/8.9.1) with ESMTP id DAA11236 for ; Thu, 28 Oct 1999 03:49:57 -0700 (PDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA11415; Thu, 28 Oct 1999 03:50:26 -0700 (PDT) Received: from vayne (remote-nl-23.Holland.Sun.COM [129.159.209.105]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with SMTP id MAA05508; Thu, 28 Oct 1999 12:50:23 +0200 (MET DST) Date: Thu, 28 Oct 1999 12:57:25 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: SPI Question To: Joseph Campolongo Cc: srvloc@srvloc.org, erik.guttman@germany.sun.com In-Reply-To: "Your message with ID" <000901bf20c6$a6a6b5a0$6f5101aa@rapidlogic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-srvloc@wicked.neato.org > I'm wondering exactly what and SPI is. > An SPI is a string which indicates (is an index to) a set of security parameters. Since we are deploying SLP security with a single site, we can make some interoperability assumptions. Note that these have to do with the use and naming of the parameters not with their interpretation. Since SLP defines least required to implement protocols for SLP authentication, if the device supports this, it will certainly interoperate. Let's take an example: A SA advertises a service S. It has been configured with a private key to sign its advertisements. A corresponding public key is required to verify the signature. This correspondence is signified by a SPI string. SA: Private Key BSD Associated SPI privkey-1 2 VIP-office UA: Public Key BSD Associated SPI pubkey-1 2 VIP-office The UA issues a request for a service, listing the "VIP-office" SPI. The SA uses the private key to sign the reply as it assumes that the UA has the corresponding public key. Had the UA requested a service using the SPI "Copy-Room" the SA would not have responded. This is according to the rules of SLPv2: The SA can only produce signatures for UAs which are configured with security parameters corresponding to "VIP-Office". Any other parameters which are required can also be associated with the SPI - such as intialization vectors for cryptographic algorithms or whatever. Name collisions can be managed as we are deploying them only within a single site. The reason that the BSD and the SLP SPI are separate is to explicitely list the algorithm associated with the SPI. This allows interoperation with SLPv1 and the ability for the UA to be sure the calculation is worth the effort (it won't need to start to process an authentication block with the wrong BSD.) > In RFC 2608 (SLPv2), it states that the > > Security Parameters Index (SPI) string identifies the > key length, algorithm parameters and keying material > to be used by agents to verify the signature data in > the Structured Authentication Block. The SLP SPI string > has the same grammar as the defined in > section 6.4.1. > > Also, > > SLP SPI's deployed in a stie MUST be unique. > > And, > > The SA supplies a SLP SPI in each authentication block > indicating the SLP SPI configuration required to verify > the digital signature. > > From what I can tell, the SPI is just an arbitrary string that acts as a key > value to identify which Block Structure Descriptor to use. What is > confusing is that this cannot be the case, or else the SPI would just be the > BSD, and wouldn't be some string. Also, the SPI is supposed to identify the > "key length, algorithm parameters and keying material", although I have no > idea how. It identifies it since a site administrator assigned the SPI name to a set of parameters (one set for SAs, another for UAs) and then used some key distribution technique to get the keys to the appropriate agents. > Could somebody please give me a hand here? I hope this helps. Erik From owner-srvloc@wicked.neato.org Thu Oct 28 09:39:39 1999 Received: from wicked.neato.org (wicked.neato.org [198.70.96.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20624 for ; Thu, 28 Oct 1999 09:39:38 -0400 (EDT) Received: from localhost (daemon@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) with SMTP id GAA11383; Thu, 28 Oct 1999 06:22:55 -0700 (PDT) Received: by wicked.neato.org (bulk_mailer v1.5); Thu, 28 Oct 1999 06:22:55 -0700 Received: (from majordom@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) id GAA11374 for srvloc-outgoing; Thu, 28 Oct 1999 06:22:46 -0700 (PDT) X-Authentication-Warning: wicked.neato.org: majordom set sender to owner-srvloc@srvloc.org using -f Received: from lysithea.eastgw.xerox.com (lysithea.xerox.com [208.140.33.22]) by wicked.neato.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA11370 for ; Thu, 28 Oct 1999 06:22:44 -0700 (PDT) Received: from pmdf1.cinops.xerox.com (pmdf1.cinops.xerox.com [13.250.20.175]) by lysithea.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id JAA20986 for ; Thu, 28 Oct 1999 09:23:15 -0400 (EDT) Received: from CONVERSION-DAEMON by mail.xerox.com (PMDF V5.1-12 #U3277) id <01JHNVLSHMI89KMQS2@mail.xerox.com> for srvloc@srvloc.org; Thu, 28 Oct 1999 09:23:08 EDT Received: from usaxeroxbh1.USA.XEROX.COM by mail.xerox.com (PMDF V5.1-12 #U3277) with ESMTP id <01JHNVJTS74W9N4I8N@mail.xerox.com> for srvloc@srvloc.org; Thu, 28 Oct 1999 09:23:05 -0400 (EDT) Received: by usaxeroxbh1.usa.xerox.com with Internet Mail Service (5.5.2448.0) id ; Thu, 28 Oct 1999 09:21:27 -0400 Content-return: allowed Date: Thu, 28 Oct 1999 09:21:22 -0400 From: "Filion, Joseph L" Subject: SLP API question To: srvloc@srvloc.org Message-id: <61E69E92EA1CD211B94700805F65B911012A89B2@USA0834MS1> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Sender: owner-srvloc@wicked.neato.org Content-Transfer-Encoding: 7BIT Hello, I have just recently began working with SLP, and have also just recently joined this dl, so forgive me if this has already been covered. It appears to me that the API draft (rfc2614) has an incompleteness too it that would cause a rather serious inter-operability problem. The definition for some of the configuration properties (net.slp.isBroadcastOnly for example) are read-only. According to the text, attempts to change it after the configuration file has been read are ignored. I do not, however, find a function to read in the configuration file. I see a routine in the mini-slp reference implementation, but this routine is not part of the API and so any other implementation of the libraries may do this differently. If I wrote code in my application to parse and read the configuration file, I would not be able set the read-only properties. Have I missed something here? Thanks, Joe Filion Xerox Corporation joe.filion@usa.xerox.com From owner-srvloc@wicked.neato.org Thu Oct 28 10:03:50 1999 Received: from wicked.neato.org (wicked.neato.org [198.70.96.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21782 for ; Thu, 28 Oct 1999 10:03:49 -0400 (EDT) Received: from localhost (daemon@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) with SMTP id GAA11457; Thu, 28 Oct 1999 06:43:40 -0700 (PDT) Received: by wicked.neato.org (bulk_mailer v1.5); Thu, 28 Oct 1999 06:43:40 -0700 Received: (from majordom@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) id GAA11448 for srvloc-outgoing; Thu, 28 Oct 1999 06:43:31 -0700 (PDT) X-Authentication-Warning: wicked.neato.org: majordom set sender to owner-srvloc@srvloc.org using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by wicked.neato.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA11444 for ; Thu, 28 Oct 1999 06:43:29 -0700 (PDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA03915; Thu, 28 Oct 1999 06:44:01 -0700 (PDT) Received: from vayne (remote-nl-33.Holland.Sun.COM [129.159.209.115]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with SMTP id PAA15011; Thu, 28 Oct 1999 15:43:59 +0200 (MET DST) Date: Thu, 28 Oct 1999 15:51:02 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: SLP API question To: "Filion, Joseph L" Cc: srvloc@srvloc.org In-Reply-To: "Your message with ID" <61E69E92EA1CD211B94700805F65B911012A89B2@USA0834MS1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-srvloc@wicked.neato.org Joe, The intent was that the application itself wouldn't change the properties once they were loaded. The API specifies how an application can get or set properties but leaves it to the implementation how the configuration file is loaded (when the SLP library is initialized). The properties which are read only are considered to not be ones which are 'system' rather than 'application' specific properties. Erik > Hello, > > I have just recently began working with SLP, and have also just recently > joined this dl, so forgive me if this has already been covered. > > It appears to me that the API draft (rfc2614) has an > incompleteness too it that would cause a rather serious inter-operability > problem. The definition for some of the configuration properties > (net.slp.isBroadcastOnly for example) are read-only. According to the text, > attempts to change it after the configuration file has been read are > ignored. I do not, however, find a function to read in the configuration > file. I see a routine in the mini-slp reference implementation, but this > routine is not part of the API and so any other implementation of the > libraries may do this differently. If I wrote code in my application to > parse and read the configuration file, I would not be able set the read-only > properties. Have I missed something here? > > Thanks, > Joe Filion > Xerox Corporation > joe.filion@usa.xerox.com > > > From owner-srvloc@wicked.neato.org Thu Oct 28 14:27:16 1999 Received: from wicked.neato.org (wicked.neato.org [198.70.96.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03703 for ; Thu, 28 Oct 1999 14:27:15 -0400 (EDT) Received: from localhost (daemon@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) with SMTP id KAA11946; Thu, 28 Oct 1999 10:56:53 -0700 (PDT) Received: by wicked.neato.org (bulk_mailer v1.5); Thu, 28 Oct 1999 10:56:53 -0700 Received: (from majordom@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) id KAA11937 for srvloc-outgoing; Thu, 28 Oct 1999 10:56:44 -0700 (PDT) X-Authentication-Warning: wicked.neato.org: majordom set sender to owner-srvloc@srvloc.org using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by wicked.neato.org (8.9.1b+Sun/8.9.1) with ESMTP id KAA11933 for ; Thu, 28 Oct 1999 10:56:43 -0700 (PDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA16065; Thu, 28 Oct 1999 10:57:14 -0700 (PDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.63.34]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id KAA06975; Thu, 28 Oct 1999 10:57:13 -0700 (PDT) Received: from suntana by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA05169; Thu, 28 Oct 1999 10:57:11 -0700 Message-Id: <199910281757.KAA05169@ha1mpk-mail.eng.sun.com> Date: Thu, 28 Oct 1999 11:01:57 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: SLP API question To: srvloc@srvloc.org, Joe.Filion@usa.xerox.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: LUvg49i9yjmCwydCmQYTKQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Sender: owner-srvloc@wicked.neato.org > >It appears to me that the API draft (rfc2614) has an >incompleteness too it that would cause a rather serious inter-operability >problem. The definition for some of the configuration properties >(net.slp.isBroadcastOnly for example) are read-only. According to the text, >attempts to change it after the configuration file has been read are >ignored. I do not, however, find a function to read in the configuration >file. I see a routine in the mini-slp reference implementation, but this >routine is not part of the API and so any other implementation of the >libraries may do this differently. If I wrote code in my application to >parse and read the configuration file, I would not be able set the read-only >properties. Have I missed something here? > The intent is that the file be read in by the library implementation and that the read-only properties be protected from modification by the API property modification functions (SLPSetProperty() for C). Other properties which are not read-only can be modified by this function. RFC 2614 describes how and when the properties should be read in by the library implementation. The actual mechanism for reading them is encapsluated within the library. It may be different on different operating systems (Registery in Win95 v.s. a file on VMS for example). jak From owner-srvloc@wicked.neato.org Fri Oct 29 08:32:50 1999 Received: from wicked.neato.org (wicked.neato.org [198.70.96.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21068 for ; Fri, 29 Oct 1999 08:32:50 -0400 (EDT) Received: from localhost (daemon@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) with SMTP id FAA15017; Fri, 29 Oct 1999 05:12:37 -0700 (PDT) Received: by wicked.neato.org (bulk_mailer v1.5); Fri, 29 Oct 1999 05:12:37 -0700 Received: (from majordom@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) id FAA15008 for srvloc-outgoing; Fri, 29 Oct 1999 05:12:28 -0700 (PDT) X-Authentication-Warning: wicked.neato.org: majordom set sender to owner-srvloc@srvloc.org using -f Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [192.6.10.2]) by wicked.neato.org (8.9.1b+Sun/8.9.1) with ESMTP id FAA15004 for ; Fri, 29 Oct 1999 05:12:26 -0700 (PDT) Received: from sweep.hpl.hp.com (sweep.hpl.hp.com [15.144.30.248]) by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id NAA25791; Fri, 29 Oct 1999 13:12:53 +0100 (BST) Received: from morciniecm1 (morciniec-m-1.hpl.hp.com [15.144.26.242]) by sweep.hpl.hp.com with SMTP (8.7.6/8.7.3 TIS 5.0) id NAA09593; Fri, 29 Oct 1999 13:12:50 +0100 (BST) From: "Michal Morciniec" To: "Erik Guttman" , "Joseph Campolongo" Cc: Subject: SPI in SLP integration with PKI Date: Fri, 29 Oct 1999 13:12:50 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-srvloc@wicked.neato.org Content-Transfer-Encoding: 7bit Dear Eric, Are the UA authenticated by SAa or DAs in any way? It seems to me that only SAs and DAs sign anything because the only messages containing the authenticator are SrvRply, SrvReg, SrvDereg (through serviceURL entry) and SrvAttrRply, SAAdvert and DAAdvert (through attribute list). Is it true to say that there is no provision for authentication of senders of messages SrvRqst, SrvAck, SrvTypeRqst, SrvTypeRply, AttrRqst (because they do not contain signed objects - only SPI string)? I wonder what are the implications of that for SLP with PKI key management. It looks like issuing the certificate to SAs and DAs can improve trust but if a certificate is issued to UAs it does not because UAs never uses the private key to sign anything. For example suppose SA has a certificate SA_12 and receives a SrvRqst with from UA which has a certificate UA_101. Would then the correct use of the SPI be that if UA sends SrvRqst to SA it should include SPI=SA_12 and that SPI=UA_101 would never appear in any message (because of lack of authentication mechanisms for UAs by DAs and SAs by the protocol) ? Thanks for your help > -----Original Message----- > From: owner-srvloc@wicked.neato.org > [mailto:owner-srvloc@wicked.neato.org]On Behalf Of Erik Guttman > Sent: Thursday, October 28, 1999 11:57 AM > To: Joseph Campolongo > Cc: srvloc@srvloc.org; erik.guttman@germany.sun.com > Subject: Re: SPI Question > > > > I'm wondering exactly what and SPI is. > > > > An SPI is a string which indicates (is an index to) a set of > security parameters. > > Since we are deploying SLP security with a single site, we can > make some interoperability assumptions. Note that these have > to do with the use and naming of the parameters not with their > interpretation. Since SLP defines least required to implement > protocols for SLP authentication, if the device supports this, > it will certainly interoperate. > > Let's take an example: > > A SA advertises a service S. It has been configured with > a private key to sign its advertisements. A corresponding > public key is required to verify the signature. This correspondence > is signified by a SPI string. > > SA: > > Private Key BSD Associated SPI > privkey-1 2 VIP-office > > UA: > > Public Key BSD Associated SPI > pubkey-1 2 VIP-office > > The UA issues a request for a service, listing the "VIP-office" > SPI. The SA uses the private key to sign the reply as it assumes > that the UA has the corresponding public key. > > Had the UA requested a service using the SPI "Copy-Room" the SA > would not have responded. This is according to the rules of SLPv2: > The SA can only produce signatures for UAs which are configured with > security parameters corresponding to "VIP-Office". > > Any other parameters which are required can also be associated with > the SPI - such as intialization vectors for cryptographic algorithms > or whatever. > > Name collisions can be managed as we are deploying them only within > a single site. > > The reason that the BSD and the SLP SPI are separate is to explicitely > list the algorithm associated with the SPI. This allows interoperation > with SLPv1 and the ability for the UA to be sure the calculation is worth > the effort (it won't need to start to process an authentication block with > the wrong BSD.) > > > In RFC 2608 (SLPv2), it states that the > > > > Security Parameters Index (SPI) string identifies the > > key length, algorithm parameters and keying material > > to be used by agents to verify the signature data in > > the Structured Authentication Block. The SLP SPI string > > has the same grammar as the defined in > > section 6.4.1. > > > > Also, > > > > SLP SPI's deployed in a stie MUST be unique. > > > > And, > > > > The SA supplies a SLP SPI in each authentication block > > indicating the SLP SPI configuration required to verify > > the digital signature. > > > > From what I can tell, the SPI is just an arbitrary string that > acts as a key > > value to identify which Block Structure Descriptor to use. What is > > confusing is that this cannot be the case, or else the SPI > would just be the > > BSD, and wouldn't be some string. Also, the SPI is supposed to > identify the > > "key length, algorithm parameters and keying material", > although I have no > > idea how. > > It identifies it since a site administrator assigned the SPI name to > a set of parameters (one set for SAs, another for UAs) and then used > some key distribution technique to get the keys to the appropriate > agents. > > > Could somebody please give me a hand here? > > I hope this helps. > > Erik > > From owner-srvloc@wicked.neato.org Fri Oct 29 10:19:18 1999 Received: from wicked.neato.org (wicked.neato.org [198.70.96.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26786 for ; Fri, 29 Oct 1999 10:19:17 -0400 (EDT) Received: from localhost (daemon@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) with SMTP id GAA15138; Fri, 29 Oct 1999 06:58:32 -0700 (PDT) Received: by wicked.neato.org (bulk_mailer v1.5); Fri, 29 Oct 1999 06:58:32 -0700 Received: (from majordom@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) id GAA15129 for srvloc-outgoing; Fri, 29 Oct 1999 06:58:22 -0700 (PDT) X-Authentication-Warning: wicked.neato.org: majordom set sender to owner-srvloc@srvloc.org using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by wicked.neato.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA15125 for ; Fri, 29 Oct 1999 06:58:21 -0700 (PDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA00077; Fri, 29 Oct 1999 06:58:54 -0700 (PDT) Received: from vayne (remote-nl-35.Holland.Sun.COM [129.159.209.117]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with SMTP id PAA14035; Fri, 29 Oct 1999 15:58:50 +0200 (MET DST) Date: Fri, 29 Oct 1999 16:05:54 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: SPI in SLP integration with PKI To: Michal Morciniec Cc: Erik Guttman , Joseph Campolongo , srvloc@srvloc.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-srvloc@wicked.neato.org > Dear Eric, > Are the UA authenticated by SAa or DAs in any way? It seems to me that > only SAs and DAs sign anything because the only messages containing the > authenticator are SrvRply, SrvReg, SrvDereg (through serviceURL entry) > and SrvAttrRply, SAAdvert and DAAdvert (through attribute list). That is correct. UAs only check signatures. SAs sign SrvReg, SrvDereg, SrvAttrRply and SrvRply and potentially AttrRply. DAs sign only DAAdverts. SAs may also check signatures (of DAAdverts). > Is it true to say that there is no provision for authentication of > senders of messages SrvRqst, SrvAck, SrvTypeRqst, SrvTypeRply, AttrRqst > (because they do not contain signed objects - only SPI string)? SLP contains no provisions for authentication of the UA requesting information, nor for authenticating SrvAck messages. SrvTypeRply was not deemed to be critical (that is, it won't mislead anyone about the existence or capabilities of any particular service). > I wonder what are the implications of that for SLP with PKI key > management. It looks like issuing the certificate to SAs and DAs > can improve trust but if a certificate is issued to UAs it does > not because UAs never uses the private key to sign anything. > For example suppose SA has a certificate SA_12 and receives a > SrvRqst with from UA which has a certificate UA_101. The use of certificates does help: If the UA has a certificate 'C' which was installed by the site manager, then it might be possible to have each SA and DA have a *separate* private key and to provide either their certificate 'C1' which is *signed by* C, or simply include the name 'C1' and have the UA to use some PKI to retrieve it. Either way, you have one certificate to install in the UA and can use distinct keys for each SA. Note that the current protocol could support this: The signature in the authentication block is in X.509 format which allows the inclusion of certificate, I believe. > Would then the correct use of the SPI be that if UA sends SrvRqst to > SA it should include SPI=SA_12 and that SPI=UA_101 would never appear > in any message (because of lack of authentication mechanisms for UAs > by DAs and SAs by the protocol) ? The idea is that the UA would send a request with an SPI like "Accounting Department". Say the SA had advertised >0 services signed by a DSA private key which could be verified by the use of the "Accounting Department" public key. These services are candidates to return to the UA in SrvRply or SrvAttrRply messages (if of course the SrvRqst or SrvAttrRqst matches the scope, service type, language and so on, of the service advertisement.) > Thanks for your help My pleasure. Erik From owner-srvloc@wicked.neato.org Sat Oct 30 07:56:32 1999 Received: from wicked.neato.org (wicked.neato.org [198.70.96.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23062 for ; Sat, 30 Oct 1999 07:56:31 -0400 (EDT) Received: from localhost (daemon@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) with SMTP id EAA16946; Sat, 30 Oct 1999 04:38:06 -0700 (PDT) Received: by wicked.neato.org (bulk_mailer v1.5); Sat, 30 Oct 1999 04:38:06 -0700 Received: (from majordom@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) id EAA16937 for srvloc-outgoing; Sat, 30 Oct 1999 04:37:53 -0700 (PDT) Received: from poptart.corp.home.net (poptart.svr.home.net [24.0.26.24]) by wicked.neato.org (8.9.1b+Sun/8.9.1) with ESMTP id EAA16933 for ; Sat, 30 Oct 1999 04:37:50 -0700 (PDT) From: radar11@hello.to Received: from zipcode.corp.home.net ([24.0.26.58]) by poptart.corp.home.net (Netscape Messaging Server 3.54) with ESMTP id AAA3593; Sat, 30 Oct 1999 04:38:23 -0700 Received: from mx-corp.home.net (root@mx-corp.home.net [24.0.30.25]) by zipcode.corp.home.net (8.9.3/8.9.3) with ESMTP id EAA13524; Sat, 30 Oct 1999 04:38:22 -0700 (PDT) Received: from pro-web.ie (orihah.lightrealm.com [209.95.126.4]) by mx-corp.home.net (8.8.5/8.8.5-AtHome) with ESMTP id EAA28492; Sat, 30 Oct 1999 04:38:20 -0700 (PDT) Received: from super (1Cust133.tnt4.titusville.fl.da.uu.net [63.14.8.133]) by pro-web.ie (8.8.7/8.8.5) with SMTP id MAA22939; Sat, 30 Oct 1999 12:37:53 +0100 (GMT/IST) Message-Id: <199910301137.MAA22939@pro-web.ie> X-Authentication-Warning: pro-web.ie: nigel owned process doing -bs Subject: Build Your Own Descrambler and Jammer Date: Tue, 03 Aug 1999 03:30:17 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_2BB7_00001A0B.0000739E" X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-srvloc@wicked.neato.org To: undisclosed-recipients:; ------=_NextPart_000_2BB7_00001A0B.0000739E Content-Type: text/html;


NOTE: THIS IS AN ADVERTISEMENT FOR LEGAL TV
DE-SCRAMBLER AND RADAR JAMMER IF YOU HAVE
NO INTEREST IN THIS INFORMATION
PLEASE CLICK DELETE NOW. THANK YOU--

Build your own Descrambler and Jammer

LEGAL CABLE TV DE-SCRAMBLER AND A FREE RADAR JAMMER

Want to watch Sporting Events?--Movies?--Pay-Per-View??

*This is the Famous R-D-O Shack TV Descrambler
You can assemble it from R-D-O Shack parts for about $12 or $15.

We Give You:
E-Z To follow Assembly Instructions.
E-Z To read Original Drawings.
The Famous R-D-O Shack Parts List.

PLUS SOMETHING NEW YOU MUST HAVE!

Something you can't do without.

THE UP-TO-DATE REPORT: USING A DESCRAMBLER LEGALLY



Warning: You should not build a TV Descrambler without
reading this report first.

Frequently Asked Questions--CABLE TV DESCRAMBLER

Q: Will the descrambler work on Fiber, TCI, Jarrod
and satellite systems?
A: The answer is YES. In respect to satellite,
you just get more stuff! There is one exception:
The descrambler will not work with DSS satellite.

Q: Do I need a converter box?
A: This plan works with or without a converter box.
Specific instructions are included in the plans for each!

Q: Can the cable company detect that I have the descrambler?
A: No, the signal descrambles right at the box and does
not move back through the line!

Q: Do I have to alter my existing cable system,
television or VCR?
A: The answer is no!

Q: Does this work with my remote control?
A: The answer is yes. The descrambler is
manually controlled--but very easy to use!

Q: Does this work everywhere across the country?
A: Yes, every where in the USA plus England,
Brazil, Canada and other countries!

Q: When I order, when will I get my stuff?
A: Immediately. Once your card has been aproved you
will gain immediate access to download the information.

Q: How do I order?
A: Simply call the toll free number below and place
your order 24 hours a day


BONUS: Order Now and get plans for building your
own RADAR JAMMER FREE!!!! (A $19.95 value)

These plans include easy to follow instructions and diagrams for building
your own radar jammer.

NEVER get another speeding ticket again!!!


Why pay hundreds of dollars for these devises when you can
build your own for around 12-15 dollars.



To order call 24 hours a day
1-888-736-0868


ONLY 14.95 for both the easy to follow CABLE DESCRAMBLER
plans and the RADAR JAMMER plans.








This mailing is done by an independent marketing co.
We apologize if this message has reached you in error.
Save the Planet, Save the Trees! Advertise
via E mail. No wasted paper! Delete with
one simple keystroke! Less refuse in our Dumps!
This is the new way of new millenium!




To be removed from future mailing reply to this email

------=_NextPart_000_2BB7_00001A0B.0000739E-- From owner-srvloc@wicked.neato.org Sun Oct 31 16:30:18 1999 Received: from wicked.neato.org (wicked.neato.org [198.70.96.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23732 for ; Sun, 31 Oct 1999 16:30:17 -0500 (EST) Received: from localhost (daemon@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) with SMTP id NAA20544; Sun, 31 Oct 1999 13:12:57 -0800 (PST) Received: by wicked.neato.org (bulk_mailer v1.5); Sun, 31 Oct 1999 13:12:56 -0800 Received: (from majordom@localhost) by wicked.neato.org (8.9.1b+Sun/8.9.1) id NAA20535 for srvloc-outgoing; Sun, 31 Oct 1999 13:12:47 -0800 (PST) X-Authentication-Warning: wicked.neato.org: majordom set sender to owner-srvloc@srvloc.org using -f Received: from poptart.corp.home.net (poptart.svr.home.net [24.0.26.24]) by wicked.neato.org (8.9.1b+Sun/8.9.1) with ESMTP id NAA20531 for ; Sun, 31 Oct 1999 13:12:37 -0800 (PST) Received: from zipcode.corp.home.net ([24.0.26.58]) by poptart.corp.home.net (Netscape Messaging Server 3.54) with ESMTP id AAA6DCA for ; Sun, 31 Oct 1999 13:13:13 -0800 Received: from mx-corp.home.net (root@mx-corp.home.net [24.0.30.25]) by zipcode.corp.home.net (8.9.3/8.9.3) with ESMTP id NAA14889 for ; Sun, 31 Oct 1999 13:13:12 -0800 (PST) Received: from itaa.com.tw (c130.h202052110.is.net.tw [202.52.110.130]) by mx-corp.home.net (8.8.5/8.8.5-AtHome) with ESMTP id NAA14830; Sun, 31 Oct 1999 13:13:08 -0800 (PST) Received: from brokat.co.jp [63.25.55.24] by itaa.com.tw (SMTPD32-5.01 EVAL) id A36F12E016A; Mon, 01 Nov 1999 05:19:43 PDT To: smart-homeowners@yourdomain.com Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7BIT Message-Id: Date: Sun, 31 Oct 1999 13:08:33 -0800 From: homeloansource@eqqwojlobeq.connectfree.co.uk Subject: It's a borrowers market Sender: owner-srvloc@wicked.neato.org Content-Transfer-Encoding: 7BIT You can now comparison shop thousands of loan programs through hundreds of lenders by filling in a single short form. Let lenders compete for your business Cash back refinances No Equity 2nd Trust Deeds Debt Consolidation No Income Verification The most competitive interest rates. Fill in our quick pre-qualification form and find out how much of a loan you would qualify for. Visit this website: http://3499894548/~home.loans/ or Click here for your free loan evaluation There is NEVER any fee or obligation for using our service. To be removed from the mailing list send any email to homeloansource@connectfree.co.uk The Home Loan Source 4654 E Ave S, Suite B-102 Palmdale, CA 93552 home.loans@virginnet.co.uk