Comments on: you say data, i say data…Telco Intercept Amendment Bill introduced into the Senate… http://www.lawfont.com/2007/08/29/you-say-data-i-say-datatelco-intercept-amendment-bill-introduced-into-the-senate/ an analysis of law, technology, economics, and policy Thu, 29 Dec 2011 19:59:43 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: David Cake http://www.lawfont.com/2007/08/29/you-say-data-i-say-datatelco-intercept-amendment-bill-introduced-into-the-senate/comment-page-1/#comment-55729 David Cake Thu, 30 Aug 2007 07:31:15 +0000 http://www.lawfont.com/2007/08/29/you-say-data-i-say-datatelco-intercept-amendment-bill-introduced-into-the-senate/#comment-55729 While I think the AG's department is clearly quite in the wrong on the technical issues of RFC 2822 in any case. And they are more wrong that Jules suggests - RFC 2822 clearly allows optional fields, including most of those permitted by RFC 822 (it just doesn't make the same guarantees about them). But its beside the point. The mention of email RFCs was to make the point that technical boundaries about what is content and what is communications data do not usefully correspond to the level of privacy that should be afforded that data (as they may have with paper mail and telephone communication), and so a legal definition is necessary to make it clear where this boundary should be. While I think the AG’s department is clearly quite in the wrong on the technical issues of RFC 2822 in any case. And they are more wrong that Jules suggests – RFC 2822 clearly allows optional fields, including most of those permitted by RFC 822 (it just doesn’t make the same guarantees about them).

But its beside the point. The mention of email RFCs was to make the point that technical boundaries about what is content and what is communications data do not usefully correspond to the level of privacy that should be afforded that data (as they may have with paper mail and telephone communication), and so a legal definition is necessary to make it clear where this boundary should be.

]]> By: Jules http://www.lawfont.com/2007/08/29/you-say-data-i-say-datatelco-intercept-amendment-bill-introduced-into-the-senate/comment-page-1/#comment-55728 Jules Wed, 29 Aug 2007 07:02:16 +0000 http://www.lawfont.com/2007/08/29/you-say-data-i-say-datatelco-intercept-amendment-bill-introduced-into-the-senate/#comment-55728 ..and of course RFC2822 more or less describes the format of an email message without really enforcing the meaning of the fields. For example, it goes into intricate detail about the possible ways of describing the 'Sender:' email address, but doesn't insist that the email address be real. A telecommunications provider carrying an email message across their network can use RFC2822 to see if it is well-formed but not if it actually came from who it says it came from. Hence spam. The AG's department is being a little disingenuous when it says "This is an obsolete standard that was superseded in 2001 by RFC 2822 and the relevant header fields stated by EFA cannot be found in the current standard. RFC 2822 also states that these obsolete fields `MUST NOT be generated'". They are right: an RFC2822 system oughtn't generate those headers, but they `MUST be accepted and parsed by a conformant receiver'. Because RFC2822 says these headers shouldn't be out and about on the intertron doesn't mean they aren't. So the EFF's comments still apply. "Telecommunications data" is a very fuzzy term, as is "content". ..and of course RFC2822 more or less describes the format of an email message without really enforcing the meaning of the fields. For example, it goes into intricate detail about the possible ways of describing the ‘Sender:’ email address, but doesn’t insist that the email address be real. A telecommunications provider carrying an email message across their network can use RFC2822 to see if it is well-formed but not if it actually came from who it says it came from. Hence spam.

The AG’s department is being a little disingenuous when it says “This is an obsolete standard that was superseded in 2001 by RFC 2822 and the relevant header fields stated by EFA cannot be found in the current standard. RFC 2822 also states that these obsolete fields `MUST NOT be generated’”. They are right: an RFC2822 system oughtn’t generate those headers, but they `MUST be accepted and parsed by a conformant receiver’. Because RFC2822 says these headers shouldn’t be out and about on the intertron doesn’t mean they aren’t.

So the EFF’s comments still apply. “Telecommunications data” is a very fuzzy term, as is “content”.

]]>