Network Working Group                                         C. Malamud
Internet-Draft                                       Memory Palace Press
Expires: August 8, 2005                                 February 4, 2005


            Attaching Meaning to Solicitation Class Keywords
                draft-malamud-keyword-discovery-01.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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.

   This Internet-Draft will expire on August 8, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This Internet-Draft proposes a mechanism for finding information
   about solicitation class keywords which are defined in RFC 3865, the
   No Soliciting SMTP Service Extension.  The mechanism uses a DNS NAPTR
   Resource Record to associate a URI with a solicitation class keyword.

Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",



Malamud                  Expires August 8, 2005                 [Page 1]


draft-malamud-keyword-discovery    No-Solicit Discovery    February 2005


   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, [RFC2119].

Table of Contents

   1.  Solicitation Class Keywords  . . . . . . . . . . . . . . . . .  3
   2.  The No-Solicit NAPTR Application . . . . . . . . . . . . . . .  3
   3.  Example(Non-Normative) . . . . . . . . . . . . . . . . . . . .  4
   4.  DDDS Application Specification . . . . . . . . . . . . . . . .  7
   5.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     8.1   Normative References . . . . . . . . . . . . . . . . . . .  8
     8.2   Informative References . . . . . . . . . . . . . . . . . .  9
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  9
   A.  Intended Status and Discussion (TO BE REMOVED UPON
       PUBLICATION) . . . . . . . . . . . . . . . . . . . . . . . . .  9
   B.  Changes From Previous Draft (TO BE REMOVED UPON
       PUBLICATION) . . . . . . . . . . . . . . . . . . . . . . . . .  9
       Intellectual Property and Copyright Statements . . . . . . . . 11






























Malamud                  Expires August 8, 2005                 [Page 2]


draft-malamud-keyword-discovery    No-Solicit Discovery    February 2005


1.  Solicitation Class Keywords

   [RFC3865] defines the concept of a "solicitation class keyword",
   which is an arbitrary string or label which can be associated with an
   electronic mail message and transported by the ESMTP mail service as
   defined in [RFC2821] and related documents.  Solicitation class
   keywords are formatted like domain names, but reversed.  For example,
   the registrant of "example.com" might specify a particular
   solicitation class keyword such as "com.example.adv" that could be
   inserted in a "No-Solicit:" header or in a trace field.  [RFC3865]
   explicitly placed discovery of the meaning of a solicitation class
   keywords as outside of the scope of the basic ESMTP service
   extension.

   If that standard becomes widely deployed, a  mail message might
   contain a large number of solicitation class keywords.  The
   "No-Solicit:" header has keywords inserted by the sender of the
   message, which might include the sender's own keywords, as well as
   those mandated by regulatory authorities or recommended by voluntary
   industry associations.  Likewise, the "received:" trace fields might
   contain a large number of keywords produced by message transfer
   agents (MTAs), filtering software, forwarding software in the message
   user agent (MUA), or any other system in the chain of delivery.

   As the number of keywords employed grows, it will be important to
   find a method for discovering the meaning behind the various labels.
   This draft specifies such a mechanism using the DNS NAPTR Resource
   Record, which is defined in [RFC3403].  An explicit design goal is to
   keep the system as simple as possible.  Approaches such as defining
   an XML-based structure that would contain keyword meta-data or other
   approaches that define the format of the explanation were ruled out.
   Instead, the goal is to associate a solicitation class keyword with a
   URI, which in turn contains an explanation of the keyword.

2.  The No-Solicit NAPTR Application

   The DDDS framework of [RFC3401] and related documents provides a
   powerful set of mechanisms that can yield sophisticated applications
   such as ENUM.[RFC3761] There is a simplification of the DDDS
   framework called the Straightforward-NAPTR (S-NAPTR) application
   [RFC3958].  Unfortunately, S-NAPTR does not permit the use of the "U"
   flag for terminal lookups and does not support the regular expression
   field of the NAPTR RR.  Since a replacement field in a NAPTR record
   must contain only a domain name, and our goal is to find a URI, this
   draft does not use the S-NAPTR mechanism.

   This draft uses the NAPTR RR to do a single lookup from solicitation
   class keyword to URI.  The fields of the NAPTR RR are used as



Malamud                  Expires August 8, 2005                 [Page 3]


draft-malamud-keyword-discovery    No-Solicit Discovery    February 2005


   follows:
   o  The "ORDER" and "PREFERENCE" fields are to be processed as
      specified in [RFC3403]: if multiple records are returned, the
      one(s) with the lowest "ORDER" value that have a matching
      "SERVICE" field MUST be used.  Of those with the lowest ORDER
      value, those with the lowest "PREFERENCE" SHOULD be used.
   o  The "FLAGS" field MUST contain the character "U".
   o  The "SERVICES" field MUST contain only the string "no-solicit".
   o  The "REGEXP" field MUST contain a valid URI as further specified
      in this section.
   o  The "REPLACEMENT" field MUST be empty.

   The "REGEXP" field is defined in [RFC3402] as consisting of a
   "delim-character", a POSIX Extended Regular Expression, another
   "delim-character", a replacement value, and a final
   "delim-character".  For this application the following rules apply:
   o  The "delim-character" MAY be any valid character as defined in
      section 3.2 of [RFC3402].
   o  The extended regular expression MUST be empty.
   o  The replacement value MUST contain a valid URI as specified in
      [RFC2396].
   o  The replacement value SHOULD contain a URI limited to the "ftp",
      "http", and "https" schemes as specified in [RFC2396] and
      [RFC2660].
   o  The document that is retrieved at the URI SHOULD conform to
      [W3C.REC-html401-19991224], including the Accessibility Guidelines
      contained therein.

3.  Example(Non-Normative)

   A set of NAPTR records have been installed in the "simians.net"
   subdomain and can be retrieved using "dig" or other DNS utilities:



















Malamud                  Expires August 8, 2005                 [Page 4]


draft-malamud-keyword-discovery    No-Solicit Discovery    February 2005


   [carl@example.com]% dig 2795.simians.net naptr

   ; <<>> DiG 9.2.3 <<>> 2795.simians.net naptr
   ;; global options:  printcmd
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY,
      status: NOERROR, id: 43494
   ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5,
      AUTHORITY: 2, ADDITIONAL: 1

   ;; QUESTION SECTION:
   ;2795.simians.net.              IN      NAPTR

   ;; ANSWER SECTION:
   2795.simians.net.       86400   IN
        NAPTR   1 1 "U" "iam+invalid"
        "!!http://invalid.simians.net/contact.html!" .
   2795.simians.net.       86400   IN
        NAPTR   1 1 "U" "sip+invalid"
        "!!http://invalid.simians.net/contact.html!" .
   2795.simians.net.       86400   IN
        NAPTR   1 2 "U" "no-solicit"
        "!!http://infinite.simians.net/keywordinfo.html!" .
   2795.simians.net.       86400   IN
        NAPTR   2 1 "U" "no-solicit"
        "!!http://infinite.simians.net/keywordinfo.html!" .
   2795.simians.net.       86400   IN
        NAPTR   1 1 "U" "no-solicit"
        "!!http://infinite.simians.net/keywordinfo.html!" .

   A simple utility written in PERL accepts a lookup key and returns a
   URL using the specifications in this document:



















Malamud                  Expires August 8, 2005                 [Page 5]


draft-malamud-keyword-discovery    No-Solicit Discovery    February 2005


   #!/usr/bin/perl
   # This program accepts a solicitation class keyword and
   # returns a URL on success.  It dies quietly on failure.
   use strict;

   # http://www.net-dns.org/
   use Net::DNS;

   # reverse the label to create a domain name
   my $target = join( ".", reverse( split( /\./, $ARGV[0]) ) );

   # create a resolver
   my $res = Net::DNS::Resolver->new;

   # find all naptr records
   my $query = $res->query( "$target", "NAPTR" ) || exit ;

   # Do your DNSSEC checks here, throw away all invalid RRs

   # get the answers, strip out non-matching services,
   # sort by order, preference
   my @rr =
     sort {
       # sort records numerically by order, preference
       $a->order <=> $b->order
         || $a->preference <=> $b->preference
     }
     grep { $_->service =~ /no-solicit/ } $query->answer;

   # print the first qualifying record, strip out the
   # regexp markers
   my $op = substr( my $answer = $rr[0]->regexp , 0, 1 )
      || exit ;
   print split ( $op, $answer ) ; exit ;

   Running the code gives the following results:















Malamud                  Expires August 8, 2005                 [Page 6]


draft-malamud-keyword-discovery    No-Solicit Discovery    February 2005


   [carl@example.com]% lynx -source `./discover.pl net.simians.2795`
   <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
   <html>
     <head>
       <title>About Our Solicitation Class Keyword</title>
     </head>
     <body>
       <center>
         <a href="monkey.mp3">
           <img alt="bouncy monkey logo"
                src="images/monkey_fpo.gif" border="0" />
           <br />
          </a>
          <br />
          About net.simians.2795:<br />
          It has been determined that the content of this
          mail message<br />
          conforms to the spirit of RFC 2795.
          Congratulations?
       </center>
     </body>
   </html>


4.  DDDS Application Specification

   The following definitions apply to this application:
   o  Application Unique String: The application unique string is a
      Solicitation Class Keyword as defined in [RFC3865].
   o  First Well Known Rule: The Solicitation Class Keyword is reversed
      in order to produce a valid domain name.  For example,
      "com.example.adv" would become "adv.example.com".
   o  Valid Databases: The DNS _is_ the database.
   o  Expected Output: A URI.
   o  The "SERVICE" field MUST contain the string "no-solicit", the
      "FLAGS" field MUST contain the string "U", the "REPLACEMENT" field
      MUST be empty, and the "REGEXP" field MUST be formatted as
      specified in Section 2.

   Wildcards are appropriate for this application, allowing multiple
   solicitation class keywords that share a common prefix to all point
   to the same URI.

5.  Acknowledgments

   The author would like to thank the following for their helpful
   suggestions and reviews of this draft: Leslie Daigle, Arnt
   Gulbrandsen, Michael Mealling, and Ted Hardie.



Malamud                  Expires August 8, 2005                 [Page 7]


draft-malamud-keyword-discovery    No-Solicit Discovery    February 2005


6.  Security Considerations

   Use of a URI with the "https:" scheme without the use of DNSSEC makes
   an unwarranted illusion of authenticity and the possibility of active
   attacks a serious concern.

7.  IANA Considerations

   There does not appear to be a central registry maintained by the IANA
   of values that might appear in a "SERVICE" field of a NAPTR resource
   record.  Thus, no direct IANA actions are required.

   However, the IANA does maintain an Application Service Tag Registry,
   which is used to support the S-NAPTR DDDS application defined in
   [RFC3958].  The IANA is advised that the "no-solicit" value for the
   SERVICE field is in use per this draft and thus should not be used in
   the Application Service Tag Registry for other applications.

8.  References

8.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2396]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998.

   [RFC2660]  Rescorla, E. and A. Schiffman, "The Secure HyperText
              Transfer Protocol", RFC 2660, August 1999.

   [RFC3402]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Two: The Algorithm", RFC 3402, October 2002.

   [RFC3403]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Three: The Domain Name System (DNS) Database",
              RFC 3403, October 2002.

   [RFC3865]  Malamud, C., "A No Soliciting Simple Mail Transfer
              Protocol (SMTP) Service Extension", RFC 3865, September
              2004.

   [RFC3958]  Daigle, L. and A. Newton, "Domain-Based Application
              Service Location Using SRV RRs and the Dynamic Delegation
              Discovery Service (DDDS)", RFC 3958, January 2005.

   [W3C.REC-html401-19991224]



Malamud                  Expires August 8, 2005                 [Page 8]


draft-malamud-keyword-discovery    No-Solicit Discovery    February 2005


              Hors, A., Jacobs, I. and D. Raggett, "HTML 4.01
              Specification", W3C REC REC-html401-19991224, December
              1999.

8.2  Informative References

   [RFC2795]  Christey, S., "The Infinite Monkey Protocol Suite (IMPS)",
              RFC 2795, April 2000.

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC3401]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part One: The Comprehensive DDDS", RFC 3401, October 2002.

   [RFC3761]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform
              Resource Identifiers (URI) Dynamic Delegation Discovery
              System (DDDS) Application (ENUM)", RFC 3761, April 2004.


Author's Address

   Carl Malamud
   Memory Palace Press
   PO Box 300
   Sixes, OR  97476
   US

   Email: carl@media.org

Appendix A.  Intended Status and Discussion (TO BE REMOVED UPON
            PUBLICATION)

   This draft is being submitted to the RFC Editor as an individual
   submission with an intended publication as a Proposed Standard.
   Discussion of this draft should take place on the
   <mailto:namedroppers@ops.ietf.org> mailing list
   (<mailto:namedroppers-request@ops.ietf.org> to subscribe).  The
   source and alternative transformations for this draft may be found at
   <http://trusted.resource.org/no-solicit/>.

Appendix B.  Changes From Previous Draft (TO BE REMOVED UPON
            PUBLICATION)

   From draft-malamud-keyword-discovery-00 to
   draft-malamud-keyword-discovery-01:
   o  Moved the example from the appendix to the main text.




Malamud                  Expires August 8, 2005                 [Page 9]


draft-malamud-keyword-discovery    No-Solicit Discovery    February 2005


   o  Added a brief note on use of wildcards to the DDDS application
      definition.
   o  Minor re-arranging to conform to RFC Editor requirements.
















































Malamud                  Expires August 8, 2005                [Page 10]


draft-malamud-keyword-discovery    No-Solicit Discovery    February 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Malamud                  Expires August 8, 2005                [Page 11]