Subject: Re: New Version Notification for draft-leiba-extended-doc-shepherd-00.txt

From: Barry Leiba <[email-masked]>
Date: Thu, 2 Aug 2012 02:01:03 -0400

I've posted my thoughts on starting document shepherding at the time a
document first starts its life in a working group, and on the tasks a
shepherd might perform at each stage in the document's life.  I intend
to pursue having this published as an Informational document, not a
BCP, reflecting my personal opinion.  That said, I'm interested in
comments, and might make changes accordingly.

Barry

> Filename:        draft-leiba-extended-doc-shepherd
> Revision:        00
> Title:           Document Shepherding Throughout a Document's Lifecycle
> Creation date:   2012-08-02
> WG ID:           Individual Submission
> Number of pages: 24
> URL:
> http://www.ietf.org/internet-drafts/draft-leiba-extended-doc-shepherd-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-leiba-extended-doc-shepherd
> Htmlized:
> http://tools.ietf.org/html/draft-leiba-extended-doc-shepherd-00
>
>
> Abstract:
>    RFC 4858 talks about "Document Shepherding from Working Group Last
>    Call to Publication".  There's a significant part of a document's
>    life that happens before working group last call, starting, really,
>    at the time a working group begins discussing a version of the idea
>    that's been posted as an individual draft.  It seems reasonable and
>    helpful to begin shepherding when there's a call for adoption as a
>    working group document, and this document gives one Area Director's
>    view of how that extended shepherding function might work, and what
>    tasks might be involved throughout the document's lifecycle.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 2 Aug 2012 09:02:42 -0700

> comments, and might make changes accordingly.
If this piques anyone's interest, we will be trying what Barry's suggesting
in APPSAWG.  Ask us in a few months how well it's working.

-MSK

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 02 Aug 2012 18:25:03 +0200

All,

IETF documents have number of mandatory sections .. IANA Actions, 
Security Considerations, Refs, etc ...

Does anyone have a good reason why any new protocol definition or 
enhancement does not have a build in mandatory "XML schema" section 
which would allow to actually use such standards based enhancement in 
vendor agnostic way ?

There is a lot of talk about reinventing APIs, building network wide OS 
platform, delivering SDNs (whatever it means at any point of time for 
one) ... but how about we start with something very basic yet IMHO 
necessary to slowly begin thinking of network as one plane.

I understand that historically we had/still have SNMP however I have 
never seen this being mandatory section of any standards track document. 
Usually SNMP comes 5 years behind (if at all) making it obsolete by design.

NETCONF is great and very flexible communication channel for 
provisioning. However it is sufficient to just look at number of ops 
lists to see that those who tried to use it quickly abandoned their 
efforts due to complete lack of XML schema from each vendor they happen 
to use or complete mismatch of vendor to vendor XML interpretation.

And while perhaps this is obvious I do not think that any new single 
effort will address this. This has to be an atomic and integral part of 
each WG's document.

Looking forward for insightful comments ...

Best,
R.

---

From: Randy Bush <[email-masked]>
Date: Thu, 02 Aug 2012 09:31:33 -0700

hi robert

> which would allow to actually use such standards based enhancement in 

xml is just a way to package the incompatibilities.  just as mime is a
way to codify incompatibility.

randy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 2 Aug 2012 18:59:03 +0200

Hi,

The OPSAWG/OPSAREA open meeting this afternoon has an item on the agenda
concerning the revision of RFC1052 and discussing a new architecture for
management protocols. 

My personal take is that no one protocol, or one data modeling language
can match the operational requirements to configure and manage the wide
and wider range of hosts, routers and other network devices that are
used to implement IP networks and protocols. We should be talking
nowadays about a toolset rather than one tool that fits all. However,
this is a discussion that just starts. 

Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Robert Raszuk
> Sent: Thursday, August 02, 2012 7:25 PM
> Cc: [email-masked]
> Subject: Basic ietf process question ...
> 
> All,
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 02 Aug 2012 19:12:21 +0200

Hi Dan,

 > We should be talking
 > nowadays about a toolset rather than one tool that fits all.

Just to clarify what I asked about .. I am not looking for a single tool 
or single protocol to be used to configure everything.

I am asking for small building block like xml schema (or something 
similar) to be part of each new IETF proposal or protocol change. IMHO 
only that can allow any further more fancy abstractions and tools to be 
build and used in practice.

Best regards,
R.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 2 Aug 2012 19:16:20 +0200

Yes. The question is whether a basic information model written in XML can be a useful starting point (trying to interpret the proposal made by Robert). 

Dan

> From: Andy Bierman [mailto:[email-masked]]
> Sent: Thursday, August 02, 2012 8:14 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [OPSAWG] Basic ietf process question ...
> 
> On Thu, Aug 2, 2012 at 9:59 AM, Romascanu, Dan (Dan)
> <[email-masked]> wrote:
> > Hi,
> >
> > The OPSAWG/OPSAREA open meeting this afternoon has an item on the
> > agenda concerning the revision of RFC1052 and discussing a new
> > architecture for management protocols.
> >
> >
> > My personal take is that no one protocol, or one data modeling
> > language can match the operational requirements to configure and
> > manage the wide and wider range of hosts, routers and other network
> > devices that are used to implement IP networks and protocols. We
> > should be talking nowadays about a toolset rather than one tool that
> > fits all. However, this is a discussion that just starts.
> 
> NMS developers need to spend too many resources on translating naming
> and other data-modeling specific details so they can be usable within
> the application.  So if 1 data modeling language is not used, then
> deterministic, loss-less, round-trip translation between data modeling
> languages is needed.  Multiple protocols are not the problem --
> incompatible data from multiple protocols is the problem.
> 
> >
> > Regards,
> >
> > Dan
> >
> 
> Andy
> 
> >
> >
> >
> > _______________________________________________
> > OPSAWG mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/opsawg

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 2 Aug 2012 10:18:36 -0700

I am discussing this very topic in the Ops meeting today at 3. Please come by to discuss.

	--Tom

On Aug 2, 2012:9:25 AM, at 9:25 AM, Robert Raszuk <[email-masked]> wrote:

> All,
> 
> IETF documents have number of mandatory sections .. IANA Actions, Security Considerations, Refs, etc ...
> 
> Does anyone have a good reason why any new protocol definition or enhancement does not have a build in mandatory "XML schema" section which would allow to actually use such standards based enhancement in vendor agnostic way ?
> 
> There is a lot of talk about reinventing APIs, building network wide OS platform, delivering SDNs (whatever it means at any point of time for one) ... but how about we start with something very basic yet IMHO necessary to slowly begin thinking of network as one plane.
> 
> I understand that historically we had/still have SNMP however I have never seen this being mandatory section of any standards track document. Usually SNMP comes 5 years behind (if at all) making it obsolete by design.
> 
> NETCONF is great and very flexible communication channel for provisioning. However it is sufficient to just look at number of ops lists to see that those who tried to use it quickly abandoned their efforts due to complete lack of XML schema from each vendor they happen to use or complete mismatch of vendor to vendor XML interpretation.
> 
> And while perhaps this is obvious I do not think that any new single effort will address this. This has to be an atomic and integral part of each WG's document.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Aug 2012 19:11:19 +0100

I think anyone with intimate experience of the Web Services standards
experiment (trying to use XML as if it was a Turing machine) would have
extreme doubts about any proposal to impose such a requirement.

It was not for no reason that many people came to refer to the Web
Services family of standards as "WS-splat". The words "small" and
"xml schema" don't really belong together,

Regards
   Brian Carpenter

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 02 Aug 2012 20:17:30 +0200

Hi Brian,

Perhaps we understand a different thing by "xml schema" As example what 
I had in mind when asking this question was the example from "Appendix 
A" of http://tools.ietf.org/html/draft-marques-l3vpn-schema-00 where 
while perhaps not yet complete it does provide decent representation of 
one of the popular service today.

That's what I had mind asking why such appendix isn't a mandatory part 
of each new protocol extension.

It has very little to do with Web Services you may be referring to.

Many thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 02 Aug 2012 23:50:06 +0200

Hi Joe,

Many thx for your comments.

Perhaps my intentions were not very well described. Personally I am not 
that much stuck on plain XML schema .. it could be expressed in any 
language IETF would choose to use. The point is not how to do it .. but 
to do it at the moment of bringing new protocol extension.

However for years the same functionality is completely different to 
configure using one vendor from other vendor (leave alone that even 
within single vendor there are complete different UIs to provision the 
same knob).

If anyone is even remotely serious about some form of common network OS 
IMHO the first step is to create unified configuration abstraction. The 
xml schema for each proto extension would be just a standard based API 
for configuration input.

Keep in mind that today routers are configured by scripts from central 
management clusters where there are tons of templates which in fact 
completely differ from vendor to vendor and their maintenance and 
keeping them up to date is a real pain.

Regards,
R.

> On 8/2/12 9:25 AM, "Robert Raszuk" <[email-masked]> wrote:
>
> For docs that use XML, requiring some form of schema makes sense.
> However, what we're finding at the application layer is that often times
> using JSON (see RFC 4627) ends up with better interoperability more
> quickly than using XML, except in the case of human-readable content like
> marked-up text.  See RFC 6120, Appendix A (http://goo.gl/CBv8G) for
> another example.
>
> For those that insist on XML, RelaxNG (http://goo.gl/MYnB1) is another
> language you can use to describe your XML, which is a little easier to
> learn than XSD.
>
> However, for implementors, if you start with the schema and blindly use it
> for conformance checking of real-world traffic, you are likely to have
> both performance and extensibility issues in practice.
>
> If folks at other layers in the stack would like input from Apps folks,
> I'm sure that we would be happy to share our lessons learned.  Join
> apps-discuss (http://goo.gl/0Otjv) and ask for help.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Aug 2012 07:58:03 +0100

> one of the popular service today.

There are certainly cases where systematic metadata are useful; I can't judge
whether VPN configuration is one of them, but I can easily believe it. In such
a case, I suppose XML is as good a tool as ASN.1, ABNF or whatever else
you might choose.

> of each new protocol extension.

That's an enormous leap that I just don't understand. Most protocols don't
need that sort of configuration complexity.

> It has very little to do with Web Services you may be referring to.

Yes it does. It's exactly because of a doctrinaire approach that whatever
it is, it should be represented by an XML schema, that WS-splat became
such a horribly complex matter.

Again: no problem with creating XML schemata where they are useful. But
making them mandatory would be just as bad as making MIB modules mandatory,
IMHO.

    Brian

>>>> agenda

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 03 Aug 2012 09:22:10 +0200

Hello Brian,

> need that sort of configuration complexity.

Hmmmm I am of the opinion that most protocols requires configuration. I 
am also of the opinion that each vendor chooses an original way to 
configure their network elements.

Therefor if you do not define up front a standard based of configuring 
given routing protocol you will end up with exactly what we have today 
.. zoo of various different CLI commands to enable the exact same 
protocol across more then one vendor box.

Are you saying that this is ok ?

Or are you saying that there is simpler way to enable netconf based 
unified way to configure protocols and services on your network other 
then providing per component "xml schema" with subsequent schema 
extensions as part of IETF standardization process ?

To make it a bit more explicit ... do you really need to study 5 user 
manuals or google 5 times to enable IGP or BGP or even configure NTP 
across 5 different router OS running in your network ???

 > Again: no problem with creating XML schemata where they are useful.
 > But making them mandatory would be just as bad as making MIB modules
 > mandatory, IMHO.

Aha .. so you are saying that MIBs are not mandatory .... Very 
interesting. So I guess SSH to the routers and box by box cli 
provisioning is here to stay for a while I think :(

Best regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 03 Aug 2012 16:31:42 +0200

Hi Juergen,

Many thx for the great suggestion !

However perhaps you are much more knowledgeable in that area and could 
recommend which model fit the best the requirement to standardize 
configuration of any new protocol or protocol extension at least in the 
space of routing and routing protocols or services being based on them ?

As you know the current IRS framework driven by junisco is trying to 
come with common API to the routing system agreed across vendors. This 
is great as attempts never happened in the past.

But if we are at this phase I think creating a network elements 
abstraction layer and be able to configure/monitor any protocol and 
service at the unified way is one of the building blocks we should start 
with. And of course I think this is very clear to everyone if it is not 
made mandatory in each draft as new section or appendix it is just not 
going to happen in practice.

Best regards,
R.

> On Fri, Aug 03, 2012 at 09:22:10AM +0200, Robert Raszuk wrote:
>>
> Robert,
> you may want to take a closer look at the data models currently being
> defined in the NETMOD working group. Please review them and send any
> comments.
>
> /js
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 2 Aug 2012 10:13:44 -0700

> this is a discussion that just starts.

NMS developers need to spend too many resources on translating
naming and other data-modeling specific details so they can be
usable within the application.  So if 1 data modeling language
is not used, then deterministic, loss-less, round-trip translation
between data modeling languages is needed.  Multiple
protocols are not the problem -- incompatible data from multiple
protocols is the problem.

Andy

---

From: David Harrington <[email-masked]>
Date: Thu, 02 Aug 2012 13:19:55 -0400

+1

--
David Harrington
[email-masked]
+1-603-828-1401

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 2 Aug 2012 21:17:39 +0000

-- 
Joe Hildebrand

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 Aug 2012 15:29:45 +0200

Robert,

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 Aug 2012 17:31:00 +0200

On Fri, Aug 03, 2012 at 04:31:42PM +0200, Robert Raszuk wrote:
> service at the unified way is one of the building blocks we should
> start with. And of course I think this is very clear to everyone if
> it is not made mandatory in each draft as new section or appendix it
> is just not going to happen in practice.
> 

Writing data models that are implementable on multiple platforms is
non trivial. We started working on your "building block" but it will
take time. And after all, a data model is only worth something if it
gets implemented.  A mandatory section does not help much with all of
this. What helps is people who commit time to work on it, who review
stuff, producing good and hopefully widely implementable models.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 3 Aug 2012 09:24:03 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Romascanu, Dan (Dan)" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Thursday, August 02, 2012 10:13 AM
...
> protocols is the problem.
...

Picking a single language or set of round-trip translatable languages
also isn't enough.  Its a fact of life that vendors will produce
models and implementations that are slightly, or even radically different.
The differences aren't necessarily even intentional, but nonetheless
introduce the need to talk about "similar" models and "operationally
equivalent" configurations, where the transformations needed to go
from what will do the job on one piece of equipment to what will
work on another may be substantial.  (From an implementation perspective
it might be better to think in terms of transformations necessary to go
from a common model of desired operational characteristics to the
dial tweaks and button pokes necessary to get a device to do the right
thing.)  Since great minds often think alike, even in the absence
of standards, there is not necessarily a formal "derived from" or
"subclass" or "common aspect" relationship between the definitions.
This may be an obvious use case for XSLT, but as far as I know nothing
has been done about *standardizing* such usage, other than discussions at the
IAB workshop oh-so-many years ago, and some ISO/ITU discussions in
the 1990s about eventual applications of the General Relationship
Model and the management domain/policy stuff in GDMO land.

Randy

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 3 Aug 2012 12:47:44 -0500

> I think anyone with intimate experience of the Web Services standards

I do, unfortunately.

Specifically: contributor to SOAP, WS-Addressing, WS-Policy, MTOM, lead editor of the WS-I Basic Profile, etc. (ad nauseum).

+1

XML Schema is grossly over-engineered for its purpose; being the subject of requirements from not only the document markup field, but also databases and object models, it's a twisted monstrosity that tries to do many things, and fails at most.

Specifically, it's very common for people to try to use schema to inform "binding" tools into specific languages. However, the underlying metamodel of XML, the Infoset, is both complex and a poor fit for most languages, so bindings take "shortcuts" and expose a profile of XML's range of expression, encouraging some patterns of use, while discouraging (or disallowing) others. Since the bindings often make different decisions (based upon the language of use), interoperability is difficult (sometimes, impossible).

Furthermore, designing a schema that is extensible is incredibly convoluted in XML Schema 1.0. Schema 1.1 was designed to address this failure, but it hasn't been broadly adopted; most people I know in the field consider it a failure. 

What surprises me and many others is that people are still using it and promoting it, when it's well-understood by almost EVERYONE who was involved in using XML for protocols in the past ten years agrees that it's a mistake.

Cheers,

--
Mark Nottingham
http://www.mnot.net/

---

From: [email-masked] (Martin Rex)
Date: Fri, 3 Aug 2012 21:29:27 +0200 (CEST)

> to use or complete mismatch of vendor to vendor XML interpretation.

There seems to be a network management protocol in active use
for CPE networking gear:

  http://en.wikipedia.org/wiki/TR-069

that is based on SOAP (ie WebService using XML).

-Martin

---

From: [email-masked]
Date: Fri, 03 Aug 2012 15:59:04 -0700 (PDT)

> XML Schema is grossly over-engineered for its purpose; being the subject of
> requirements from not only the document markup field, but also databases and
> object models, it's a twisted monstrosity that tries to do many things, and
> fails at most.

Agreed, and I would add that it is seriously lacking in flexibility. (I would
like to have words with whoever thought the "unique particle attribution rule"
was a good idea.)

That said, there's a timing issue in play here. A variety of tools supporting
other validation systems, e.g., RelaxNG or Schematron are available now, but a
few years back alternatives to XML Schema were much more limited. Despite our
dislike we've used XML Schema in a couple of places for precisely this reason.

> Specifically, it's very common for people to try to use schema to inform
> "binding" tools into specific languages. However, the underlying metamodel of
> XML, the Infoset, is both complex and a poor fit for most languages, so
> bindings take "shortcuts" and expose a profile of XML's range of expression,
> encouraging some patterns of use, while discouraging (or disallowing) others.
> Since the bindings often make different decisions (based upon the language of
> use), interoperability is difficult (sometimes, impossible).

It very much depends on what you're doing and how you're doing it. If what
you want is for your data to manifest directly as a data structure, XML is
a lousy fit for that for a bunch of different reasons. Json is the clear choice
in such cases. But there are other uses where the more complex Infoset of
XML can be an asset.

Really, it's all about how you use the available tools.

> Furthermore, designing a schema that is extensible is incredibly convoluted
> in XML Schema 1.0. Schema 1.1 was designed to address this failure, but it
> hasn't been broadly adopted; most people I know in the field consider it a
> failure.

Yes, XML Schema makes this a lot harder to do than it should be, but in a lot
of designs I've seen it also has to do with how XML is actually used. A bad
design is a bad design, regardless of what schema language you use.

> What surprises me and many others is that people are still using it and
> promoting it, when it's well-understood by almost EVERYONE who was involved in
> using XML for protocols in the past ten years agrees that it's a mistake.

See above. I certainly wouldn't use XML Schema for anything new, but there's
a lot of legacy stuff out there.

				Ned

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 3 Aug 2012 19:50:21 -0500

> in such cases. But there are other uses where the more complex Infoset of

Very much; when it becomes a "document" (e.g., mixed markup), XML is a much better choice.

> a lot of legacy stuff out there.

That's the rub, isn't it?

--
Mark Nottingham
http://www.mnot.net/

---

From: [email-masked]
Date: Fri, 03 Aug 2012 18:09:47 -0700 (PDT)

> Very much; when it becomes a "document" (e.g., mixed markup), XML is a much

The other interesting case is where large amounts of data arrive in a stream.
SAX and SAX-like libraries makes this easy to implement with XML. I hope
there's an equivalent for Json; if not there needs to be.

> That's the rub, isn't it?

Yeah, and it sure is rubbing me the wrong way every time I look at our usage.
I know it was the right choice at the time, and now that it's done it's not
cost effective to change unless we need additional capabilities, but that
all so ... unsatisfying.

				Ned

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 4 Aug 2012 10:52:37 -0500

> there's an equivalent for Json; if not there needs to be.

Funny you mention that, I was just looking into that yesterday.

This seems to be in the front running:
  http://lloyd.github.com/yajl/

Cheers,

--
Mark Nottingham
http://www.mnot.net/

---

From: Martin Thomson <[email-masked]>
Date: Sat, 4 Aug 2012 09:26:54 -0700

>   http://lloyd.github.com/yajl/

The conclusion that I reached on this subject was that both XML and
JSON are poorly suited to streaming use cases for large datasets.  Try
implementing XMPP "framing" some time and tell me afterwards how much
you love SAX.

I prefer CSV or lots of small objects.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 4 Aug 2012 12:01:41 -0500

Probably digressing here (from our previous digression), but I find a hybrid API best. E.g., the python pulldom API, which is event driven until you find a node you're interested in, whereupon it can give you an object. 

Should be even easier with json, since it can just give back a data structure. 

Sent from my iPhone

---

From: Hector Santos <[email-masked]>
Date: Sat, 04 Aug 2012 13:04:15 -0400

> I prefer CSV or lots of small objects.

+1, too much overhead, cries/needs for compiling and p-coding it comes 
in.  But it depends much on how much dynamic vs static data is 
involved in the application.  For on the fly dynamic processing, too 
much overhead and relaxing on strong syntaxing (i.e. allow for 
errors). Of course, thats getting cheaper these day.  One other issue, 
at least for us, to make it more useful, more layers will be needed. 
So this library may be great, but not for the layman to use. It will 
good for the systems level people to write the high layers tools (for 
application developers) perhaps.  That has been the dearth for many 
vendors who have to interface with different flavored APIs.  Single 
sourcing it is a strategic benefit for many which means having to 
write/port/convert the libraries into other languages.

Regarding the XML related question for IETF processing, well, the way 
I look at it is document writing should not involved requiring XML 
knowledge. Its already complex and it gets even more complex with XML 
Schemas, so its the last thing I want to spend time learning, 
relearning or refreshing on on.   But for usage as a tools to help 
IETF processors, management, perhaps, in what is essentially a static 
application it probably ok and keeps up with a direction in using XML 
for all things static (and even dynamic, not always the best result). 
It can help with I/O Communications, perhaps decentralization areas, a 
bunch of things once a common format is used.  But lets not require 
document writers having to know XML and XML schema just to be involved 
and productive with the IETF.

PS: For XML processing, we use the super light weight PUGXML C/C++ 
code in many areas

http://www.codeproject.com/Articles/3502/PugXML-A-Small-Pugnacious-XML-Parser

For JSON, well, thus far, we only needed it for web clients and 
javascript applets, and javascript is naturally JSON.  For the server 
side, I am probably going to relook at V8 again (googles stuff) which 
is also used for Chrome.

http://en.wikipedia.org/wiki/V8_(JavaScript_engine)

The nice thing I felt was the ability to built on top of it, new 
layers, language independent imports and more importantly, JIT "Just 
in time" pcode compiling/processing which is how Chrome gets its 
Javascripting speed from.

-- 
HLS

---

From: [email-masked]
Date: Sat, 04 Aug 2012 11:54:39 -0700 (PDT)

>   http://lloyd.github.com/yajl/

This looks promising. Thanks for the pointer.

				Ned

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 4 Aug 2012 18:32:01 -0500

Forwarding a couple more:
  http://wiki.fasterxml.com/JacksonHome
  http://argo.sourceforge.net/

Cheers,

--
Mark Nottingham
http://www.mnot.net/

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Sat, 4 Aug 2012 21:34:59 -0400

> From: Mark Nottingham [[email-masked]]
> 
> What surprises me and many others is that people are still using it
> and promoting it, when it's well-understood by almost EVERYONE who was
> involved in using XML for protocols in the past ten years agrees that
> it's a mistake.

It sounds to me like what is needed is some sort of "best common
practices" document regarding data aggregation and encoding, or even
perhaps an IETF Sunday tutorial.  Lots of people who are never going
to become experts in the field need to make good choices when
designing protocols...

Dale

---

From: Tim Bray <[email-masked]>
Date: Sat, 4 Aug 2012 20:06:05 -0700

I gave such a Sunday tutorial at IETF70.  The slides are here
(somewhat dated, but still useful I’d say):
http://www.tbray.org/tmp/IETF70.pdf

 -Tim