Subject: TECH-OMISSION (-protocol): Partial IPs with CIDRs allowed?

From: Max Kanat-Alexander <[email-masked]>
Date: Tue, 07 Sep 2004 17:47:22 -0700

Section 4. Mechanism Definitions:

	"If a CIDR-length is specified, then only the specified number of
high-order bits of <ip> and the IP address are compared for equality."

	Caller ID provided a similar description of how to read IPs from an
element, and a customer and I were uncertain about one thing:

	Is it OK to write 1.2.3/24, or MUST I write 1.2.3.0/24? It would be
easier for implementation if the second form was required.

	My apologies if this has already been mentioned or discussed elsewhere.

	-Max
-- 
Maxwell Kanat-Alexander
2nd Level Tech Support Engineer, USA
Kerio Technologies, Inc.

---

From: Meng Weng Wong <[email-masked]>
Date: Tue, 7 Sep 2004 22:02:17 -0400

On Tue, Sep 07, 2004 at 05:47:22PM -0700, Max Kanat-Alexander wrote:
| 
| 	Is it OK to write 1.2.3/24, or MUST I write 1.2.3.0/24? It would be
| easier for implementation if the second form was required.
| 
| 	My apologies if this has already been mentioned or discussed elsewhere.
| 

I have the feeling that people are going to write the first
form, so we might as well require implementations to support
it.  As long as it's not ambiguous, lazy is okay.

Similarly "ipv4" and "ipv6" being synonyms for "ip4" and
"ip6", and "a:1.2.3.4" being interpreted as "ip4:1.2.3.4".
That seems to happen rather often.

---

From: Max Kanat-Alexander <[email-masked]>
Date: Tue, 07 Sep 2004 19:47:36 -0700

> it.  As long as it's not ambiguous, lazy is okay.

	OK, great. Yeah, we modified our Caller ID implementation to accept it
because webtv was doing it.

	I'll just be glad to have it stated that we do have to read IPs written
that way.

> That seems to happen rather often.

	Yeah, "liberal in what you accept" certainly doesn't do any harm,
there. :-)

	-Max

---

From: wayne <[email-masked]>
Date: Tue, 07 Sep 2004 23:09:01 -0500

> That seems to happen rather often.

<rant>

Over the last year or so, Meng and I have gone around and around on
this issue.  In general, Meng appears to be willing to let
implementations do whatever they want to try to fix up errors in SPF
records.  I, on the other hand, think that it is very important to
have a consistent interpretation of an SPF record between
implementations.

I strongly believe that implementations MUST detect all syntax errors
and return PermError in such cases.

If we want to support these common deviations from the spec, I think
we should put them into the spec and have all implementations support
them.

This is email we are talking about, not some formatting of a web
page.  I think it would be very bad to require ever implementation of
SPF/SenderID to know about weird voodoo magic that is needed to work
reliably the way web browers are required to know.  I think SPF
records should be handled much more like a Java virtual machine, where
all errors are (in theory) detected and (in theory) all results are
the same everywhere.

I have submitted patches to require strict syntax checking.  Neither
Meng nor Mark appear to be concerned about this issue and they control
the spec.  I've pretty much given up on this issue.  I suspect that
one day, someone will write up a big compatibility guide so that
publishers know what kind of stuff they can get away with, and
implementers will know what kind of bogus stuff will get thrown their
way that everyone else "does the right thing" with.

</rant>

For those who want to review the subject, here are a couple of posts
to the SPF-discuss mailing list:

http://archives.listbox.com/[email-masked]/200403/0424.html
http://archives.listbox.com/[email-masked]/200403/0428.html
http://archives.listbox.com/[email-masked]/200403/0441.html

-wayne

---

From: Max Kanat-Alexander <[email-masked]>
Date: Tue, 07 Sep 2004 22:09:35 -0700

> we should put them into the spec and have all implementations support

	I agree. The common deviations that Meng and I just discussed should be
specified as being allowed.

	-Max
-- 
Maxwell Kanat-Alexander
2nd Level Tech Support Engineer, USA
Kerio Technologies, Inc.
2041 Mission College Blvd. Suite 100
Santa Clara, CA 95054
Phone: (408) 496-4500 x23
Fax: (408) 496-6902
Web: http://www.kerio.com/support.html

---

From: Margaret Olson <[email-masked]>
Date: Wed, 8 Sep 2004 06:25:32 -0400

> <rant>
[snip]
> we should put them into the spec and have all implementations support
I can not agree more. A spec that has a large number of common 
deviations is not a spec. It's a series of suggestions, and you wind up 
with a myriad of implementations doing all kinds of things, and it 
becomes impossible for a publisher to know if the record is really 
right or not.  A spec with many deviations tends to encourage more 
deviations and "improvements". Consistency is a BIG part of keeping it 
simple.

I don't mind if the syntax is extended to include the variants listed 
above, but it needs to be in the spec.

This reasoning applies to the MUST and SHOULD debate about TXT and the 
new SPF RR as well. If it's allowed, say so. If it's not, it's an 
error. And don't spec things that many implementations can't comply 
with!

> reliably the way web browers are required to know.

Well, it's pretty bad on a web page too. The browser mess wastes 
buckets of development time in every organization all over the world. 
Let's not do that.

Margaret.