Re: [Fwd: IPv6 @ IETF-71, especially Jabber]

new-style session request

hi,all
   i download the newest version jabberd2.1.23,i find that my jabberd client can't login the
jabberd2.1.23,but my jabberd client can login to jabberd2.1.15,i get the xmpp message:

 SEND:
<iq id='session' type='set'><session xmlns='urn:ietf:params:xml:ns:xmpp-session'/></iq>
RECV:
<iq id='session' type='error' xmlns='jabber:client'><error code='501'
type='cancel'><feature-not-implemented
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error><session
xmlns='urn:ietf:params:xml:ns:xmpp-session'/></iq> 

why the jabberd2.1.23 can not support the new-style session request(xmpp protocal) ?
				
--------------
jackie

Re: new-style session request

JackieZhang pisze:
> hi,all
>    i download the newest version jabberd2.1.23,i find that my jabberd client can't login the
jabberd2.1.23,but my jabberd client can login to jabberd2.1.15,i get the xmpp message:
>  
>  SEND:
> <iq id='session' type='set'><session xmlns='urn:ietf:params:xml:ns:xmpp-session'/></iq>
> RECV:
> <iq id='session' type='error' xmlns='jabber:client'><error code='501'
type='cancel'><feature-not-implemented
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error><session
xmlns='urn:ietf:params:xml:ns:xmpp-session'/></iq> 
> 
> why the jabberd2.1.23 can not support the new-style session request(xmpp protocal) ?

It will soon be "old-style session request" ;) - it's being removed from
RFC bis. Does the server advertise "session" in stream features? What
client are you using?

--

-- 
Maciek
 xmpp:machekku <at> uaznia.net

Re: new-style session request

On Mon, 2008-03-03 at 13:38 +0100, Maciek Niedzielski wrote:
> JackieZhang pisze:
> > hi,all
> >    i download the newest version jabberd2.1.23,i find that my jabberd client can't login the
jabberd2.1.23,but my jabberd client can login to jabberd2.1.15,i get the xmpp message:
> >  
> >  SEND:
> > <iq id='session' type='set'><session xmlns='urn:ietf:params:xml:ns:xmpp-session'/></iq>
> > RECV:
> > <iq id='session' type='error' xmlns='jabber:client'><error code='501'
type='cancel'><feature-not-implemented
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error><session
xmlns='urn:ietf:params:xml:ns:xmpp-session'/></iq> 
> > 
> > why the jabberd2.1.23 can not support the new-style session request(xmpp protocal) ?
> 
> It will soon be "old-style session request" ;) - it's being removed from
> RFC bis. Does the server advertise "session" in stream features? What
> client are you using?

I'm probably way late on getting into this conversation but why is
session being removed?  It seems to me that removing it prevents future
stream features that MUST occur after bind but before requesting the
session be started.  Regardless I could see client libs getting confused
when they don't see 'session' in the list of features, so a better
approach for backwards compatibility is to advertise it and make it a
no-op.

-travis

P.S. And I know I'm way late on this too, but requiring some stream
features from reopening the stream:stream and others not is a similar
problem. Take resource bind as an example.  If there was a future stream
feature that could not be advertised in <features> until after binding a
resource how would the client see it since we only get new features
after reopening the stream.  Methinks a better approach is to say that
all negotiated features are followed by reopening the stream.  Perhaps
this ship has sailed. :)

Re: new-style session request

Travis Shirk wrote:
> On Mon, 2008-03-03 at 13:38 +0100, Maciek Niedzielski wrote:
>> JackieZhang pisze:
>>> hi,all
>>>    i download the newest version jabberd2.1.23,i find that my jabberd client can't login the
jabberd2.1.23,but my jabberd client can login to jabberd2.1.15,i get the xmpp message:
>>>  
>>>  SEND:
>>> <iq id='session' type='set'><session xmlns='urn:ietf:params:xml:ns:xmpp-session'/></iq>
>>> RECV:
>>> <iq id='session' type='error' xmlns='jabber:client'><error code='501'
type='cancel'><feature-not-implemented
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error><session
xmlns='urn:ietf:params:xml:ns:xmpp-session'/></iq> 
>>>
>>> why the jabberd2.1.23 can not support the new-style session request(xmpp protocal) ?
>> It will soon be "old-style session request" ;) - it's being removed from
>> RFC bis. Does the server advertise "session" in stream features? What
>> client are you using?
> 
> I'm probably way late on getting into this conversation but why is
> session being removed?  It seems to me that removing it prevents future
> stream features that MUST occur after bind but before requesting the
> session be started.  Regardless I could see client libs getting confused
> when they don't see 'session' in the list of features, so a better
> approach for backwards compatibility is to advertise it and make it a
> no-op.

Right, it's a no-op. Or at least it's treated that way by all
implementations. As you may remember we discussed this at the devcon in
Portland back in 2006.  All implementations treat initial presence as
the session start and ignore the special session-start command. So
advertise-but-ignore is the best way to ensure backwards-compatibility.
I think there's something about this in rfc3921bis, no?

/me checks...

Yep:

http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-04.html#diffs

Maybe that deserves to be mentioned in a more prominent fashion.

> -travis
> 
> P.S. And I know I'm way late on this too, but requiring some stream
> features from reopening the stream:stream and others not is a similar
> problem. Take resource bind as an example.  If there was a future stream
> feature that could not be advertised in <features> until after binding a
> resource how would the client see it since we only get new features
> after reopening the stream.  Methinks a better approach is to say that
> all negotiated features are followed by reopening the stream.  Perhaps
> this ship has sailed. :)

I think so. :)

Indeed, the stream-reopen was added for security purposes (you need to
forget about things you learned before TLS or SASL was negotiated). So
for security-critical features I'd agree, but not in general.

Indeed, it's not 100% clear that we need *any* stream re-openings, and
that's something we might want to put into rfc3920bis for improved
efficiency during stream negotiation. Or at least discuss.

Peter

--

-- 
Peter Saint-Andre
https://stpeter.im/

Re: new-style session request

On Mon, 2008-03-03 at 16:24 -0700, Peter Saint-Andre wrote:

> 
> Indeed, it's not 100% clear that we need *any* stream re-openings, and
> that's something we might want to put into rfc3920bis for improved
> efficiency during stream negotiation. Or at least discuss.

I agree that reopening the stream is just syntactic sugar since it
really enforces nothing, but maybe a better option would be that the new
list of features is sent after each one is negotiated?  That would allow
my example to work (regarding some future feature) and would probably be
backward compatible since clients don't typically crash when they
receive something they are not expecting.  But going forward 'bis'
clients could expect the new set of features after, for example, binding
the resource.

-travis

ANNOUNCE: Loudmouth 1.3.4

What is Loudmouth?

Loudmouth is a small C library for writing Jabber clients written using
GLib. It's designed to be extensible while maintaining ease of use.

Loudmouth 1.3.4 is a release on the unstable 1.3 branch. It contains of
added features and bug fixes.

Fixed bugs:

* [LM-95]  - File descriptor leak in lm-connection.c
* [LM-113] - Loudmouth doesn't build with --disable-debug
* [LM-115] - ABI breakage from 1.2 => 1.3
* [LM-116] - lm_connection_set_jid() required when not using SRV
* [LM-117] - Reentrancy error on failed connect
* [LM-118] - Build fails on Mac OS X
* [LM-120] - Protect EAI_NODATA with #ifdef
* [LM-121] - Getting time outs when going through NAT on Linux

Thanks to Senko Rasic, Owen Taylor, Richard Hult, Martyn Russell and
Mikael Hallendal for the work done on this release.

You can download Loudmouth 1.3.4 here:
http://ftp.imendio.com/pub/imendio/loudmouth/src/loudmouth-1.3.4.tar.bz2

The git repository for the 1.3 branch is located on freedesktop.org:
git://github.com/hallski/loudmouth.git

You can browse it online here:
http://github.com/hallski/loudmouth/tree/master

The Loudmouth project page: http://www.loudmouth-project.org/

Enjoy!
The Loudmouth Team

File Transfer and custom attributes

Re: File Transfer and custom attributes

Hello

On Wed, Mar 05, 2008 at 12:22:11PM +0100, Matías Rojas wrote:
> I’m using Stream Initiation (XEP-0095) and File Transfer (XEP-0096) to send
> a file, but I need to include additional information about the file I’m
> sending.
> 
> What is the best way to send custom attributes of a file?
> 
> Should I use DataForm?

You need the other side to understand it as well, so you can
choose. There is no standard way to do this, so nothing will show it
anyway, so you can use dataforms (if your client already understands
them) to save some code, but you can make your own extension as well.

--

-- 
I left the ssh key under the doormat

Michal 'vorner' Vaner

Re: File Transfer and custom attributes

Matías Rojas wrote:
> Hi,
> 
> I’m using Stream Initiation (XEP-0095) and File Transfer (XEP-0096) to send
> a file, but I need to include additional information about the file I’m
> sending.

I'm curious: what information do you want to include? If it is of
general interest, perhaps we should update XEP-0096 to include it.

> What is the best way to send custom attributes of a file?
> 
> Should I use DataForm?

Sure, that might work...

<iq type='set' id='offer1' to='receiver <at> jabber.org/resource'>
  <si xmlns='http://jabber.org/protocol/si'
      id='a0'
      mime-type='text/plain'
      profile='http://jabber.org/protocol/si/profile/file-transfer'>
    <file xmlns='http://jabber.org/protocol/si/profile/file-transfer'
          name='test.txt'
          size='1022'>
      <x xmlns='jabber:x:data' type='result'>
        <field var='FORM_TYPE' type='hidden'>
          <value>your-private-namespace-here</value>
        </field>
      <field var='your-first-private-field'>
        <value>a-value</value>
      </field>
      <field var='your-second-private-field'>
        <value>a-value</value>
      </field>
    </x>
    </file>
    <feature xmlns='http://jabber.org/protocol/feature-neg'>
      <x xmlns='jabber:x:data' type='form'>
        <field var='stream-method' type='list-single'>
          <option>
            <value>http://jabber.org/protocol/bytestreams</value>
          </option>
          <option>
            <value>http://jabber.org/protocol/ibb</value>
          </option>
        </field>
      </x>
    </feature>
  </si>
</iq>