Subject: RE: What's an experiment?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 18 Feb 2006 06:18:18 -0800

> Behalf Of Frank Ellermann

> Intentionally disrupting other running experiments or 
> breaking standards is also dubious.  

Not necessarily.

One of the most important uses of Experimental is to document the
minority position when a working group gets its cranium embedded in its
posterior. In a significant number of cases the minority position has
turned out to be right.

In a consensus based organization it is very easy for a minority to
prevent any change in the status quo simply by filibustering the
proposed change. This is not a good thing when the status quo is failure
to deploy for a decade or more.

Experimental is also an essential safeguard to prevent the game of a WG
with an unsuccessful protocol finding other groups to inflict it on.
Given the impressive lack of success of BEEP vs SOAP it would be much
better for the IESG to formally recognize that this attempt to ratify a
'me too' protocol in 9 months has backfired and is now harming IETF Web
Services efforts.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 18 Feb 2006 17:39:59 +0100

Hallam-Baker, Phillip wrote:

> One of the most important uses of Experimental is to document
> the minority position when a working group gets its cranium
> embedded in its posterior. In a significant number of cases
> the minority position has turned out to be right.

So here you'd say "let the minority have an experimental RfC",
in the spirit of "better document than not publish", besides
the minority might otherwise decide to block everything.

What if the solutions simply can't coexist, one of them harming
the other ?  What I said was "intentionally disrupting" ... "is
dubious".  If both sides get their way, but it cannot work in
practice, e.g. different semantics for the same bit, agents
don't know if it's a minority bit or a majority bit, then it's
wrong.

And if a simple solution how both sides could coexist without
worldwide upgrade stunts is possible, but one side refuses to
consider this, then it's malice.

> Given the impressive lack of success of BEEP vs SOAP it would
> be much better for the IESG to formally recognize that this
> attempt to ratify a 'me too' protocol in 9 months has
> backfired and is now harming IETF Web Services efforts.

Are they related ?  I had the vague impression that BEEP is
a way to multiplex one TCP-connection, and SOAP is a kind of
RPC with XML over http-post (and other bindings).  Not the
same layer, different problems => different solutions (?)

Both no experiments and not harming each other, or are they ?

                        Bye, Frank

---

From: Andrew Newton <[email-masked]>
Date: Sat, 18 Feb 2006 15:38:19 -0500

> same layer, different problems => different solutions (?)

Frank,

You are right.  They solve two different problems.  In fact, I  
believe one of the bragging points about SOAP (other than it can  
defeat your firewalls and snooker your security admins) is that it  
can be run over various transfer protocols, such as that defined in  
RFC 3288.  If great harm can come from using SOAP as intended, that  
says more about SOAP than it does BEEP.

-andy

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sat, 18 Feb 2006 23:12:36 +0100

>consider this, then it's malice.

Dear Frank,
the situation you describe is RFC 3066 Bis situation. There is no 
problem for the RFC 3066 Bis ABNF and the RFC 4151 to coexist. But 
the affinity group refusal. You use the term "malice", I did not. I 
prefer to use the terms lack of vision, or RFC 3869 motives.
jfc

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 19 Feb 2006 11:02:28 +0100

JFC (Jefsey) Morfin wrote:

> the situation you describe is RFC 3066 Bis situation.

No.  As far as I'm concerned you can publish your draft
announced for early 2005 whenever it pleases you.

You can also create your very own "language name system"
organized like DNS with multiple roots and governmental
control when you find the time for it - IIRC you want to
discuss it with the UNESCO and the UN general assembly
first, so this delay is not necessarily your fault.

Another of your ideas is to use the tag-URI scheme for
language tags, after all they are "tags", and consistent
terminology is a good thing.  But the LTRU WG decided
to stick to the 3066 syntax for backwards compatibility,
and it was you who wanted to disrupt and break 3066.

> There is no problem for the RFC 3066 Bis ABNF and the
> RFC 4151 to coexist.

Because they are unrelated, all they share is the word
"tag".  You can use as many tag-URIs as it pleases you.
If you use them as values for xml:lang or in similar
3066-contexts it would be invalid.  Otherwise no harm.

> You use the term "malice",

This thread is about experiments passing a laugh test,
or that was my assumption.  It's good that you made it
clear that there also cases not passing a laugh test -
I'd say that's not good enough for "experimental RfC".

Above all there must be a draft first.  I don't think
that the IESG question is about "experiments" with tag
URIs in 3066-contexts.
                       Bye, Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Feb 2006 19:21:42 +0100

I did ask for this thread to be general. No problem if you
want to discuss your (least) favourite protocols here,
but please change the subject line...

Thanks

     Brian

Andrew Newton wrote:
> You are right.  They solve two different problems.  In fact, I  believe 
> one of the bragging points about SOAP (other than it can  defeat your 
> firewalls and snooker your security admins) is that it  can be run over 
> various transfer protocols, such as that defined in  RFC 3288.  If great 
> harm can come from using SOAP as intended, that  says more about SOAP 
> than it does BEEP.
> 
> -andy
>