Subject: [XCON] Multiple Protocols: What Do You Really Want?

From: Adam Roach <[email-masked]>
Date: Wed, 15 Mar 2006 18:44:09 -0600

[not as chair]

Chris Boulton wrote:

> It is for these reasons that I was pondering the prospect of XCON 
> allowing both a handset friendly interface such as CSCP and a SOAP 
> interface for web services where the client might well be another 
> application and not a handset. I realise that having two interfaces is 
> not ideal, but as long as we are careful in our rules on minimal 
> implementation and ability to advertise capabilities to a Conference 
> Client I personally feel that this is the best solution to make XCON 
> appealing to a wide variety of architectures.
>

There have been a number of favorable responses to this proposal, and 
I'd like to feel out some of the thoughts people have on the topic.

In particular, if we choose more than one protocol for conference 
control, we still must select from one of the following four models:

   1. The focus must implement all protocols; the endpoints may choose one.

   2. The endpoints must implement all protocols; the focus may choose one.

   3. Both endpoints and focuses must implement a single specified
      protocol, and may implement others.

   4. Endpoints and focuses implement whichever of the protocols they
      want; arbitrary combinations of implementations simply don’t work
      together.

I would offer that option 4 is a complete nonstarter. There's no point 
coming up with a standard that just flat-out doesn't interoperate in 
some large percentage of the cases. If we want that, we may as well let 
each vendor come up with their own proprietary signaling protocol.

Option 3 gets us back to selecting the one sole mandatory-to-implement 
protocol, which probably doesn't clear us from the current logjam. 
(Anyone who is currently championing a proposal and would be happy 
seeing it as an option but not the "mandatory-to-implement" option in 
such a scheme, speak up).

Selecting either option 1 or option 2 would be a tacit admission that 
implementation complexity is a non-issue (since doing so approximately 
doubles the implementation complexity of either the focuses or the 
endpoints) -- and admitting this takes *all* of the wind out of any 
arguments regarding the relative implementation complexity of XML versus 
binary.

So, of those who have so far spoken in favor of having multiple 
protocols to do the same thing: which of these four models did you have 
in mind? (Or did I miss one?)

/a

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

---

From: "Sean Olson" <[email-masked]>
Date: Wed, 15 Mar 2006 17:26:26 -0800

I would say that option 4 is not a complete non-starter. I would draw
the analogy between a WAP browser and a normal browser. There are sites
that offer support only for WAP, sites that support WAP and regular
browsers, and sites that support only a full browser like Firefox or IE.
This has not proven to be a non-starter for the web. WBXML/WML is a
compact encoding of the same data model that a richer XML encoding
offers and I think a good example of how we can offer both an encoding
that works well for mobile while preserving the richness of
functionality for other clients.

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Wednesday, March 15, 2006 4:44 PM
To: Chris Boulton
Cc: [email-masked]; Adam Roach; [email-masked]
Subject: [XCON] Multiple Protocols: What Do You Really Want?

[not as chair]

   1. The focus must implement all protocols; the endpoints may choose
one.

   2. The endpoints must implement all protocols; the focus may choose
one.

   4. Endpoints and focuses implement whichever of the protocols they
      want; arbitrary combinations of implementations simply don't work
      together.

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 15 Mar 2006 20:08:08 -0600

[not as chair]

To which Sean Olson responded:

>This has not proven to be a non-starter for the web.
>

I'm not sure I'd hold out WAP/WML as a model of how to build a 
successful protocol. I have a WAP browser on my phone. So far, I've 
discovered that I can get to the National Weather Service; a tiny, tiny 
fraction of Yahoo's offerings; and whatever stuff Google can manage to 
automatically translate from HTML without complete information 
destruction. By contrast, the range of information that  I can get with 
HTTP/HTML is virtually limitless.

Of course, I'm happy to be proven wrong. I'll hand you my phone next 
week (WAP/WML only), and I'll borrow Robert's phone (HTTP/HTML). I'll 
try to find information you can't, and you'll try to find information 
that I can't. We'll see whether whether these two optional protocols for 
"the web" have resulted in an even vaguely similar user experience for 
both kinds of clients.

On the balance, it is my opinion that WAP/WML serves as a terrifying 
cautionary tale warning XCON in the strongest terms possible *away* from 
selecting multiple protocols (with none mandatory) -- not an example to 
follow to our own consequent doom.

/a

---

From: "Sean Olson" <[email-masked]>
Date: Wed, 15 Mar 2006 19:15:53 -0800

Interesting point ... Where would the web be today if they had chosen
WAP/WML as the "one" standard to fit the needs of mobile devices? Do you
think we would have reached the level of innovation that we have
including Web 2.0? 

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Wednesday, March 15, 2006 6:08 PM
To: Sean Olson
Cc: Chris Boulton; [email-masked]; [email-masked]
Subject: Re: [XCON] Multiple Protocols: What Do You Really Want?

[not as chair]

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 16 Mar 2006 00:32:57 -0600

(not as chair)

>think we would have reached the level of innovation that we have

To demonstrate why the analogy is imperfect, I would have to delve into 
my opinions around the quality of standards produced by engineering 
organizations versus those produced by parliamentary organizations. 
Since that's a distraction from the issue at hand, I'll rephrase your 
question to be more relevant:

    Where would the web would be today if it had been based on a single
    underlying protocol that was developed with *both* bandwidth
    constrained devices *and* extremely rich and powerful devices in mind?

Exactly where it is today, *except* without many mobile phone users 
stuck in a protocol ghetto created by the creation of two ways to do one 
thing.

A key reason WAP/WML is so poorly supported when compared to HTTP/HTML 
is that supporting *both* requires *twice* the effort. This goes all the 
way from designing protocol extensions up through the implementation of 
servers and on to the actual creation of content. Very few people are 
willing to spend twice as much time, effort, and money than should be 
necessary at every step of the process. The use of a *single* protocol 
would have avoided these issues.

Your objections so far seem based on an underlying assertion that the 
selection of a concise encoding for the protocol somehow limits 
functionality. Brian directly requested that you point out something 
that can be done in a bloated protocol that can't be done in a concise 
one. Your response, by my reading, related not to his question, but to 
the relative ease with which developers could make proprietary extensions.

I will repeat Brian's question: since your objections are based on an 
assertion that a concise encoding will "hobble the rest of the system," 
I request an example. Please provide a simple existence proof of one 
operation that cannot be done simply because we make syntactic 
concessions to bandwidth-constrained devices.

/a

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 16 Mar 2006 22:55:26 -0500

Without addressing the question itself, we have had another object  
lesson, much closer to home: binary and text encoding of Megaco/H. 
248. I haven't been closely involved with Megaco, but this seems to  
have been exactly a similar compromise: similar functionality, one in  
a textual rendition (albeit not XML) and one in a binary rendition  
(ASN.1 BER). Maybe somebody here can say more about this experience.  
See RFC 3015.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 16 Mar 2006 23:41:42 -0600

FWIW, I spent about six months looking at VoIP traces on deployed networks 
last year, and was only seeing H.248 text encoding on production networks. I 
can ask former co-workers what they are seeing now (since I changed 
employers, I don't see the same things :-), but I'm pretty sure that having 
two encodings is likely to give one that's actually used in most situations.

Spencer

p.s. I was also seeing a heckuva lot more MGCP than H.248, but everybody was 
testing H.248. Oh, well.

From: "Henning Schulzrinne" <[email-masked]>

> lesson, much closer to home: binary and text encoding of Megaco/H. 248. I 
> haven't been closely involved with Megaco, but this seems to  have been 
> exactly a similar compromise: similar functionality, one in  a textual 
> rendition (albeit not XML) and one in a binary rendition  (ASN.1 BER). 
> Maybe somebody here can say more about this experience.  See RFC 3015.
>