HEY! (tongue being inserted in cheek)
Snippet from the WINZIP FAQ-
By contrast, some types of data (such as text files and picture files
in the BMP format that the Microsoft Paint program uses) (insert)<SPF or
Caller-ID records> can often be compressed by 90% or more; some types
(such as program files) are often compressed by 50%.
Let's just ZIP'm
;)
Call it.
aRRGzip
StuffItXML
ZIPSPIF
JustZIPitMardid
Regards,
Damon Sauer
-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of
Hallam-Baker,
Phillip
Sent: Monday, June 14, 2004 5:31 PM
To: 'Luis Bruno'; ietf-mxcomp(_at_)imc(_dot_)org
Subject: RE: Alternative to TXT or new RR was: Comments on
draft-ietf-marid-core-01 xml use
Why on earth are we even discussing this?
There is no difference whatsoever between a 1 byte packet and a 500 byte
packet. Either data fits in a packet or it does not. Only the number of
packets has significance when considering the impact on the network.
The hotmail policy is an outlier, there are perhaps ten ISPs of similar
scope. Nobody disputes the fact that most policies will easily fit in a
single packet - even without dns extensions.
Once read the hotmail policy will be cached for at least 24 hours.
If AOL has a thousand servers accepting mail then worst case the
difference between binary and text amounts to 1 packet a day on their
external network and maybe a couple of thousand on their internal
network. Thats less than a single powerpoint attachement.
This is control information we are discussing here. This is a tiny
fraction of the message data volume.
-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Luis
Bruno
Sent: Monday, June 14, 2004 1:20 PM
To: ietf-mxcomp(_at_)imc(_dot_)org
Subject: Re: Alternative to TXT or new RR was: Comments on
draft-ietf-marid-core-01 xml use
I'd like to hear comments on this, even flames or pointers to threads
I've missed. If this discussion is in any way out of order now, I
apologise; but do tell me to shut up in that case.
Hector Santos wrote:
I don't know why the TXT vs. RR is an issue.
From my point of view, creating a new RR type is the correct approach.
The problem lies with Microsoft's existing design, which makes the
deployment of a new RR type harder.
It's actually a moot point; my personal peeve is the representation of
the MARID information: you could place the binary information in a TXT
record, as I see it.
I'd like to have the MARID information in a binary representation; the
current design favors a textual representation, with a lot of
overhead.
I'll use hotmail.com as an example. You can see the information at:
http://www.lessspam.org/CallerIDPolicyWizard/?domain=hotmail.com
[37 records snipped]
The information occupies 537 bytes without tags.
In binary, that would be 185 bytes: 5 binary octets * 37 records.
The work on representing prefix lists has already been made
by RFC3123.
As I see it, it supports the SPF a, mx, ip4 and ip6 mechanisms. Each
of the prefixes in that list can be negated.
I think this is a better way to publish the MARID
information. If we use
TXT for that or not, it seems irrelevant. As I understand it, we could
use TXT to publish binary information: RFC1035 seems to allow
arbitrary
information in TXT RDATA.
--
Luis Bruno UTM: 29T 629481E
4511776N 576m
*****
The information transmitted is intended only for the person or entity to which
it is addressed and may contain confidential, proprietary, and/or privileged
material. Any review, retransmission, dissemination or other use of, or taking
of any action in reliance upon, this information by persons or entities other
than the intended recipient is prohibited. If you received this in error,
please contact the sender and delete the material from all computers. 113