RE: Removal (Time for XMail?)

In ICE we support both PBR and PBV models. I'll summarize here, and direct
you to
http://www.icestandard.org/spec/SPEC-ICE1.01-20000511.html#section5.2.2.2
for more detail.

Interestingly, while PBV is conceptually quite a bit simpler, PBR has been
the first encoding method implemented by pretty much every ICE
implementation that I am aware of. I suspect that this is because, given
modern programming libraries that make network communication trivially easy,
it's easier to retrieve a file from a URL than it is to base64 decode a
stream from an XML message.

PBR; People are tending to use pass-by-reference (ice-item-ref) when
transmitted web assets, in particular large binary assets such as images,
video and audio, because it's easier/more efficient than inline encoding. In
effect, they're using ICE to pass metadata and the notification about the
availability of the resource, and then either HTTP or FTP to actually
transmit the asset. In ICE, PBR is intended for transmitting assets that are
large and change value relatively infrequently.

One practical issue that drove us towards supporting PBR is in transmitting
rich content across unreliable connections. While in principle this should
not be an issue, in practice it can be difficult to successfully HTTP
transmit a single extremely large package containing both all assets, making
it preferable to transmit an ICE "control file" over HTTP, followed by a
series of individual assets sent by (for example) FTP. Imagine, for example,
sending 10 GB of video files over a congested T1.

In order to manage assets transmitted out of band, we must address the
issues of how to retrieve the asset, when it is legitimate to do so, and
access control.

- Where: the asset is encoded with a 'url' that provides the method and
address of the asset. (Pretty easy)
- When: the ice-item-ref can contain an ice-access-window that allows the
sender to define the valid period during which the asset must be retrieved.
This can be used to declare that the sender only guarantees that the asset
will be available for 24 hours, for example, so that receivers can retrieve
it before the server's disk space is reclaimed for new assets. If
ice-access-window is not specified, the asset is assumed to be available at
any time. Of course, waiting for a month to retrieve a file updated hourly
is likely to be unsuccessful, even if the sender didn't explicitly say so.
- Access Control: the ice-item-ref can contain an ice-access-control that
provides the username, password, cookie, etc., required to retrieve the
asset. If ice-access-control is not specified, the asset is assumed to be
available with no authentication.

If an asset passed by reference changes value occasionally, it is not
suffient to update the copy on the source server; the item's meta-data must
be retransmitted via ICE so that the subscribers know to retrieve the
updated file.

If an asset changes value constantly, the ice-item-ref grants the right to
access the asset on an ongoing basis. For example, web-cam images could be
syndicated by sending ice-item-ref's to subscribers allowing them to
retrieve the images whenever they care to. There's no value in sending
ice-updates to all subscribers several times a second notifying them of the
availability of new video frames, so instead the ice-update would only be
transmitted when the address if the web-cam changes.

PBV: People are tending to use pass-by-value (ice-item) for more traditional
text-like data. That includes text data (e.g. book title, price, ISBN
number, part number, quantity in inventory, article text) and also
XML-encoded industry specific data (e.g. NewsML encoded news stories
transmitted over ICE). For binary data encoded in-line, ICE specifies base64
encoding.

-----Original Message-----
From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
Behalf Of John Evdemon
Sent: Sunday, October 01, 2000 9:30 PM
To: 'orchard@pacificspirit.com'; 'aswartz@swartzfam.com';
'xml-dist-app@w3.org'
Subject: RE: Removal (Time for XMail?)


I agree with David's observations regarding PBV and PBR.  PBR introduces
significant design challenges, especially in terms of performance.   PBV can
be enabled via a simple CDATA/base64 encoding.


-----Original Message-----
From: David Orchard <orchard@pacificspirit.com>
To: 'Aaron Swartz' <aswartz@swartzfam.com>; 'XML-DIST-APP'
<xml-dist-app@w3.org>
Sent: Fri Sep 29 18:52:49 2000
Subject: RE: Removal (Time for XMail?)

Ah yes, the advantages and disadvantages of pass by value versus pass by
reference :-)

I would think that pbr makes it harder to keep a distributed system in a
state close to coherency.  Further, there are significant performance,
reliability and scalability issues.

Seems like another interesting requirement to debate, whether or not to
explicitly support remote references.  Obviously references are supported
implicitly via URIs, but should the xml protocol elaborate on this.

I think that version 1.0 of a protocol should do the simplest case first,
that is pass by value.

Cheers,
Dave


-----Original Message-----
From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
Behalf Of Aaron Swartz
Sent: Friday, September 29, 2000 2:07 PM
To: XML-DIST-APP
Subject: Re: Removal (Time for XMail?)


Simon St.Laurent <simonstl@simonstl.com> wrote:

> Another benefit of using a request-response approach for email that I
> forgot to mention is that it might give the intended recipient an
> opportunity to say 'unsubscribe me from all future messages' - which is
> what got this thread started in the first place.

Not to mention the ability for the sender to update messages after they've
been sent. How many times have you wanted "unsend" a message? Can't with
SMTP, but if we just emailed URLs back and forth, you could update the
content at the URL before the person you sent it to has downloaded it. This
is, of course, both a benefit and a drawback.

I think this is definitely an interesting area for XML work, and relates to
a lot of stuff I've been working on. Anyone have pointers to people who are
already working on this kind of thing? I'm interested.

--
        Aaron Swartz         |"This information is top security.
<http://swartzfam.com/aaron/>|     When you have read it, destroy yourself."
  <http://www.theinfo.org/>  |             - Marshall McLuhan

Received on Sunday, 1 October 2000 22:27:06 UTC