[Council] Re: VOTE: JEP-0127 (Common Alerting Protocol (CAP) Over XMPP)

[Ralph Meijer]

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