Network Working Group C. Malamud Internet-Draft Memory Palace Press Expires: October 3, 2005 April 1, 2005 Attaching Meaning to Solicitation Class Keywords draft-malamud-keyword-discovery-04 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 October 3, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This Internet-Draft proposes a mechanism for finding a URI associated with a solicitation class keyword, which is defined in RFC 3865, the No Soliciting SMTP Service Extension. Solicitation class keywords are simple labels consisting of a domain name that has been reversed, such as "org.example.adv". These solicitation class keywords are inserted in selected header fields or used in the ESMTP service extension, including a new "No-Solicit:" header which can contain one Malamud Expires October 3, 2005 [Page 1] Internet-Draft No-Solicit Discovery April 2005 or more solicitation class keywords inserted by the sender. This draft specifies an application based on the Dynamic Delegation Discovery System (DDDS) described in RFC 3401 and related documents. An algorithm is specified to associate a solicitation class keyword with a URI which contains further information about the meaning and usage of that solicitation class keyword. For example, the registrant of the "example.org" domain could use this mechanism to create a URI which contains detailed information about the "org.example.adv" solicitation class keyword. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119]. Malamud Expires October 3, 2005 [Page 2] Internet-Draft No-Solicit Discovery April 2005 Table of Contents 1. Solicitation Class Keywords . . . . . . . . . . . . . . . . . 4 2. The No-Solicit NAPTR Application . . . . . . . . . . . . . . . 4 3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. DDDS Application Specification . . . . . . . . . . . . . . . . 8 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1 Normative References . . . . . . . . . . . . . . . . . . . 10 8.2 Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 A. Intended Status and Discussion (TO BE REMOVED UPON PUBLICATION) . . . . . . . . . . . . . . . . . . . . . . . . . 11 B. Changes From Previous Draft (TO BE REMOVED UPON PUBLICATION) . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 13 Malamud Expires October 3, 2005 [Page 3] Internet-Draft No-Solicit Discovery April 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 by the message sender or in a trace field by a message transfer agent (MTA). This solicitation class keyword is inserted by the sender of the message, who may also insert a variety of other solicitation class keywords as defined by the sender or by other parties. [RFC3865] explicitly places discovery of the meaning of a solicitation class keyword as outside of the scope of the basic ESMTP service extension. For the purposes of message transport, these solicitation class keywords are opaque. However, if RFC 3865 becomes widely used, 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, 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 solicitation class keywords. This document specifies such a mechanism, associating a solicitation class keyword with a URI which contains further information by 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 specific meta-data about the solicitation class keyword or other approaches that define the format of the explanation were ruled out. Instead, the goal is to simply 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 as specified in [RFC3761]. There is a simplification of the DDDS framework called the Straightforward-NAPTR (S-NAPTR) Malamud Expires October 3, 2005 [Page 4] Internet-Draft No-Solicit Discovery April 2005 application as specified in [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 character "." is first substituted for any instances of the character ":" and then the solicitation class keyword is reversed, using the character "." as the delimiter. This becomes the domain name lookup key. For example, "org.example:ADV" becomes "ADV.example.org". The fields of the NAPTR RR are used as 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 [HTML-4.01], including the Accessibility Guidelines contained therein. 3. Example In this example, a set of NAPTR records are added to the "example.com" zone and can be retrieved using "dig" or other DNS utilities: Malamud Expires October 3, 2005 [Page 5] Internet-Draft No-Solicit Discovery April 2005 [carl@example.com]% dig 2795.example.com naptr ; <<>> DiG 9.2.3 <<>> 2795.example.com 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.example.com. IN NAPTR ;; ANSWER SECTION: 2795.example.com. 86400 IN NAPTR 1 1 "U" "iam+invalid" "!!http://invalid.example.com/contact.html!" . 2795.example.com. 86400 IN NAPTR 1 1 "U" "sip+invalid" "!!http://invalid.example.com/contact.html!" . 2795.example.com. 86400 IN NAPTR 1 2 "U" "no-solicit" "!!http://infinite.example.com/keywordinfo.html!" . 2795.example.com. 86400 IN NAPTR 2 1 "U" "no-solicit" "!!http://infinite.example.com/keywordinfo.html!" . 2795.example.com. 86400 IN NAPTR 1 1 "U" "no-solicit" "!!http://infinite.example.com/keywordinfo.html!" . A simple utility written in PERL accepts a lookup key and returns a URI using the specifications in this document. This example is non-normative: Malamud Expires October 3, 2005 [Page 6] Internet-Draft No-Solicit Discovery April 2005 #!/usr/bin/perl # THIS SAMPLE CODE IS NOT NORMATIVE # This program accepts a solicitation class keyword and # returns a URI 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 $ARGV[0] =~ tr/:/./ ; 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 sample code gives the following results: Malamud Expires October 3, 2005 [Page 7] Internet-Draft No-Solicit Discovery April 2005 [carl@example.com]% lynx -source `./discover.pl com.example.2795`