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:
>
> <link rel='xmpp' href='xmpp:...'/>
>
> 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 [email protected] 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
