JID terminology (was: Re: [jdev] PyMSNt 0.11 release)

[Norman Rasmussen]

On 2/18/06, Justin Karneges <justin-keyword-jabber.093179 at affinix.com> wrote:
> On Friday 17 February 2006 12:58, Norman Rasmussen wrote:
> > RFC 3920 and 3921 will disagree with you.  There are multiple
> > instances in the specs where something like this is written:
> >
> > the resource identifier portion of the "full JID" (<node at domain/resource>)
> > address for use over that stream is a "full JID" of the form
> > <node at domain/resource>.
> > stanza whose value is the bare JID (<node at domain>) or the full JID
> > (<node at domain/resource>)
> > deliver the user's presence stanza to the full JIDs
> > (<contact at example.org/resource>)
>
> I don't see how this disagrees with what I wrote.  My point was that
> "barejid=fulljid" is logically false.
>
> Correct: "The bare JID happens to be the same as the JID."
>
> Nonsense: "The bare JID happens to be the same as the full JID."
>

> What you mean to say is "barejid=jid".  "Full JID" is more of a boolean.

okay, re-read specs, etc, and what I understand is: barejid has come
to mean jid without a resource, and fulljid has come to mean jid with
a resource - as far as transports are concerned, there is never a
resource (excluding recent pymsnt fix), so there's never a full jid.

Now looking at JEP-0065:

3.1.1. Initiator sends IQ-set to Target specifying the full JID and
network address of StreamHost/Initiator as well as the StreamID (SID)
of the proposed bytestream.

3.2.2 Initiator sends IQ-set to Target specifying the full JID and
network address of StreamHost as well as the StreamID (SID) of the
proposed bytestream.

4.6 The JIDs provided MUST be full JIDs (i.e., <user at host/resource>)

So transports with contacts with not full jids is exactly the status
we have with the c-based transports and the aim/icq python transports
(and the irc transport).

PyMSNt only differs because James changed it recently.  How is the
statement nonsense when it's implemented that way in transport code at
the moment?

So the (current) socks5 jep is basically saying you can't do
bytestreams (and hence FT) with transport contacts.

I think (personal opinion) that it was silly of the gajim team to make
the 'no full-jid, no FT) assumption.  I treat the PyMSNt /msn resource
hack as exactly that - a hack.

As Peter said:
> JEP-0100 includes the following note:
> ******
> If the Legacy Service to which the Gateway connects does not support a
> concept equivalent to that of Jabber "resources" as described in RFC
> 3920 [8], the 'from' address of message stanzas generated by a gateway
> SHOULD NOT include a resource identifier (i.e., they SHOULD be of the
> form <user at host> rather than <user at host/resource>). However, the 'from'
> address MAY include a resource if the Gateway determines that this is
> appropriate in the context of its communications with the Legacy Service.>
> ******
> So there is no requirement for a gateway to add resources.

So the PyMSNt 'fix' is going against 2x'SHOULD' in JEP-0100, but doing
FT with a barejid goes against 1xMUST in JEP-0065 -- That Peter (if i
remember correctly) has already said he doesn't mind changing to allow
basejids for transports.

All-in-all it makes more sense to allow FT with bare jids (like _most_
clients do atm), than it does it force all transports's contacts to
acquire a resource, just to support FT.

--
- Norman Rasmussen
 - Email: norman at rasmussen.co.za
 - Home page: http://norman.rasmussen.co.za/