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