On Sat, 2 Oct 2004, Meng Weng Wong wrote:
On Sat, Oct 02, 2004 at 09:31:56AM +0200, jpinkerton wrote:
|
| Mark has said that he is a "shepherd" and that is a very comforting attitude
| from us sheep's point of view ;-) , and Meng is baffled by us needing
| permission to do things, which is probably because he doesn't realise just
| how much of a leader he is seen as by M$, IESG, the press, etc, etc.
My leadership seems to derive mainly from good service to
good ideas.
It is derived mainly from supporting, encoriging development of and promoting
the ideas supported by the majority of the community that you attempt to
represent.
So I will write down some of the ideas that are
now in my head. If people agree with those ideas, perhaps
they will also agree with the course of action which I suggest.
So far there was very little agreement with those actions based on
majority of other posts.
I have no formal training in political theory, but I have
studied systems architecture, which is about designing
systems that work for many stakeholders whose interests are
generally compatible but can sometimes conflict. By that
definition systems architecture and legislative politics
have a lot in common.
And I've also studied system architecture and engineering of complex
interoperatable systems and separately studied political history,
I've not found that much commonality between the two.
It is however notable that in case of SPF we're not dealing with
only system architecture design but with standards process which
is a different fish. In standards process you must work towards
design that everyone can implement, that tries to base itself
as much as possible on existing supported standards, that does
not break them and that can be easily extended in the future.
This process may sometimes have more to do with politics, especially when
several stakeholders come together to create interoperatable architecture
standard and such work may require political compromises. But in politics
there certain criteria that are used when two different parties decide if
its in their best interest to work together on compromise proposal:
1. The compromise MUST NOT hurt either party in the future
2. The proposal should not be opposed by majority of stakeholders of
either party (note that difference between "should not be opposed"
and "must be supported")
3. The end-result should be supported by majority of both parties when
counted together
And we seem to have problems with all of the above. First of all Microsoft
proposal would hurt FOSS movement because they are trying to make
technique that can not be implemented by FOSS to become standard
and SPF community is basicly part of this FOSS movement. Second many
and possibly even majority of the SPF community seem to be directly
opposed to PRA and working with Microsoft ideas (see previous messages
at spf-discuss) and when last-call was called at MARID (which can
be considered a place where both spf and microsoft and others came
together) there was definetly no majority support for Sender-ID either.
Additionally when working together on compromise it requires both parties
to bring something to the table and to be able to benefit from what the
other side has. Lets see what we have here: SPF community brought in SPF
protocol, which was tested and refined over the last year. What did Microsoft
bring in? - caller-ID algorithm, but it has not been tested and appears
to have multiple flows. But even if it did not - are they letting us
benefit from it? No!!!
So I'm sorry, but even from the standpoint of trying to create political
compromises, it is not in SPF community's best interest to work together
with Microsoft. Now that does not mean we should not let Microsoft do
what it wants - we should act as gentlemen and if they can use our work
we should let them (unlike Microsoft's position...), but SPF community
should not actively assist them in that or do anything to make it seem
like we endorse their work or Sender ID.
To my uneducated eye, there seems to be an important pattern
in both politics and systems architecture. I want to talk
about this pattern because it appears relevant to the
current question of "what to do about Microsoft and PRA".
The pattern identifies two principles: on the one hand, we
have inclusiveness; on the other, control and dominance.
If you mean that you can use inclusiveness to force dominance, we've
definetely seen that. That is a core of building the monopoly and it
can be found both in software and in other business areas and in
political movements. And without effective means of control the few
will always try to dominate the many, that has been the seen in history
over and over again.
But new political systems that began to emerge in the last century have
laws and other counter-balances in place that allow to disrupt this
practice and if necessary let many be heard and stop the few that are
trying to dominate. In case of internet standards IETF serves as
counter-balance that lets many stop the few that may try to create
their own standards and dominate the industry with that.
This pattern shows up all over the place. Local politics
today, no matter where you live, can be read in those terms.
During the Cold War, when Ronald Reagan called the Soviet
Union an "Evil Empire" he saw democracy as liberal/inclusive
and communism as controlling/totalitarian. Going farther
back, three thousand years ago the Taoists had yin and yang.
Black/White, Good/Evil, Right/Wrong, etc.
I note that in all of these we have something of the opposite concepts.
Building of a standard is simply not possible when we have opposite
concepts, so this would not apply to our situation.
However in reality that comparison is flowed to begin with - PRA and
Mail-From and not opposites and to be honest I really dont see how
comparing one to democracy while the other one with communism makes
sense (and if it did, guess which one would the people pick as being
a democracy :).
[Here was text regarding Canada and its supposed bilinguism, I also don't
think this has anything to do with SPF, Microsoft, PRA, etc. But since I
happen to disagree with Meng's assesment of situation in Canada, I moved
that text and added my own comments to end of this post on that topic]
What does this have to do with Microsoft? The SPF community
has shown strong support for the envelope sender. And this
makes sense, because the envelope is the natural domain of
the MTA. Microsoft has shown strong support for the PRA in
the headers.
PRA does not exist right now and many argued this concept is flowed
to start with. On the other Return-Path (envelope sender) has been
around from beginning of SMTP and is widely used.
There is some need to authenticate "From" header, but I've not seen
any good algorithm that could be used for this that is based on LMAP
concept (dns authentication of the ip of the SMTP Client), in fact
I'm prepared to argue that such trying to authenticate From: header
based on ip address of SMTP Client is not compabile with current model
of SMTP email system.
And that makes sense, because headers are the natural domain of the MUA.
Lets be clear about something - on one hand we're trying to authenticate
session parameters during session. Headers are not part of SMTP session,
so how can it make sense for it to be used for authenticating session?
Message body can however be effectively authenticated by means of
cryptography - this is a proven system that has worked for last 10 years
and we even have two standard for that - S/MIME and PGP. However these
standards do not effectively deal with message headers in the encryption
system - and that is something for MASS group to work on.
Coincidentally, the opensource world dominates the MTA market, and the
commercial world, notably Microsoft, dominates the MUA market.
Coincidently if MUA world wanted to have security for email body they could
have it deployed everywhere by now - S/MIME is 5 years old and PGP is 10
years old. Its a failure of MUA software providers that have not effectively
marketed this to end-users that is part of the problem we have now.
On the other hand MTA world has worked very hard to combat what is
primarily message content problem (i.e. which belongs into MUA world),
and have come up with some session security tools to deal with it.
Spam email filtering systems are widely deployed not because of efforts
by MUA vendors (and some did help there, but not the biggest vendors)
but by efforts of those running MTAs. Now we're going to bring MTAs
even further into dealing with this problem by allowing MTAs to do
automated message - something that we could have avoided if MUA vendors
were really doing their job on email security well!
And BTW - this is not the first time we've seen that Microsoft has
sucrificed security in order to allow for fast deployment. They often
wake up day too late and begin to come up half-baked solutions to the
problem and at the same time blame everyone else for what happened.
(2nd or 3rd time around they may well get it right, but notice that
for spam its so far the 1st time around for microsoft solution...)
So we observe a natural connection between SPF Classic, the
return-path, opensource, and MTAs. We observe an equally
natural connection between Sender ID, the PRA, Microsoft,
and MUAs.
I'm sorry but I see no "natural connection" in all of that...
I do see "natural connection" between SPF Classic and return-path because
it is authentication of session parameter during session. I do see natural
connection between message body authentication and cryptography and email
encryption techniques.
But SenderID does not seem to have a very "natural" place for it...
Of course there are exceptions: plenty of
commercial MTAs and opensource MUAs exist, and where do you
put SpamAssassin? But it is telling that the MTA vendors
have generally added support for SPF first and Sender ID
second if at all --- and that is simply because of the
natural connections.
No major MTA has so far implemented SenderID. And if they implemented SPF
checks first that is because its session authentication system unlike the
"unnatural" SenderID.
It is an interesting question for fans of alternate
histories to ask whether, in a parallel universe where MUAs
were overwhelmingly opensource and MTAs were overwhelmingly
commercial, Microsoft would have been a proponent of SPF.
It would because in that case it would have understood MTA world better
and would support system that is session based for session verification.
But this is not relevant; the important question is what
position the SPF Community should take on the PRA and on
working with Microsoft.
It is the main question and so far it seems politically the compromise is
not in our best interests and technically Sender ID has serious problems.
I know that among the opensource
commuity, who have been burned many times, and, with the
patent application, continue to be burned, the natural
instinct is to say that cooperating with Microsoft in any
way is beyond the pale. And the same community has said
that on a purely technical level the PRA is simply
unworkable, and will be exploited the day it comes out, and
that while sendership can be verified by IP-based channel
methods, authorship can only be verified with cryptography.
Good, you understand this too.
We must distinguish between these two positions. One is to
say that you would rather speak English than French; the
other says that French people are bad.
Again you try to make inappropriate analogy between two different things
to feet into real world analogy and compare similar things, this is well
known trick in the debate and I do not like when people do this on purpose
(last time I've seen something like this when SPF scopes were compared to
gasolone types, but gasoline types can not be mixed together and you have
to use or the other, where as SPF scopes can be used together).
If you want to use language analogies, lets take latin alphabet and
binary code. One is good for human communication, while 2nd one is good
for computer communication. Is it possible for humans to create 2-symbol
alphabet to represent english language? Sure - morse code. Do we use it
in our writing? No. Why? Well, because its technically not a good
representation of human language sounds and because its more difficult
for us and we'd rather use latin script. But does it mean that 2-letter
script like morse-code is BAD? NO - it does not! It just not suited for
ordinary writing.
And BTW - its probably not the best analogy for our situation either,
but its better then French to English!
I believe in the importance of protecting mail-from. In
August, I made a special trip to Redmond to try to convince
Microsoft to reserve a role for the return-path in Sender
ID. I was pretty much shown the door. It took the IETF to
make that point.
I don't believe IETF made any points with Microsoft did as last I heard
Microsoft said they will not be checking mail-from and are only interested
in implementing PRA. No matter how many times people said its not a good
way to use dns authentication of SMTP client and especially not a good
idea to do it after the session is over, they still dont listen. Its
nightmare when such a large company is not driven by technical excelence
but by bad political decisions.
I also believe in being inclusive. We now have the option
of submitting drafts to the IETF which do not give PRA any
role at all.
Or we can submit drafts which give the marke a choice of scopes,
including mail-from, helo, PRA, and possibly others.
I believe that a single syntax which can apply to multiple
identities is more gracious than a syntax which excludes one
of them by design.
I think we should submit drafts of the protocol that is actually being
used right now (SPF v1) and work further on new version of SPF protocol.
That does not mean we're excluding PRA, but we should not make it a
priority to rush our work just for Microsoft. We should now work further
on Unified SPF concept that would support multiple scopes and when
we're ready we should then submit new SPF v2 protocol specification as
well as appropriate additional Unified SPF scopes.
When SPF v2 with multiple scopes support is ready if Microsoft wishes to
use that we should be professional and not explicitely exclude them, so
they can then publish a specification for PRA scope.
But as for main Unified SPF algorithm, I do not believe it should in any
form reference PRA as that scope can not be implemented by majority of
SPF community. Instead we should focus on the scopes and specification
documents that are likely to not require license to implement it.
| By doing this you give M$ the same advantage of "first-there" as SPF
| classic.
| You're either playing politics or you're in league with M$ - which is it?
I am certainly not in league with MS: I have not taken any
money from them, and in fact I half expect them to sue me
just to shut me up.
I have hard time believing that they will sue you to shut you up, we
do have concept of free speach after all and Microsoft also is not
known for abusing legal system in this way (so far...).
On the other hand I also have to note that right now you're basicly the
only person on this list advocating for what Microsoft wants and I hope
this is not something that has been forced upon you under threat of
some legal action and only represents your personal opinion.
I do find this course of action to be inappropriate in some cases in
light that many in outside world and in press see you as representing SPF
community. While your opinion is your own and nobody has any right to
stop you from expressing it, it would be appropriate when you speak on
public events to make it clear that when you say you support Microsoft
Sender ID proposal, that means you're expressing your personal opinion
and that opinion does not represent the majority view of SPF community.
I entertain no illusions that in the event of a lawsuit the opensource
community would come to my rescue. The SPF donation link typically sees
a $2 contribution three times a week, and I don't expect a legal
defense fund would do any better.
Actually in event of lawsuite like that EFF would get involved and provide
you with free legal defense and likely succeed as they do have pretty good
lawyers working for them that specialize in these very matters.
I am arguing for PRA support not because I think PRA is
technically right, but because giving Microsoft what it has
asked for is gracious. And if Microsoft is going to take it
even if we don't give it to them, then it is not only
gracious; it is pragmatic.
I wonder why UN did not approve latest invasion of IRAQ by US and why
majority of the world did not participate in it? Did they not realize that
US can and would do it on their own anyway? So why were there less then
dozen countries that were so pragrmatic and why was UN security council
not gracious to US demands? Oh, and BTW, did it turn out all right,
especially for US in light of all the costs and even worthened security
situation in middle-east?
Perhaps when majority say its wrong and its not a good idea, even if you're
so powerfull that you can ignore them, its better to listen. So many
people can not all be wrong!
So, to answer the question, in part I am doing it because it
seems to be the right thing to do, and in part I am playing
politics.
I ask you to go back to beginning of this post and to reread the part
about politics and how this is actually a politicly bad decision for
SPF community.
The extremists in the SPF community who hate Microsoft can
do two things: they can deride the PRA, or they can actively
try to suppress it from the standards.
Hating Microsoft and working against standartization of PRA are different
things. I would gladly suppress my personal opinion of Microsoft and work
with them if they provided great new techology that is not flowed and were
willing to make it available to entire public without restrictive license.
But that is not the case, that is why I chose best parts of the Sender ID
(that did not have technical or IPR problems) and created separate document
for it - RFC2821-only SUBMITTER - and I'm glad to acknoledge Microsoft
participation in original documents that went into that draft.
If they tried to suppress it, I have no doubt that we would quickly see
a full-blown standards war. Microsoft is committed to Sender ID and
already has more money and manpower dedicated to implementing and
evangelizing it than the entire SPF community combined. Going head to
head is not a viable strategy. If we refused to allow PRA at all, I am
sure Microsoft would publish Sender ID as a standard anyway and
say goodbye to the IETF.
That is possible and may even be likely but it would then be clear that
its not a standard but a specification supported exclusively by Microsoft
for Microsoft. There would not be any standard war because of that just
like there are no standard wars because of Netbios vs TCP/IP.
Part of the fallout from that standards war would be delayed adoption of
SPF (both Classic and Unified) in the market,
I do not believe it would change anything. Microsoft already said they
will not be supporting SPF Classic envelope mail-from checks and will
only be looking for PRA scope records. Others have already said they will
not be looking at PRA records and will only check SPF-classic.
and possibly a reversal of their decision that SPF Classic is not
covered by their patent.
Excuse me, but were there really any such "decision"?
And reality check - there can not be decision changes like that, its
either covered by the patent or its not. The only decisions are that they
can choose not to say if its covered or they may choose to specifically
say that it is covered.
At the same time, I have also not seen any strong case that can show
that Microsoft or any other company has rights to ideas that were
created by others and published before they applied for a patent.
None of these things would be in the public interest.
Public's best interest in case of email security is served by technological
excellence and not by decisions made for political reasons to support flawed
idealogy.
If you do not believe that PRA will work, you are free not
to use it, and you are free to convince people of its flaws.
It appears that is exactly what is happening on this list. However it also
appears the only person we're trying to convince is Meng...
Think for yourselves and let others enjoy the privilege to
do so too. But attempts at censorship are rarely productive.
Nobody is attempting to stop Microsoft from convincing us that their
technology is good, so far they have failed to do so!
Does that mean we should stop Microsoft from attemting to do in on their
own? No. But we should tell them its bad idea and should provide no
support for such bad ideas in any way shape or form!
Originally SPF Classic was about the mail-from, and used
HELO as a fallback only when the return path was null.
Good. That is the way it should stay for SPF v1.
In January, Hector Santos argued to elevate the HELO scope
to first-class status. Since January receivers have been
free to interpret an SPF record in HELO and MAIL-FROM scopes
equally, and publishers have been admonished to ensure
compatibility with both scopes.
I do not believe this is a concept universally agreed to by SPF community.
and I do not think there are too many implementation to do so. I think
we should not encorage this practice and specify precisely what identity
the SPF record covers.
When Harry Katz, Jim Lyon, and Bob Atkinson discussed Sender ID in May,
we agreed that v=spf1 records could also be interpreted in PRA context
without risk. Margaret Olson and others in the IETF later objected that
different scopes required disambiguation. This objection led to the
creation of the sp2.0 prefix.
To satisfy all of the above views, I would like to pursue
the following approach with Sender ID:
v=spf1 originally applied to mail-from.
v=spf1 now applies to helo as well.
v=spf1 will in future apply to PRA also.
That is the worst approach I've heard so far. In my opinion it is a mistake
to apply SPF1 records to everything together. At least with EHLO you usually
have host.example.com and rarely do you actually have email coming as
email(_at_)host(_dot_)example(_dot_)com so there is some degree of separation
(not very
good one as I have mentioned before this breaks with wildcards), but PRA
record would need to be entered in same location as spf1 mail-from.
People who have published SPF1 records currently have published it for
purpose of mail-from checking. They did not make any assumptions about
that it maybe checked for PRA and some may not want that to happen,
i.e. how would you like it when your words are taken out of context?
This approach is like having file system without extensions or having
MIME without types... BAD!
No - I do not think we should allow for multiple scopes under spf1 at all
or make it a "*" scope. I believe our best approach is to standartize
SPF1 record to mean Return-Path verification and further work on getting
Unified SPF with new scopes that are compabile with SPF1, but make those
new scopes explicitely defined if its anything other then mail-from.
Senders whose PRA and mail-from configurations are
identical need only publish v=spf1. This describes the
vast majority of senders, particularly those with control
over the Sender header.
Some senders may not want to publish particular scope like PRA because
they fear its use is not technically accurate. Same goes for mail-from.
I prefer that senders that want the data to be used for PRA or for
Mail-From explicitely defined their record in that way and if its
the same as from SPF2.0, they specify both scopes, like:
"v=SPF1 v=SPF2.0/PRA,MFROM ..."
The above is pragmatic because it allows spf1 records to be
used by the Sender ID / Microsoft / PRA camp; it also allows
spf1 records to be used by SPF Classic; and it removes the
need to fight a battle over whose is bigger. I mean,
better. Avoiding a standards war is in everybody's
interest. Getting Microsoft to tell people to publish
v=spf1 records would also have been in our interest.
No - Microsoft is telling people to publish records for purpose of PRA
checking. We don't know if they are ok with those records being used for
envelope mail-from checking. The published records should reflect the
meaning of the publisher.
Unfortunately, the purists won that round, and I expect
Microsoft to spend considerable resources telling people to
publish spf2.0/pra records only. However, if the
specifications leave room for other scopes, I hope and
expect that third-party advisories will present a more
balanced view.
If we bundle mail-from into Sender ID, and if Microsoft
backs Sender ID, then Microsoft won't want to kill
mail-from.
Again listen to what I told you in private and in public:
- Distinguish SPF from Sender-ID by all means!!!
Microsoft has already made strong effort to "own" Sender ID term. Their
effort is not even stopped by the fact that the term is trademarked - they
dont care about some small company who has prior art in the term, this
is the kind of company we're forced to deal with and we have to explain
to them when they are wrong and ignore such bad habits.
It is in best interst of SPF community to make SPF mail-from and UnifiedSPF
stand on its own and make SenderID to be no more then a scope that is using
UnifedSPF syntax and furthermore scope that is not endorsed by SPF community.
I expect vendors to do "all of the above" anyway, so asking
them to exclude one technology isn't realistic. That works
in Microsoft's favour, because that means PRA will have a
future; and it also works in the SPF community's favour,
because it ensures survival for mail-from.
Depends on vendors. If you mean publishers, then yes - most likely they
will publish both mail-from and PRA. If you mean vendors of MTA software,
I expect many will not be implementing PRA checking. Since effort of SPF
community is to provide means of email session verifiction for MTA, that
means we got what we want.
Folks who think that Microsoft should abandon PRA entirely
are welcome to take that up with them directly. Asking them
to abandon PRA is like asking them to not sell a billion
dollars of the next release of Outlook.
I do think they should focus on better technology but I also realize
they do not listen to anyone else any more...
So, even if nobody here likes Microsoft and nobody here likes PRA, those
are the reasons I think we should specify spf1 to include PRA, and we
should specify spf2.0 to allow explicit PRA scoping.
No we should in no way aid Microsoft, this is not in our best interest
politically or otherwise. And as far as SPF1 we should not allow it to
be used for anything but the scopes already defined (mail-from)
As for SPF2.0 we should NOT deny Microsoft ability to write draft to
specify PRA scoping, but we should not aid them in it either.
After all that, if people feel that a policy of appeasement
is misguided then please say so. After all, appeasement has
been known to fail in the past.
Yes, I think appeasement has been known to backfire badly, especially with
tirans. The example with Hitler that was already given was right on point
and we have many more examples like that in history. In majority of cases
these people will take what they can in peace talks and then they still
think its not enough and they will still go to war. Lessons to be learned.
I think the lesson we can take from MARID is this: above a certain level
of organization, formal bodies are inherently subject to denial of
service attacks eg. filibusters. These kinds of attacks are moves in a
game which operates at a lower layer in the stack. If we do not
organize at such a high level, we can counter those moves more directly.
What happened in MARID was quite appropriate in that solution that was not
supported by majority was finally defeated. The lesson to be learned there
is not to be so political and not promise one particular organization
something that open standards forum (that is capabile of brining entire
internet community together) may not be able to deliver. That is the
lesson we must learn - so don't repeat the same mistake by making any
promises from SPF community to anybody else!
-------------------------------------------------------------------------
[below is Off-Topic to the list and is my opinion about situation in
Canada and Quebec in regards to their official languages]
If there is an arrow of human destiny, I would like to think
it points in the direction of inclusiveness. Take Canada,
with an English-speaking majority and a Francophone
minority. Throughout most of human history, forced
assimilation would have been the norm: the minority forced
to abandon their French roots and learn only English in
schools.
BTW - English did try forced assimilation in canada, it failed. They were
however sucessfull in some parts of canada that could be populated by new
immigrants.
Yet Canada is bilingual. All official
communications are expressed in both languages. In
English-speaking provinces, this is arguably wasteful. But
we recognize that bilingualism is more enlightened than
genocide.
Canadian bilingualism is an example Alexis de Tocqueville
would have admired. He distinguished between freedom and
equality, and that distinction is important. Canada could
have achieved equality: citizens could have been equally
free to speak English. Instead it chose freedom: citizens
are free to speak different languages with equal fluency.
I don't know how many times you've been in Canada and if you could
ever really feel their "bilinguism", but I had been visiting on regular
basis (three times in any two year periods for last 10 years)
and had been multiple times in Toronto, Montreal, Vancouver, Ottawa
as well as some smaller cities both in Quebec and in other parts of
Canada. The only place that true bilinguism really exist is Ottawa
and to smaller degree in Montreal - there many people can easily
speak either one of the languages.
In other places its very exclusive, I've multiple friends from Toronto
and they all had to learn French in school, but they would understand
it worth then I could on visit to Montreal - it was no more then a
required foreign language and in truth I've seen people in europe learn
foreign language to a lot better degree then what either American students
do with foreign language of their choice or in Canada where they have
one "required" foreign language.
And talking about exclusiveness, a relative of mine was in University of
Sherbrooke half a year doing research. He said that there were no english
signs at all there and nobody even attempted to speak English and most
could not understand it. Similarly if you go to Vancouver, there are no
french signs there and people don't speak french (btw - an interesting
situation actually happened there half a year ago when after a a conference
I went to aquarium in stanley park, at the same time I came in a group
of students from city of Quebec came in. As aquarium is state/federally
funded it had majority of signs in French too, but they had just slight
problem of finding a tour guide that could actually speak french...)
I've talked to people about this subject on both sides of the "language"
border in that country. Most don't really feel the problem has been
addressed. French are there still speaking french not because English
have not tried to assimilate them (they did and they took majority
of what was french canada for english colonists, i.e. what is now
Ontario was before upper canada and was originally settled by french)
but because for last 200 years they refused to be assimilated and
continued to speak their own language and tradition. They feel strongly
that english does not belong in their community and there is nothing
federal government can do about it. At the same time in English parts
the people don't care care about french language and cant understand
and as you say see it as waste of their resources.
Now creation of this artificial language duality was a political reasoning
to keep country together but it was still done by forcefull means. Now
that the world is more tolerate to self-expression, we have a situation
that majority of french-speaking population in Quebec said they want to
live in separate country. So what did that language-duality bought Canada?
It did nothing but postponed the inevitable break-up of the country. Most
of the people I talked to on either side think that 20 years from now
Quebec will be independent country.
I personally think its moving toward a confederation with Canada & Quebec
being officially independent countries and being able to make laws regarding
language entirely on their own (most likely that means English would not
be official language in Quebec any more or French in rest of the country)
but maintaining some form of central federal structure (like European
parliment, etc) and maintaining requirement for dual-language only for
those federal institutions that remain shared.
---
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net