Re: [Standards] [xmppwg] encapsulating NodeIDs in XMPP URIs
Dave Cridland wrote: > On Wed Dec 12 15:49:10 2007, Ralph Meijer wrote: >> In line with XEP-0147, I would like to register the empty string as a >> XMPP URI/IRI Querytype for the purpose of pointing to a specific note >> without implying a particular action. > > Actually, this strikes me as particularly good. Interesting. :) > URIs are, supposedly, used for addressing an object. However, the > resolution of a URI - getting at the object data - usually supposes a > particular action be used. In some cases, where URIs don't provide a > useful action, this is a pain. "http" scheme URIs suffer from this, > because we can't say "Open this URI as a WebDAV collection", or > "Checkout this resource as a DeltaV working copy". > > But sometimes it's very useful to use a URI purely as an address, and > "xmpp" scheme URIs do suffer from the problem that there usually *is* an > explicit action. Not necessarily, though. A URI like xmpp:[EMAIL PROTECTED] simply identifies the entity. > So I quite like the notion of using the empty query type as an explicit > action of no action - addressing a node is one such case, but I suspect > there may be others. (Maybe not today, maybe not tomorrow, etc) So if there is no node identifier involved, are you suggesting that we would do (2) instead of (1) below? 1. xmpp:[EMAIL PROTECTED] 2. xmpp:[EMAIL PROTECTED] How do we know that the query type is indeed empty? Do we need to do (3) instead? 3. xmpp:[EMAIL PROTECTED]; Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] [xmppwg] encapsulating NodeIDs in XMPP URIs
On Wed Dec 12 15:49:10 2007, Ralph Meijer wrote: In line with XEP-0147, I would like to register the empty string as a XMPP URI/IRI Querytype for the purpose of pointing to a specific note without implying a particular action. Actually, this strikes me as particularly good. URIs are, supposedly, used for addressing an object. However, the resolution of a URI - getting at the object data - usually supposes a particular action be used. In some cases, where URIs don't provide a useful action, this is a pain. "http" scheme URIs suffer from this, because we can't say "Open this URI as a WebDAV collection", or "Checkout this resource as a DeltaV working copy". But sometimes it's very useful to use a URI purely as an address, and "xmpp" scheme URIs do suffer from the problem that there usually *is* an explicit action. So I quite like the notion of using the empty query type as an explicit action of no action - addressing a node is one such case, but I suspect there may be others. (Maybe not today, maybe not tomorrow, etc) Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] [xmppwg] encapsulating NodeIDs in XMPP URIs
Dave Cridland wrote: > On Wed Dec 12 15:49:10 2007, Ralph Meijer wrote: >> David also noticed that the keys and value of the query parameters may >> be empty. That's probably not right. > > I'll disagree with myself as well, since it seems popular today. > > Having an empty value is quite sane, for those circumstances where the > value is either irrelevant, or when the value specifically needs to be > the empty string. > > But an empty key strikes me as odd. Agreed. Are you saying that the ABNF needs to be changed in rfc4622bis? I hope not, because it has been approved for publication. In any case, the XMPP Registrar can enforce this rule when accepting registrations for the relevant registry: http://www.xmpp.org/registrar/querytypes.html Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] [xmppwg] Re: encapsulating NodeIDs in XMPP URIs
Ralph Meijer wrote:
> On Wed, Dec 08, 2004 at 02:26:30PM -0700, Peter Saint-Andre wrote:
>> In article <[EMAIL PROTECTED]>,
>> Ralph Meijer <[EMAIL PROTECTED]> wrote:
>>
>>> On Wed, Nov 17, 2004 at 10:02:40AM -0700, Peter Saint-Andre wrote:
Two further issues/questions:
(1) The more I look at, the more I think that it would be best to
encapsulate disco/pubsub NodeIDs in the query component, e.g., something
like ?disco&node=foo. This seems simpler than putting it in the path,
which strikes me as unnecessarily complicated.
>>> Yes, I agree. In XMPP, the node is also 'just' an attribute of some specific
>>> action (like disco).
>>>
>>> For the moment we can leave out path segment parameters entirely, but maybe
>>> we should reserve the allowed reserved characters for future use? Did that
>>> parse?
>> Hmm, but designing for unknown use cases is probably not a good idea.
>
> Well, after a bit over three years [*], I am finding me disagreeing with
> myself.
Wow, I think you have broken my record for longest time between post and
reply. :)
> Within the work on federating social networks,
Well, now you are designing for known use cases instead of unknown use
cases. It makes a difference. :)
> I am looking at linking
> to publish-subscribe nodes from HTML and Atom documents like so:
>
>
>
> The rel 'xmpp' is debatable, but as far as I know there is no one
> referring to XMPP entities from HTML yet. In this case it could refer
> to any kind of xmpp entity: users (' accounts), MUC rooms, servers, etc.
Right. The rel='xmpp' seems fine to me. Is there a registry of rel
values? I don't think so.
> The problem I have is that there is no nice way to encapsulate the
> combination JID + NodeID in a URI without specifying an action.
Correct. That's because we never went all the way with nodes by making
them part of the address or considering a node to be an addressable entity.
> I would like to avoid specifying an action because I believe it is
> better if a consumer of such an URI would maybe use service discovery on
> the JID/NodeID and then provide possible actions based on that. For
> pubsub nodes, that might be subscribing, but also maybe retrieving
> previously published items.
So what about this?
xmpp:[EMAIL PROTECTED];type=get;request=info;\
node=f9451384-e23e-449f-8a8b-918649205f3c
> So I am tempted to come back to my original proposal of using URI Path
> Component parameters looking like this:
>
> xmpp:[EMAIL PROTECTED];node=f9451384-e23e-449f-8a8b-918649205f3c
>
> Opinions?
Basically that makes the NodeID part of the address, because rfc4622bis
says "The path component of an XMPP IRI/URI identifies an XMPP address
or specifies the XMPP address to which an XML stanza shall be directed
at the end of IRI/URI processing."
I need to look at rfc4622bis, RFC 3986, and RFC 3987 a bit more to know
what I think about this, but my immediate reaction is that it's not evil.
> I'm cross posting to standards@xmpp.org because I'm not sure if anyone reads
> this list anymore.
I'm dropping [EMAIL PROTECTED] because we don't use that list anymore.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [Standards] [xmppwg] encapsulating NodeIDs in XMPP URIs
On Wed Dec 12 15:49:10 2007, Ralph Meijer wrote: David also noticed that the keys and value of the query parameters may be empty. That's probably not right. I'll disagree with myself as well, since it seems popular today. Having an empty value is quite sane, for those circumstances where the value is either irrelevant, or when the value specifically needs to be the empty string. But an empty key strikes me as odd. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] IETF SASL WG meeting
On Tue, 11 Dec 2007, Justin Karneges wrote: > > Is the idea that you should be able to bind to an underlying privacy layer if > it is stronger than what SASL can provide? Yes, typically for relatively simple SASL password authentication mechanisms (replacements for CRAM-MD5 etc.) that don't provide a security layer. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ SHANNON: SOUTH 6 TO GALE 8, PERHAPS SEVERE GALE 9 LATER. VERY ROUGH BECOMING HIGH. RAIN. MODERATE OR POOR.
Re: [Standards] [xmppwg] encapsulating NodeIDs in XMPP URIs
On Wed, 2007-12-12 at 15:26 +0100, Ralph Meijer wrote:
> > [..snip..]
> Well, after a bit over three years [*], I am finding me disagreeing with
> myself.
>
> Within the work on federating social networks, I am looking at linking
> to publish-subscribe nodes from HTML and Atom documents like so:
>
>
>
> The rel 'xmpp' is debatable, but as far as I know there is no one
> referring to XMPP entities from HTML yet. In this case it could refer
> to any kind of xmpp entity: users (' accounts), MUC rooms, servers, etc.
>
> The problem I have is that there is no nice way to encapsulate the
> combination JID + NodeID in a URI without specifying an action.
> I would like to avoid specifying an action because I believe it is
> better if a consumer of such an URI would maybe use service discovery on
> the JID/NodeID and then provide possible actions based on that. For
> pubsub nodes, that might be subscribing, but also maybe retrieving
> previously published items.
>
> So I am tempted to come back to my original proposal of using URI Path
> Component parameters looking like this:
>
> xmpp:[EMAIL PROTECTED];node=f9451384-e23e-449f-8a8b-918649205f3c
>
> Opinions?
So after discussing a bit with David Cridland, we came to the conclusion
that RFC 4622 does not allow this particular syntax. However, the ABNF
does accept the following:
xmpp:[EMAIL PROTECTED];node=f9451384-e23e-449f-8a8b-918649205f3c
That is, putting the NodeID in the query component, with iquerytype
being empty.
In line with XEP-0147, I would like to register the empty string as a
XMPP URI/IRI Querytype for the purpose of pointing to a specific note
without implying a particular action.
David also noticed that the keys and value of the query parameters may
be empty. That's probably not right.
--
Groetjes,
ralphm
--
Groetjes,
ralphm
Re: [Standards] [xmppwg] Re: encapsulating NodeIDs in XMPP URIs
On Wed, Dec 08, 2004 at 02:26:30PM -0700, Peter Saint-Andre wrote:
> In article <[EMAIL PROTECTED]>,
> Ralph Meijer <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Nov 17, 2004 at 10:02:40AM -0700, Peter Saint-Andre wrote:
> > > Two further issues/questions:
> > >
> > > (1) The more I look at, the more I think that it would be best to
> > > encapsulate disco/pubsub NodeIDs in the query component, e.g., something
> > > like ?disco&node=foo. This seems simpler than putting it in the path,
> > > which strikes me as unnecessarily complicated.
> >
> > Yes, I agree. In XMPP, the node is also 'just' an attribute of some specific
> > action (like disco).
> >
> > For the moment we can leave out path segment parameters entirely, but maybe
> > we should reserve the allowed reserved characters for future use? Did that
> > parse?
>
> Hmm, but designing for unknown use cases is probably not a good idea.
Well, after a bit over three years [*], I am finding me disagreeing with
myself.
Within the work on federating social networks, I am looking at linking
to publish-subscribe nodes from HTML and Atom documents like so:
The rel 'xmpp' is debatable, but as far as I know there is no one
referring to XMPP entities from HTML yet. In this case it could refer
to any kind of xmpp entity: users (' accounts), MUC rooms, servers, etc.
The problem I have is that there is no nice way to encapsulate the
combination JID + NodeID in a URI without specifying an action.
I would like to avoid specifying an action because I believe it is
better if a consumer of such an URI would maybe use service discovery on
the JID/NodeID and then provide possible actions based on that. For
pubsub nodes, that might be subscribing, but also maybe retrieving
previously published items.
So I am tempted to come back to my original proposal of using URI Path
Component parameters looking like this:
xmpp:[EMAIL PROTECTED];node=f9451384-e23e-449f-8a8b-918649205f3c
Opinions?
I'm cross posting to standards@xmpp.org because I'm not sure if anyone reads
this list anymore.
[*] If you don't have the whole archive handy, refer to the archive of
the xmppwg mailing list for the thread that starts here:
http://mail.jabber.org/pipermail/xmppwg/2004-November/002215.html
Beware botching of all the examples by replacement of the at-sign
by ' at '. In that thread I explain the concept of URI Path
Component parameters and give some more examples.
--
Groetjes,
ralphm
Re: [Standards] Messages to unsubscribed contacts and resources
On Tue, Dec 11, 2007 at 10:28:55AM -0700, Peter Saint-Andre wrote: > Robin Redeker wrote: > > Hi! > > > > Some days ago I had a mail discussion on the jdev@ mailing list > > about messages to unsubscribed contacts and contacts in general. > > Tomasz said that messages should generally go to the bare JID instead of > > the full JID, and that the local routing is up to the server. > > > > He meant, chat sessions should be kept track of with the > > element, which completly makes sense to me. [.snip.] > > Please also note that the term 'chat session' in that paragraph is quite > > undefined, or at least it's meaning is a bit fuzzy to me. > > At its simplest, I think this is a chat session: > [.snip.] > > The sharing of directed presence gives both parties more knowledge about > availability, but I think it should be initiated by the recipient (and > subject to client prompt on a per-session basis, or configuration in the > client to auto-share directed presence). > [.snip.] > > Of course, If I don't have to keep track of the resources, that would > > _greatly_ simplify everything for me. Just sending to the bare JID and > > leaving the rest up to and the contacts routing settings > > would make enormous sense to me. > > Sending every message to the bare JID is not the custom. > > > Back to section 5.1.1, the sections somehow contradicts the section > > 8.3.1.1 (Message): > > > >For a message stanza of type "chat", "error", "groupchat", or > >"normal", the server SHOULD deliver the stanza to the > >highest-priority available resource. > > > > That 'feature' only makes sense if at least the initial message goes to > > a bare JID. But if it is routed to a resource by the server and I have > > no knowledge about the presence of that resource (eg. if I'm not > > subscribed), where should the next message go to, to the full JID I > > received a reply from? > > You should keep sending to the bare JID until you receive a reply from a > full JID, then start sending to the full JID. > Ok, I have another question: We have: Contact A with one resource (resource is 'res1'): [EMAIL PROTECTED]/res1 And Contact B with two resources: [EMAIL PROTECTED]/res1 priority 20 [EMAIL PROTECTED]/res2 priority 10 They are not subscribed to each other and do NOT share any presence information. Contact A sends a bare JID message to contact B. Contact B receives the message at res1 (due to highest priority), and answers from that resource. Contact A receives the full JID of that resource now and 'binds' the conversation to it and they chat. Later Contact B switches to his laptop, with another client bound to the other resource 'res2'. And he sends a message to the bare JID (because the client there doesn't know the full JID of contact A) of contact A. How should contact A proceed? Should he bind (and reply) the conversation to res2? Should he make a second 'chat session', which is probably not very intuitive for the user because he just wanted to talk to contact B and when he got two options to send the message, what should he do (he doesn't even know which resource is the 'right' one, or whether 'res1' maybe went offline)? What if they share presence, should contact A's client determine from the highest priority resource where the message should go to? Robin -- Robin Redeker | Deliantra, the free code+content MORPG [EMAIL PROTECTED] / [EMAIL PROTECTED] | http://www.deliantra.net http://www.ta-sa.org/ |
Re: [Standards] Messages to unsubscribed contacts and resources
On Tue, Dec 11, 2007 at 10:28:55AM -0700, Peter Saint-Andre wrote: > Robin Redeker wrote: > > Hi! > > > > Some days ago I had a mail discussion on the jdev@ mailing list > > about messages to unsubscribed contacts and contacts in general. > > Tomasz said that messages should generally go to the bare JID instead of > > the full JID, and that the local routing is up to the server. > > [.snip.] > > Please also note that the term 'chat session' in that paragraph is quite > > undefined, or at least it's meaning is a bit fuzzy to me. > > At its simplest, I think this is a chat session: > [.interesting examples snipped.] Thanks for the examples, that was what I thought was the other option. > > The sharing of directed presence gives both parties more knowledge about > availability, but I think it should be initiated by the recipient (and > subject to client prompt on a per-session basis, or configuration in the > client to auto-share directed presence). > > > And is somewhere described how full JIDs and play together? If at > > all? > > http://www.xmpp.org/extensions/xep-0201.html Thanks :) > > If routing is up to the local server side, makes it sense to reveal > > resources at all? Wasn't there a progress towards randomized resources? > > http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-04.html#bind-servergen Nice :) [.snip.] > > IMHO, threads are *not* required to have a chat session. Ok. > > But before I can implement anything resembling 'chat sessions' that > > term must be more explictly defined. > > See above for an example. I can easily write a formal definition too. Well, that example was what I imagined what a 'chat session' would be. I don't know how important this is for others, I guess most client developers don't have a problem with this. > > Of course, If I don't have to keep track of the resources, that would > > _greatly_ simplify everything for me. Just sending to the bare JID and > > leaving the rest up to and the contacts routing settings > > would make enormous sense to me. > > Sending every message to the bare JID is not the custom. Ok. > > Back to section 5.1.1, the sections somehow contradicts the section > > 8.3.1.1 (Message): > > > >For a message stanza of type "chat", "error", "groupchat", or > >"normal", the server SHOULD deliver the stanza to the > >highest-priority available resource. > > > > That 'feature' only makes sense if at least the initial message goes to > > a bare JID. But if it is routed to a resource by the server and I have > > no knowledge about the presence of that resource (eg. if I'm not > > subscribed), where should the next message go to, to the full JID I > > received a reply from? > > You should keep sending to the bare JID until you receive a reply from a > full JID, then start sending to the full JID. Ok, that makes much sense with the behaviour described in the URL you posted below. > > > Will my messages, if that contacts resource goes > > offline, be dropped without my knowledge? > > No, they will probably go to offline storage, because of this: > > http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-04.html#rules-fulljid-availnomatch > > I agree that these customary practices are not spelled out very well, so > I will fix that in the next version of rfc3921bis. I guess that would be a nice addition. Thanks! Robin -- Robin Redeker | Deliantra, the free code+content MORPG [EMAIL PROTECTED] / [EMAIL PROTECTED] | http://www.deliantra.net http://www.ta-sa.org/ |
