I'd rather see: <message to='[EMAIL PROTECTED]/work' type='chat'> <thread>ee2944c6</thread> <x xmlns='http://jabber.org/protocol/svgwb'> <image x='32.0' y='32.0' xlink:href='xmpp:[EMAIL PROTECTED]/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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]/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='[EMAIL PROTECTED]/work' type='chat'> > <thread>ee2944c6</thread> > <x xmlns='http://jabber.org/protocol/svgwb'> > <image x='32.0' y='32.0' > xlink:href='xmpp:[EMAIL PROTECTED]/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='[EMAIL PROTECTED]/work' to='[EMAIL PROTECTED]/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='[EMAIL PROTECTED]/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: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
