[jdev] Stream Initiation: extension

Norman Rasmussen norman at rasmussen.co.za
Fri Sep 28 07:29:02 CDT 2007


I'd rather see:

<message to='mari at mus.se/work' type='chat'>
  <thread>ee2944c6</thread>
  <x xmlns='http://jabber.org/protocol/svgwb'>
     <image x='32.0' y='32.0'
          xlink:href='xmpp:mats at home.se/coci?sipub=pub0123'
          id='158229644' width='128' height='128'>
     </image>
  </x>
  <sipub xmlns='http://jabber.org/protocol/si-pub'
      id='publish-0123'
      mime-type='image/png'
      profile='http://jabber.org/protocol/si/profile/file-transfer'>
    <file xmlns='http://jabber.org/protocol/si/profile/file-transfer'
          name='blender.png'
          size='12582'
          date='2004-01-28T10:07Z'>
      <desc>All Shakespearean characters must sign and return this NDA
ASAP</desc>
    </file>
  </sipub>
</message>

and then the start/starting/si as defined in the si-pub xep.

Is there a particular reason to use sipub instead of start/starting?

(Except for tying the sipub id to the si sid, which if you want to do, then
let's rather see if we can change the xep to ask for that, instead of
creating brand new elements.  You should be able to track them via your iq's
id anyways).

Norman

On 9/28/07, Mats Bengtsson <matben at privat.utfors.se> wrote:
>
> More thoughts:
>
> Somewhat based on XHTML Inband Images
> http://wiki.jabber.org/index.php/XHTML_Inband_Images
> I have come up with another suggestion.
>
> Define an URI form xmpp:mats at home.se/coci?sipub=pub0123
> which defines a unique resource identifier to a file or other entity.
> A client, the initiator, can include this in any appropriate place,
> for instance, in a SVG image element (seen from the initiator side):
>
> SEND:
> <message to='mari at mus.se/work' type='chat'>
>   <thread>ee2944c6</thread>
>   <x xmlns='http://jabber.org/protocol/svgwb'>
>     <image x='32.0' y='32.0'
>            xlink:href='xmpp:mats at home.se/coci?sipub=pub0123'
>            id='158229644' width='128' height='128'>
>       <file xmlns='http://jabber.org/protocol/si/profile/file-transfer'
>             name='blender.png' size='12582'/>
>     </image>
>   </x>
> </message>
>
> The initiator then caches the mapping from the sipub identifier (pub0123)
> to the actual file or entity. The target can then request this file using:
>
> RECV:
> <iq type='get' from='mari at mus.se/work' to='mats at home.se/coci' id='3210'>
>    <sipub xmlns='http://jabber.org/protocol/si-pub' id='pub0123'/>
> </iq>
>
> The initiator then looks up the second id here, the sipub id attribute,
> and if it indeed has a file reference cached for this id, it initiates an
> ordinary si-set/si query after sending a result:
>
> SEND:
> <iq type='result' to='mari at mus.se/work' id='3210'>
>   <sipub xmlns='http://jabber.org/protocol/si-pub'
>          id='pub0123' sid='3c803c10-6983032b'/>
> </iq>
>
> Note that a sid attribute MUST be included which references the si id
> attribute
> to expect when the target receives the iq-set/si query. The target must be
> sure
> to understand that when it gets the corresponding iq-set/si it must not
> be handled as an ordinary user initiated file transfer.
>
> Everything continues unchanged from existing Stream Initiation. If the
> initiator
> can't find the sipub id reference it answers with an error as usual.
> Note that this XMPP URI is persistant since each request for it generates
> a new si stream. The si streams are, of course, not persistant, but the
> reference from the sipub identifier to the actual file or entity is.
> It is up to the initiating entity to decide on the lifetime of this
> relation.
>
> There is a slightly alternative solution. The initiators iq-set/si must be
> handled in the context of the original XMPP URI which the iq-set/si
> element
> doesn't say anything about. It can therefore be mistaken as an ordinary
> user initiated file transfer. Instead we could switch the
>
> <si xmlns='http://jabber.org/protocol/si' ...
>
> into
>
> <sipub xmlns='http://jabber.org/protocol/si-pub' ...
>
> in all places. I have some doubts about this, though. It complicates the
> life of a client developer.
>
> /Mats
>



-- 
- Norman Rasmussen
- Email: norman at rasmussen.co.za
- Home page: http://norman.rasmussen.co.za/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20070928/d0221345/attachment-0002.htm>


More information about the JDev mailing list