[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt
Protocols (in the sense that I understand the draft to be directed at) are
about specifying specific exchanges of bits-on-the-wire to achieve some
desired goal of information exchange.
Bits on the wire are the common ground between protocol
participants. Interoperability requires that a receiving application
properly understands the bits-on-the-wire that are sent. Everything
eventually comes down to this. By using a higher level specification that
less directly constraints bits on the wire, I think there are two potential
(1) greater opportunity to get it wrong (ASN.1 had 3 or 4 different
possible wire formats, I think).
(2) the protocol implementer has to digest a greater volume of
documentation in order to correctly implement the protocol.
Against this, I see no real advantage for using an abstract format
specification for a protocol. What is the benefit of having an abstraction
(Interestingly, and this is off topic so I won't expand, I'm not sure that
XMLP falls into the same category, and I won't way that infoset based
specifications would not be appropriate for XMLP applications.)
At 03:10 PM 5/16/02 +0200, Jean-Jacques Moreau wrote:
Thanks for your comments, and sorry for the delay, I have been away and am
up with email.
I'd be curious as to the reasons for which you, Tim and Graham think it is
idea to use the XML Infoset for a protocol. I'd be happy if you could
reasonning further. I, for now, have seen this rather positively.
Maybe we should cc: dist-app in the future. The folks there would likely be
interested in that discussion.
Martin Duerst wrote:
> I agree with Graham. Regards, Martin.
> At 16:12 02/05/07 +0100, Graham Klyne wrote:
> >At 04:25 PM 5/7/02 +0200, Jean-Jacques Moreau wrote:
> >>What I am really saying is that we would be better off in the long run
> >>recommending XML Infoset over XML 1.0. Amongst other things, this
> >>serialization independence.
> >I can imagine many situations in which that is a real advantage, but
> >protocol specification isn't one of them ;-)
> >(I'll hazard that one of the problems with ASN.1 in protocol design was
> >the fact that the wire format wasn't obvious from the specification
> >Graham Klyne