On Tue, Mar 29, 2011 at 13:24, Eric Burger
<eburger(_at_)standardstrack(_dot_)com> wrote:
Yes, it is MUCH easier for a server developer to stuff in a little
more JavaScript.
Now, you have a 100% proprietary system, with no hope or desire for
interoperability
There has to be interoperability in the system, but not at every
interface. Bear with me while I compare this situation to big old
computers connecting to a network. The I/O bus, for example, does not
have to be standardized -- it's an internal matter. It's only when
you reach an administrative boundary that you need a standard. A
standard API can help when there is advantage to opening up the field,
e.g. BSD sockets, so you create a standard interface and if necessary
you establish an administrative boundary at that point.
OK, so you probably know where I'm going. In a system such as mail,
where are the administrative boundaries? There are two scenarios:
- An "application", for example an MUA makes it possible for you to
do your mail. This is essentially a "service" that interfaces to
a "client", the human. There is no administrative boundary there,
and the ways in which "client" and "server" interact is not
standardized. But there is an administrative boundary when the
application wants to talk to either a mail transport agent or
another such service. At that point there is a published
interface spec.
- A "service" such as Gmail or Hotmail is serving a "client"
specific to it. That interface is proprietary -- unlike above,
where there is an administrative boundary, everything here is
"internal". But there is a boundary between such "services", and
that is standardized. In some cases an individual "service" can
have several (SMTP, CALDAV etc.)
Some web-style services have decided that there is an advantage to
letting a hundred flowers bloom, and they have defined clear
boundaries and specified interfaces. Consider Twitter.
So back to what you said ... there is hope for interoperability, where
it is seen as useful. Some do, some don't.
The only reason
one would go for the standard solution is if they want to
interoperate with other vendors. As you point out, there is
absolutely no reason for anyone to participate in the standards
process if they have no intention of interoperating with OTHER
implementations.
Yup. Just because some don't doesn't mean it is not possible. And in
those situations where it looks like "there is no interoperability",
therre is interoperability at administrative boundaries.
Next step ...
When things like rtcweb want standardized ways for clients to speak to
each other over a transport provided by web services, they are
creating a "layer network" (q.v.). In this case the web service
interface is like a link layer (it's specified for use within a
particular subsection of the layer network), and the end-to-end
communication is like a network layer. Where does it have to be
locally standardized, and where does it have to be globally
standardized?
Scott
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf