[Standards] UPDATED: XEP-0231 (Data Element)

[Pavel Simerda]

On Tue, 05 Aug 2008 23:28:16 -0500
XMPP Extensions Editor <editor at xmpp.org> wrote:

> Version 0.4 of XEP-0231 (Data Element) has been released.
> 
> Abstract: This specification defines an XMPP protocol extension for
> including small bits of binary data in an XML stanza.
> 
> Changelog: Generalized text regarding inclusion of parameters in type
> attribute per RFC 2045; added max-age attribute, matching semantics
> from RFC 2965; added section on caching of data; more clearly
> specified generation of Content-ID. (psa)
> 
> Diff: http://is.gd/1gmU

Good Job. Thanks for including me in the acknowledgements.

May I have still some comments to the letter of the XEP?

* 3. Caching of Data

> As a hint regarding the suggested period for caching the data, the
> sending party SHOULD include a 'max-age' attribute whenever it sends
> a non-empty <data/> element. The semantics of the 'max-age' attribute
> exactly matches that of the Max-Age attribute from RFC 2965.

Wasn't the max-age element meant to be optional (the missing one
interpreted as session-wide)? Also in the "Defined Attributes" table.

* 4. Use Cases

Are the use cases intended to standardize the particular use of Data
Element.

> Example 2. A message with included data
> ...
> Once the data is provided, a subsequent message in the same session
> can refer to the data again without including the data itself.
> Example 3. A message with referenced data

Example 3 could be made a primary example (without <data/> element) and
Example 2 might just show the possibility to include the data if
desired and therefore follow the current "Example 3".

* Example 4. Audio Media Element

Generally, the empty <data/> should be IMO used for an occasional empty
file. I know there's not many use-cases for sending empty files... but
it might occasionally happen when one send several files and some of
them just happen to be empty.

I think we're unnecessarily changing the meaning, here.

  ...
  <uri type='audio/mpeg'>
    http://victim.example.com/challenges/speech.mp3?F3A6292C
  </uri>
  <data xmlns='urn:xmpp:tmp:data-element' 
        alt='An audio file'
        type='audio/ogg; codecs=speex'/>
  </data>
  ...

Could be changed to:

  ...
  <uri type='audio/mpeg'>
    http://victim.example.com/challenges/speech.mp3?F3A6292C
  </uri>
  <uri type='audio/ogg; codecs=speex'/>
    cid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 at shakespeare.lit
  </uri>
  ...

This would simplify things so that the <data/> element would always
belong to the top of the <message/> stanza and allowing uniform
handling.

* Example 5. File transfer offer with preview

    <file xmlns='http://jabber.org/protocol/si/profile/file-transfer' 
          size='330527' 
          name='image.png'>
      <data xmlns='urn:xmpp:tmp:data-element' 
            alt='There be dragons!'
            cid='d8f904ac-636c-11dd-8a2f-001143d5d5db at montague.lit'
            type='image/png'>
         iVBORw0KGgoAAAANSUhEUgAAADkAAABACAIAAAAvV0jbAAAACXBIWXMAAA4mAAAOJgGi7yX8AAAc
         ...
      </data>
      <range/>
    </file>

I'm afraid the <data/> element doesn't properly markup its meaning.

I propose one of
1) <preview
     cid="d8f904ac-636c-11dd-8a2f-001143d5d5db at montague.lit"/>
2) <preview
     uri="cid:d8f904ac-636c-11dd-8a2f-001143d5d5db at montague.lit"/>
or similar.

Furthermore, I believe this is out of the scope of this XEP and should
be done in the FT one and within the FT namespace.

* Position of the <data/>

For messages (and presence, if needed), I'd suggest to (of course
OPTIONALLY) include one or more non-empty <data/> elements directly in
the <message/> or <presence/>. For messages, this directly maps to the
e-mail attachments and the use of CID references in e-mail messages
(for single messages this could be actually showed as in e-mail
programs).

For IQ stanzas, where this is not possible, we can put it
directly in the single child of <iq/>, maybe.

* What's the alt attribute then for?

If we don't use empty <data/> elements at all (except the occasional
empty files), then the 'alt' facility should be provided by the
protocol that is using the URL not <data/> elements themselves as it is
done in HTML-IM.

To have some user-readable description (e.g. for the cache management),
I suggest removing 'alt' but adding e.g. 'desc' attribute for textual
description. This way we avoid confusion between 'alt' in the
presentation part and 'desc' in the data part.

Note: similar examples are used in XEP-0221: Data Forms Media Element

Pavel

--

Web: http://www.pavlix.net/
Jabber & Mail: pavlix(at)pavlix.net
OpenID: pavlix.net