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

Peter Saint-Andre Wed, 06 Aug 2008 10:18:20 -0700

Pavel Simerda wrote:

On Tue, 05 Aug 2008 23:28:16 -0500
XMPP Extensions Editor <[EMAIL PROTECTED]> 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.


At this point I think I'll make you a co-author. :)

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


Certainly!

* 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.

Optional in HTTP (RFC 2965)? Yes. But we can say that it's RECOMMENDED in XMPP.

* 4. Use Cases

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


Maybe...

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".


Well, here the image is so small that I don't see the harm in sending it.

* 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:[email protected]
  </uri>
  ...

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


Yes, I think that's right.

* 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='[EMAIL PROTECTED]'
            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="[EMAIL PROTECTED]"/>
2) <preview
     uri="cid:[email protected]"/>
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.


That seems better, yes. Something like this:

    <file xmlns='http://jabber.org/protocol/si/profile/file-transfer'
          size='330527'
          name='image.png'>
      <preview>
        <data xmlns='urn:xmpp:tmp:data-element'
              alt='There be dragons!'
              cid='[EMAIL PROTECTED]'
              type='image/png'>
          [...]
        </data>
      </preview>
      <range/>
    </file>

And yes it belongs in the file transfer spec.

* 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).


Agreed.

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


Probably.

* 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.


I think so.

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.


Six of one, half a dozen of the other.

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


Yes that needs to be cleaned up.

/psa

smime.p7s
Description: S/MIME Cryptographic Signature

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

Reply via email to