OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: "Binary XML" proposals

David Brownell wrote,
> > > Nope, and not client-only implementations either! :)
> > 
> > No fair ... rationale please.
> Fair because I originally asked for different servers; I asked
> that question specifically to highlight the severe lack of 
> diversity in that binary protocol you chose as your counter-
> example.

OK, I misread the question. But then perhaps the real question
wasn't a very good one. DNS is a client-server protocol, so why
shouldn't diversity amongst the clients count?

> > > DNS is not an example of a "widely implemented" protocol; 
> > But that's simply not true.
> Your assertion doesn't make it become "not true" though.

Uh huh ...

> > How many HTTP servers can you name? How many proxies?
> Apache, Zeus, Tomcat, Squid, TUX2, Thttpd, Netscape Enterprise.

That's the low hanging fruit. For DNS I can manage,

  Bind, MS DNS, djbdns

just under half the number. I'm sure a clued up sysadmin could do
a lot better. If there isn't at least one (non-BIND) 
implementation for each reasonably recent network OS I'll eat my 

> There are hundreds more, but you probably knew that ...

Tu quoque ... saying it don't make it so. But you're quite right:
there are many more, just as there are many more DNS servers.

> and those are not comparable:  HTTP is a text based protocol, 
> DNS is a binary one.

HTTP is only a *partially* text based protocol.

> > The real killer isn't text vs. binary: it's who's in control 
> > of change.
> Change control is certainly an issue ... but it assumes that
> all vendors in the market are actually conforming to the spec!
> Doesn't matter what the paper spec says if it has no teeth,
> because the real spec is the Vendor X implementation.

I don't disagree ... but I don't see how this is supposed to
help differentiate between text and binary.

> And unfortunately few vendors nowadays have shown they really 
> care much about conformance (say, in the XML space) until 
> customers start dinging them on it. Maybe not even then, when 
> the effort gets too inconvenient.  So the easier it is for
> customers to detect and publicize such vendor bugs, the
> better the market serves customer (not vendor) needs.

Err ... well, I don't have any evidence to back this up, but I'd
be prepared to bet quite a lot that non-conformance, even in the
XML space, isn't typically detected by people evaluating behaviour
against a close reading of specs. It's detected when things fail
unexpectedly. I'd hazard a guess that failures in binary protocols 
tend to come to light at least as quickly as failures in text 
protocols. Probably quicker, because binary protocols tend to 
leave less slack.



Miles Sabin                               InterX
Internet Systems Architect                5/6 Glenthorne Mews
+44 (0)20 8817 4030                       London, W6 0LJ, England
msabin@interx.com                         http://www.interx.com/