[Standards] Namespace Priority

Peter Saint-Andre stpeter at jabber.org
Fri Mar 30 20:08:06 UTC 2007


Ian Paterson wrote:
> Peter Saint-Andre wrote:
>> Ian Paterson wrote:
>>> There seems to be a real need. We've already got servers like Tigase 
>>> implementing proprietary functionality. Shouldn't we at least 
>>> standardise something? Why shouldn't we define a protocol (perhaps 
>>> something like this: 
>>> http://mail.jabber.org/pipermail/standards/2007-February/014000.html) 
>>> to enable those applications that want to support specialized content 
>>> routing?
>>
>> Can't the server already figure that out based on RAP? It could use 
>> the RAP info for routing stanzas sent to the bare JID even in cases 
>> where the contact does not receive the user's presence. But it's not 
>> clear how that applies to IQs, if at all.
> 
> It doesn't apply to IQs. 

But couldn't it? (At least if the IQ is directed to my bare JID.)

> But, as you mention below, protocols like 
> Jingle can still use IQs because a client can first perform a Session 
> Negotiation (XEP-0155 or XEP-0116) in order to discover the resource of 
> the other entity before sending an IQ.
> 
> A server could use the RAP elements it receives in presence stanzas from 
> its users to understand which namespaces each connected resource 
> supports. However RAP elements are currently not designed for that.

But it seems to me that the server COULD use the RAP info to route IQs 
(or anything else) more intelligently, no?

> Furthermore, it doesn't help anyway, since servers would still have no 
> way of understanding to which resource a Session Negotiation request 
> should be delivered (since the sender currently has no protocol to tell 
> the server that the request should be sent to a client that supports, 
> for example, Jingle).

But we can create a RAP application (rapplication?) type for that.

> RAP only solves the issue for people who I allow to subscribe to my 
> presence. 

Not if the server uses the RAP information in creative ways. The 
presence stanza is simply how I tell the server how I want it to handle 
IQs of a certain type (or anything else that might be routed to my bare 
JID).

> So IMHO the solution should not involve presence stanzas at
> all. The alternative proposal outlined in the URL above does give 
> servers a bit more work when delivering <message/> stanzas to bare JIDs, 
> but it has several advantages:
> 
> 1. it works for non-subscribers
> 2. it keeps presence stanzas small

I.e., because you "register" on login and don't ever send your 
priorities via presence.

> 3. it is even more simple for clients

How so?

And how does your approach interact with RAP? Does it replace RAP?

>> Negotiate a chat session via XEP-0155 to request an audience, when it 
>> starts exchange directed presence, then do your IQ stuff for Jingle. 
>> Seems straightforward to me.
> 
> How can the initiator (who is not a subscriber) tell the other user's 
> server that its XEP-0155 session request should be delivered to the 
> resource that supports Jingle? 

We'd need a new RAP application type for that.

> Even after the initiator discovers that 
> the resource the request was sent to does not support Jingle, it still 
> has no protocol to tell the server to deliver any subsequent request to 
> a different resource.

Well if the request is routed appropriately (via new "rapplication" 
type) then you're all set. But if it is not routed appropriately then 
social mechanisms may take over (reply via message to contact me over 
here). Hrm.

I will look at your approach and RAP again more closely, the foregoing 
are simply off-the-cuff remarks.

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070330/cd28f40b/attachment.bin>


More information about the Standards mailing list