[Council] Re: VOTE: JEP-0127 (Common Alerting Protocol (CAP) Over
XMPP)
Ralph Meijer
jabberfoundation at ralphm.ik.nu
Thu Dec 9 09:12:49 CST 2004
On Wed, Dec 01, 2004 at 04:15:26PM -0700, Peter Saint-Andre wrote:
> In article <5080DC7A-4197-11D9-B337-000A95984138 at box5.net>,
> Thomas Muldowney <temas at box5.net> wrote:
>
> > I would maybe suggest a note about the users of the JEP needing to have
> > their own method of finding the actual pubsub nodes to subscribe to, if
> > they are used. There is no internal discovery or named nodes. I only
> > think this could be important because most other pubsub related JEPs
> > have this type of information. This isn't necessary though, and I'm
> > still +1 without out.
>
> Now that I look at this more, I think a simple note to this effect would
> make sense.
>
> The other pubsub JEPs (e.g., extended presence) show how to find
> someone's pubsub nodes based on a bare JID (disco#items
> stpeter at jabber.org to find his tunes node, or whatever). In the case of
> emergency alerts, one might have something like weather.jabber.org as a
> pubsub service and there would perhaps be one alert node for each
> weather forecast office (e.g., the "KSTO" in the examples is the
> four-character code for the Sacramento WFO).
>
> Alternatively, we could possibly show an example of disco-ing
> KSTO at JABBER.NOAA.GOV or whatever and discovering the pubsub node for
> emergency alerts originated by that WFO. Would that be more helpful?
Maybe they would use hierarchies in their pubsub nodes, and have a collection
node per WFO. Querying that node would reveal the possible leaf nodes.
I'm not sure what would be the best example here, but in any case I'm +1 on
this JEP moving forward.
--
Groetjes,
Ralphm
More information about the Council
mailing list