[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Incomplete XML Draft
At 01:16 PM 6/25/02 , Peter Thompson wrote:
>Perhaps you should add a step 0: close evaluation of
>existing standards for possible re-use/adoption. You could
>do step 0 in conjunction with step 2, and move forward with
There is already a "phase 0" in the draft that is supposed to
include this type of evaluation. Suggestions about re-wording
are welcome, if it is unclear.
> Peter Thompson
> > -----Original Message-----
> > From: email@example.com [mailto:firstname.lastname@example.org]On
> > Behalf Of Ted Goddard
> > Sent: Tuesday, June 25, 2002 9:31 AM
> > To: Margaret Wasserman
> > Cc: Andy Bierman; email@example.com
> > Subject: Re: Incomplete XML Draft
> > On Tuesday, June 25, 2002, at 09:08 AM, Margaret Wasserman wrote:
> > > Do you have other ideas? Perhaps starting with the XML <--> MIB
> > > translation work? What would be the steps in that plan that eventually
> > > lead to a protocol?
> > Here's a possible interpretation of the phased approach:
> > 1. SOAP/WSDL definitions supporting SNMP semantics
> > (perhaps leaning more towards GetBulkRequest than GetNextRequest)
> > 2. XML encoding of MIB modeled data to be used in 1. and other
> > protocols.
> > 3. Extend the "SOAP API" from 1. to support desired semantics and
> > a richer (than 2.) XML encoding; define this encoding.
> > 4. Proceed with modeling work (XML schema definition?) that
> > takes advantage of 3.
> > (1. and 2. are actually needed at the same time, but maybe 1.
> > is easier to agree on quickly?)
> > I agree this is the risk:
> > > [Chen, Weijing] We wouldn't be interested, and may even oppose such
> > > approach. We already got N^2 interfaces problem, and don't need just
> > > another
> > > "standard" interface for the same old task.
> > Have we gained anything by step 2 above? A little bit: it should be
> > easier to implement a reliably manageable device, and it should be
> > possible for step 3 to be made up of many small "extension" steps
> > that add capability (for instance, if the device supports transactions,
> > and it sees one in the SOAP header, it should obey).
> > Is it even possible for us to avoid creating yet another interface to the
> > same old model as the first step? Isn't it necessary because
> > that's the smoothest way to get people to adopt the new standard?
> > (It's also the easiest way to be initially productive on the
> > new standard.)
> > Regards,
> > Ted.
> > --
> > to unsubscribe send a message to firstname.lastname@example.org with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://ops.ietf.org/lists/xmlconf/>
>to unsubscribe send a message to email@example.com with
>the word 'unsubscribe' in a single line as the message text body.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.