Explaining Open Standards email attachements

Sam Liddicott sam at liddicott.com
Mon Apr 5 16:55:40 UTC 2010


  On 05/04/10 17:22, Hugo Roy wrote:
> Le lundi 05 avril 2010 à 17:08 +0100, Sam Liddicott a écrit :
>> My point as I first mentioned is that I cannot tell if your text is a
>> political document or a guide to interoperability. My point is that it
>> can't be both.
> This text is not a political document, nor a guide to interoperability.
> This is just an explanation of why it is wrong to send proprietary
> attachments with emails, because you never know if the person you send
> it to will be able to read it correctly.
>

However this is not true; if I send proprietary mp3 I *know* my 
recipient can read it unless they took steps not to be able to.
If I send open standards ogg I *know* that my recipient cannot read it 
unless they took steps to be able to.

It has nothing to do with "proprietary".

> That is not the purpose of this text to be a technical guide. I leave it
> to those who share the link to explain how to do that.
>

It can't be done, as I said. I'll be called a liar.

>> "When you attach a file to an email, please make sure that your
>> correspondent will be able to read your files correctly. It is a basic
>> principle of courtesy. And there is an easy way to make this possible:
>> use open standards."
>>
>> As I showed, with mp3 the correspondent likely will be able to read
>> the file correctly unless they have taken an active and informed
>> decision to not be able to. With an open standard that you mention -
>> ogg - this is not true at all.
> Yes, this is true. If you send an ogg file, you make sure that your
> correspondent will have the possibility to read the file correctly with
> the software of his choice, including Free Software!
>
> The matter of will is not the same as the one of possibility.

I don't think these finer points of position will impress the average 
man any more than the idea that DRM == choice. (As in maybe people want 
to choose pay $1 for itunes track and then $3 for a ringtone of the same 
track).

>> With ogg, your statement "If you do so, your correspondent will have
>> the possibility to choose which program he or she wants" actually
>> becomes "your correspondent will probably be required to choose a
>> different program to the one they usually use" - as you showed when
>> stating recently that the correspondent may have to install VLC or
>> Firefox.
> Yes, if they use software that don't handle Open Standards, which is in
> most of the cases Proprietary Software we want to fight against.
>

That's what I mean. This is really a political document fighting against 
proprietary standards.

> I'd like to say that your statement here is wrong, because it applies
> for proprietary formats, not to Open Standards, where people have the
> choice.

It's inconvenient to most people because suddenly they don't just have a 
choice, they have to make a choice.

> When you get a proprietary attachment: then you are require to choose a
> different program that the one you use. If you get an Open Standard:
> *it's up to you*.

I can't easily tell the difference between those two positions.
Proprietary => choose a different one
Open Standard => it's up to you

>>> The point of this text is to give an easy explanation of why open
>>> standards are important, taking the example of emails. In doing so, it
>>> also tries to raise awareness on some Open Standards such as ODF and
>>> OGG.
>> Then it is a political document and not an instructional one. Is the
>> audience intended to be those who are already aware of the issue and
>> just need to have useful information gathered in once place, or is it
>> intended to convert and/or raise awareness among those who aren't
>> aware of the issues?
> The purpose is to give an easily understandable text to explain it. The
> target is people aware of the issues, who want to share the link when
> they get proprietary attachments.
>


I don't think so, you said:

>Yes, if they use software that don't handle Open Standards, which is in
>most of the cases Proprietary Software we want to fight against.


The purpose of the document is to take advantage of the inconveniences 
of proprietary formats in email to fight against proprietary software.
I don't have any complaint with this; I just think care should be taken 
to choose scenarios that can be won. docx can be won because many office 
users can't read docx. Ogg cannot be won because for most users open 
format ogg is more awkward then proprietary mp3. So as a political 
document, I think you need to make clarifying points in relation to ogg, 
or anyone (you say "it's up to [me] and the others") who follows your 
advice on ogg will get a black eye and you may lose a convert to open 
formats.

>>> All the rest is up to you and the others, to refuse or accept mp3 files
>>> or not. I don't care and I do not want to discuss in the text to reject
>>> mp3 files because they're not Open Standards: I understand it is about
>>> convenience, but I want to say that convenience comes on both sides.
>>> That's all.
>>
>> For sure, I don't think that such a discussion it belongs in the text,
>> but it is one of the questions the text raises; it is an implicit
>> self-contradiction in the text - that widespread standards aid
>> interoperability, not open standards Open-ness is just a partial
>> driver for wide-spreadness, not a substitute.
>>
> I strongly disagree here. Widespread standards (that's a pleonasm) aid
> the one in control of the standards. Open Standards aid interoperability
> because control of the standards is shared.

I think sometimes you let idealism stand in the way of truth, Widespread 
standards IS interoperability. Open standards merely potentially 
supports interoperability - as the standard becomes widespread. There 
are enough proprietary widespread standards, or you wouldn't have had to 
write your document in the first place, I think?

Sam
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fsfe.org/pipermail/discussion/attachments/20100405/d1a855d8/attachment.html>


More information about the Discussion mailing list