[Standards] [Fwd: [Council] meeting minutes, 2007-05-16]
stpeter at jabber.org
Tue May 22 20:03:41 UTC 2007
Mridul Muralidharan wrote:
> Peter Saint-Andre wrote:
>> Mridul Muralidharan wrote:
>>> A small queey - If the ping comes to a user's bare jid - what is the
>>> server expected to do ? Can we disallow that since pings are e2e ?
>> Why disallow it?
> Not necessarily disallow - but is there any usecase for it ?
No, I'm just saying that if we disallow it then we need to define error
cases for it, and I don't think that's really necessary.
> Server will not be able to fwd it to any end point and wont be able to
> process it on the jid's behalf - and so would need to end up with an
> error anyway right ?
> The reason I asked was because the proposed change rightly mentions
> about full jid - but is silent about bare jid. Just wanted to get it
It's useless, so don't send it.
>> The server replies on behalf of IQs sent to a bare JID, so you're not
>> finding out anything useful by pinging a bare JID, but I see no reason
>> to say you MUST NOT do so.
>> And pings are not necessarily e2e.
> e2e in the sense : from sender to recipient (except for errors ofcourse).
By e2e we often or usually mean client-to-client. Clients are endpoints,
servers and components are things in the middle.
> For example, for client/component to client case : can a server respond
> on behalf of a jid ? (Assuming presence was divulged already and server
> is confident of the connectivity of the jid).
> If not - that was the meaning of e2e I was referring to - if yes, it
> becomes interesting !
RFC 3921 says that if you send an IQ to a bare JID, the server will
reply. If you don't want that behavior, don't send to the bare JID.
Seems pretty straightforward.
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards