Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-02.txt

[Scott Kitterman <[e-mail]>]

On Tuesday, July 03, 2012 01:47:18 PM Alessandro Vesely wrote:
> On Tue 03/Jul/2012 01:53:36 +0200 Scott Kitterman wrote:
> > There seemed to be a general view that I had too much about Type SPF still
> > in the draft, so I've taken another whack at it and reduced it further.
> IMHO, that whack was a little bit too procrustean.  The experiment I-D
> explains a good deal of background info, but does not anticipate what
> resolution is made at the protocol level --senders may publish,
> verifier should not query, IIRC.

Please suggest text that you think would be reasonable.  I think my latest 
attempt covers reasonably what implementors should do.  If there is a gap in 
the why we decided that, I think it should probably be a sentence or two in 
sections 1.1 or 1.2.  What are you thinking needs to be added?

> > In my last draft, I left the Type 99/SPF discussion in the IANA
> > considerations section.  I did that on purpose because even though RFC
> > 4408 will be obsolete after 4408bis is published, we still want an active
> > definition for the assignment (to preserve it's use for SPF for the near
> > future since people won't immediately remove Type SPF records, to
> > document that the code point has been used and it not available,
> 
> +1, that's needed.
> 
> > and to make it easy for a future effort to pick up it's use again
> > if it were ever warranted).
> 
> I'd keep neutral on this.  We can divine neither what an incompatible
> change will want to do, nor how easy or difficult that will be.

There are a number of people who believe that there is a need for a future SPF 
"Version 3" that will not have backward compatibility requirements.  My view 
is that I'm not even going to think about it until after 4408bis is done.  If 
we postulate such an incompatible update were to be desirable, then it should 
use type SPF from the beginning.  There's nothing in the 4408bis drafts about 
potential future usage and I don't think there should be, so we don't need to 
divine anything.

> > I do think the body of the document needs to at least mention it for
> > clarity, but it should be more minimal than my original attempt.  I'm
> > attaching an rfcdiff from the 02 draft to my current attempt.  You'll see
> > I moved some of the information about type SPF to IANA considerations
> > (not sure if I can do that) and seriously slimmed down the discussion in
> > the body of the draft.
> I'd keep something of the last paragraph of Section 3.1.1 (v -02).  At
> least:
> 
>    An SPF-compliant domain name MUST have an SPF record of type TXT.

The first sentence of 3.1.1 is now (in my local copy/the diff I mailed):

   SPF records MUST be published as type TXT [RFC1035].

I think adding your proposed sentence back is redundant.  What do you think it 
would add?

> Since the subsection's title is "DNS Resource Record Types", we might
> choose to concentrate the information on the move there, referring to
> Appendix A of [draft-ietf-spfbis-experiment] _for background_.
> Otherwise, we might drop the last word of the title.

I fixed the title.

> For the IANA considerations section, I'd limit to:
> 
>   IANA is requested to add an annotation to the SPF RRTYPE saying
>   "(OBSOLETE - use TXT)" in the DNS Parameters registry.
>
> (to be changed to "has added" upon publication.)

I've added this, but not removed any of the existing text.

> I wouldn't insist on "Version 1" more than necessary, since that is
> the same as 4408.

It's a bit difficult to know what to do here.  Personally, I think the chances 
that a non-compatible future SPF revision will get significant deployment are 
small.  Other people feel differently and so I think it is a good idea to be 
explicit that the obsoleteness is relative to version 1 here.

> US-ASCII should perhaps be changed to UTF-8 if we are going to allow
> that in mailbox names.  See
> http://www.ietf.org/mail-archive/web/spfbis/current/msg01719.html

For now, I think it should stay US-ASCII.  When we discuss IDN, then we can 
decide about that change.  We'll need to look very carefully at the backward 
compatibility implications of such a change (I absolutely guarantee you not 
all current SPF libraries are UTF-8 clean).

Scott K