Re: Deja vu Again

[Andy Bierman <abierman@cisco.com>]

At 03:50 PM 6/27/2002, Randy Presuhn wrote:
>Hi -
>
>> Message-Id: <5.1.0.14.2.20020627142559.02640828@fedex.cisco.com>
>> Date: Thu, 27 Jun 2002 14:54:20 -0700
>> To: Randy Presuhn <rpresuhn@dorothy.bmc.com>
>> From: Andy Bierman <abierman@cisco.com>
>> Subject: Re: Deja vu Again
>> Cc: xmlconf@ops.ietf.org
>...
>> >There are at least three different DTDs/Schemas that we could
>> >be talking about in xmlconf, and we need to decide which ones
>> >we're going to do:
>> >    - schema for the basic protocol operations
>> >    - payload metaschema
>> >    - schemas for managing particular gizmos
>> >
>> >I hope we're agreeing that it's the first two and not the
>> >third that we're talking about.
>> 
>> I'm not sure what a metaschema is.
>> If it means the payload will contain an opaque element like 
>>   <command>bunch of proprietary text</command> 
>> then I don't think we agree.  I would rather see something like:
>> 
>>   <command xmlns="http://www.acme.com/commands";>
>>      <acme-top-level-element>
>>          <acme-nested-element>
>>             bunch of proprietary text or maybe
>>             some more nested elements (parameters)
>>          </acme-nested-element>
>>      </acme-top-level-element>
>>   </command>
>...
>
>This is something I think we may need to permit, but
>should strongly discourage.

I suppose from a moral POV, a standards body should strongly
discourage any proprietary mechanisms, but I think the our
goal is "to do common things in a common way". Since not all
config is common, there is a practical need for proprietary content.
SNMP would not have even the moderate level of success it does 
today if we didn't provide for vendor MIBs.


>If we say anything at all about the payload part,
>I'd rather see something roughly like
>   ...
>   <instance-data>
>      <object-class typ="usmUserEntry" href="http://www.ietf.org/whatever";>
>      <instance-name>
>          <index typ=usmUserEngineID value="0x00000">
>          <index typ=usmUserName value="Andy">
>      </instance-name>
>      <attribute-list>
>          <attribute typ=usmUserSecurityName value="Bierman">
>          <attribute typ=usmUserPrivProtocol value="usmNoAuthProtocol">
>          ...
>      </attribute-list>
>   </instance-data>

I agree we should create structure for content derived from MIB objects,
and even start creating standard XML content (separate WG), but we should 
also support proprietary XML content.  I don't think we should mandate the
use of a standard template for this type of payload.


>where all the "typ" semantics can be resolved by looking in
>http://www.acme.com/classes (though, just as with WSDL
>and friends one would not normally do this at runtime!)
>
>I think each of these levels of encapsulation, especially
>the higher-level protocol stuff, should really probably
>be kept in line with the encapsulation notions in
>http://www.w3.org/TR/2002/WD-xmlp-reqs-20020626#N774 (Note
>that this document also raises the possibility of providing
>transaction support.)

Andy

> ------------------------------------------------------
> Randy Presuhn          BMC Software, Inc.  1-3141
> randy_presuhn@bmc.com  2141 North First Street
> Tel: +1 408 546-1006   San José, California 95131  USA
> ------------------------------------------------------
> My opinions and BMC's are independent variables.
> ------------------------------------------------------
>
>--
>to unsubscribe send a message to xmlconf-request@ops.ietf.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 xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>