Re: XML and encoding (was Re: summary table of WWW9 agenda propos als)

Eric Prud'hommeaux wrote:
> 
> On Thu, Apr 20, 2000 at 01:49:45PM -0700, Sami Khoury wrote:
> > Thanks, Eric.
> >
> > I've cc'd the list on this go-round as we're all fine with taking this
> > exchange public.
> >
> > To summarize what is quoted below, the information on ICE listed in Eric's
> > protocol comparison's table was a bit dated, so Bruce mailed with updates,
> > which are below.  Notably, ICE is in fact deployed and the spec has actively
> > matured to a 1.1 version due out shortly.
> >
> > An open-source reference implementation written in java is also on the way
> > (again, real soon now).
> >
> > Eric, one question you raise below, about a protocol for serializing
> > arbitrary data structures and then performing an arbitrary function on them,
> > I am not clear on.  Could you restate this?
> 
> Sure - It's down around line 135. I'm leaving the rest of the
> conversation intact. Sorry about the amount of included text.
> 
> > -----Original Message-----
> > From: Eric Prud'hommeaux [mailto:eric@w3.org]
> > Sent: Wednesday, April 19, 2000 11:12 PM
> > To: Sami Khoury
> > Cc: 'bhunt@adobe.com'
> > Subject: Re: XML and encoding (was Re: summary table of WWW9 agenda
> > propos als)
> >
> >
> > I'd like to discuss this on xml-dist-app. Feel free to quote anything
> > I said on the list. I didn't send this reply to the list as I don't
> > want to publicize a conversation without mutual consent.
> >
> > On Tue, Apr 18, 2000 at 11:21:20AM -0700, Sami Khoury wrote:
> > > hi Eric-
> > >
> > > I noticed that the protocol matrix has not been changed to indicate the
> > > deployed status of ICE.  I have attached the message the my colleague on
> > the
> > > ICE Authoring Group, Bruce Hunt, sent to you to clear up many of the
> > > particulars of ICE in your table.
> > >
> > > Questions/comments appreciated.
> >
> > Content-Description: [ice-ag] ICE - Protocol Update.
> > > Message-ID: <38ECBBCE.66F99557@adobe.com>
> > > From: "V. Bruce Hunt" <bhunt@adobe.com>
> > > Reply-To: ice-ag@egroups.com
> > > To: eric@w3.org, ice-ag@egroups.com
> > > Subject: [ice-ag] ICE - Protocol Update.
> > > Date: Thu, 6 Apr 2000 09:31:10 -0700
> > > MIME-Version: 1.0
> > > X-Mailer: Internet Mail Service (5.5.2650.21)
> > > List-Unsubscribe: <mailto:ice-ag-unsubscribe@egroups.com>
> > > Content-Type: text/plain;
> > >     charset="iso-8859-1"
> > >
> > > I would like to give you an update on ICE for your table.
> > >
> > > ICE has been implemented by at least 4 vendors and it is deployed in
> > > multiple sites.  An open source reference version of ICE is
> > > under development by the ICE-AG with sponsorship from Adobe.
> >
> > updated
> >
> > If you give me a URL, I'll link it from the "deployed" work in the ICE
> > row.
> >
> > > Under your facets, ICE has the following facets:
> > >
> > > serialization - core capability.
> > >
> > > extensibility - ICE 1.0 has DTD extensibility defined.  ICE 1.1 defines
> > >                 extension negotiation.
> > >
> > > skinnyness - ICE 1.0 and later permits a trivial implementation of a
> > >              subscriber, syndicator and parameter negotiation.
> > >
> > > protocol - core capability
> > >
> > > interface discovery - core capability.  ICE uses parameter negotiation to
> > >              enhance this process.
> > >
> > > transactions (ACIDity).  ICE carefully defines requests and responses so that
> > >              recovery and a known state is always possible on both sides;
> > >              regardless of error condition or response.  Further, ICE
> > >              provides collection management that recovers the state of
> > >              a collection for any subscriber and brings the collection
> > >              up to the current state.
> > >  remote procedure.  ICE 1.1 provides agent defined parameters on a per subscription
> > >               basis or on a per relationship basis; including the ability for
> > >              one party to direct the invocation of an identified procedure
> > >              by the other.
> > >
> > > business process.  ICE 1.1 supports almost any variant on content delivery work flow;
> > >              It provides negotiated delivery policies.  ICE supports content
> > >              delivery on both a replacement basis or a cumulative basis or
> > >              any variation in between.  ICE supports content use requirements
> > >              and permits those and any other parameters to be negotiated.
> > >              ICE supports direct delivery; encrypted delivery; and referenced,
> > >              access and time policy controlled delivery.  This means that ICE
> > >              can manage the delivery of real-time high-bandwidth media and
> > >              control access to it.
> > >
> > > security.  ICE 1.1 permits packaged content to be in any form, including encryption.
> > >            ICE provides multiple types of access control for referenced media and
> > >            it is designed to be run under SSL.
> > >
> > > routing.     ICE 1.0 and later provide support for payload redirect on both a
> > >              permanent and temporary basis.
> >
> > One problem with discussing ICE in this context is that, as far as I
> > understood from a couple hours on the spec, it's not a protocol for
> > serializing arbitrary data structures and performing an arbitrary
> > function on them.
> 
> I may be mistaken here, but isn't ICE a protocol for negotiating the
> transport of packaged data between a syndicate and a subscriber? 
Yes, it is a protocol for managing the delivery of content between a
content
supplier (Syndicator) and a content receiver (subscriber).  
ICE describes the entire content exchange using "collections".  A
collection
represents the entire content interchange.  ICE tranports content in
units
called packages.  These packages are pieces of the entire collection.  
ICE uses the packaging technique to partition content deliveries into
managable chunks
for sending through the delivery channel.  An application
processor controls the size, format and content in the packages that
ICE delivers. 

A
> general prob we are solve here involves the serializing of arbitrary
> data to ship to an agent which then uses the protocol to deserialize
> the data and dispatch to some RPC handler.

I'm not clear on what the difference between "Packaged" data and
"serializing of
arbitrary data" is.  If by "serializing" you mean the act of
transforming 
data into a form desirable for transport; then "packaging" and
"serializing" 
have similar meanings.  ICE's packaging technique permits any data of
any format
to be inside a package (also data can be referenced from within the
package). 
I think this matches your "arbitrary data" notion.  ICE requires,
however, that 
the data be contained in an XML wrapper and thus requires
the serialization of the internal data to be compatible with XML.  One
way
to accomplish this is to encode (transform) incompatible data into a
base64 encoding.
ICE uses the term "application processor" to refer to the "agent" that
provides
the application level intelligence that drives the protocol.  In ICE,
content received
by a subscriber would be unpackaged, transformed (e.g. deserialized) and
handed to
the application processor for further processing.  The data is clearly
described
according to it's place in the collection (and any other identifiers
inherant in the
data) so the application processor is free
to invoke any semantic processing on the data that it chooses based on
it's
collection identification or other identification.  This of course
includes invoking
some RPC handler.   If you are saying that ICE doesn't formalize the
rules for
application processor use of the data you are completely correct.  We
took the
philosophical tack of carefully defining the protocol from application
processor
through sending entity (Syndicator or Subscriber), delivery channel,
receiving entity
(Syndicator or Subscriber) to application processor and specifically did
NOT limit
an application processor's use of the data.
> 
> The problem with saying that ICE has something like interface
> discovery is that it doesn't make it available to the sending and
> recieving applications. 
The ICE protocol (in 1.1 ) delivers the parameters under negotiation and
hence
all interface information to the associated application processors on
both the
syndicator and subscriber sides.  I think that this "makes the
interface" available to the sending and receiving applications.  The big
change in 1.1 is that additional parameters, defined by application
processors and not ICE may be negotiated.

That is, if I create a tax preparer server,
> some developer wouldn't use ICE to query the interface to my server
> and create a VB object to talk to it.

Well, we think that they might.  It would happen as follows.  The Tax
Preparer server
constructs a catalog of ICE offers.  A catalog is simply a collection of
ICE offers that
the server is willing to negotiate over with the specific developer
(i.e. client).  The offers define the various interfaces that the server
is prepared to support.  In detail, there might be an offer for the
"Business Tax Preparation Service", an offer for the
"Complex Estate Tax Preperation Service", "the Homeowner's Tax
Preparation Service",
etc.  Each offer contains a set of parameters and legal
values for the parameters.  These parameters are defined independent of
the ICE protocol,
ICE simply manages the offer collection and supervises parameter
resolution through it's
negotiation mechanism.  This means that these offer parameters may
define the VB methods
and the values for the parameters to those methods.  To be clear, ICE
has nothing to
say about the meanings of the methods except as to the range of legal
values and
the supervision of obtaining an agreement to use them.  Thus, the values
are owned
and controlled by the application processors (i.e. agents).  It is thus
possible
for consenting application processors to interpret the parameters as the
defining
values for the creation of a VB object to talk to the Tax preparer
server.  The negotiation mechanism is simply a means for there to be
general agreement about 
the offer prior to commencement of data interchange.

I would point out that we have formalized many of the parameters that
control the delivery and interchange process so that reliable
interchange can take place.  These
parameters are negotiable as well; but they are used by the ICE protocol
to
opportunely deliver data according to the general framework provided by
the
subscription.  We recognized that the same mechanism that works for ICE
delivery
parameter negotiation can work for arbitrary parameter resolution
between two
parties.  While this requires both sides of an interchange to understand
the
parameters of the interchange, it also provides a means for the sides to
discover 
mutually understood parameters and adjust their operation accordingly. 
We think
this may have considerable merit because it suggests a mechanism that
permits
"agents" to arrive at mutually beneficial parameters for
inter-operation; including
shared semantic invocation.

/Bruce



> 
> --
> -eric
> 
> (eric@w3.org)

Received on Thursday, 20 April 2000 18:58:38 UTC