Subject: [earlywarning] comment on draft-rosen-atoca-server-discovery

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 15 Jul 2010 11:18:39 +0800

I like this.  It's simple enough that it could just work.

GeoRSS seems like a doubling up.  You can already stuff a CAP alert into Atom.  That should suffice, since the CAP alert already contains information on location.

Even using Atom leads to a double up on a number of parameters, like the originator (author) of the alert.  Both Atom and CAP provide fields for this.

Care will be needed (specification) to ensure that this doesn't lead to un-interoperable implementations.

The draft doesn't identify what aspects of the LoST extensions are useful.  I couldn't work it out either.  As far as I can tell, the extensions will at best be marginally useful.  Either way, this needs expansion.

--Martin

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 20 Jul 2010 14:04:36 +0200

Hi Martin,

please expand a bit on what you meant with the GeoRSS comment.

The reason for having GeoRSS mentioned in there is that GeoRSS is quite 
widely used for distributing alerts and there will always be different 
ways to distribute alerts.

Are you suggesting not to use GeoRSS?

Ciao
Hannes

On 15.07.2010 05:18, Thomson, Martin wrote:
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 21 Jul 2010 06:40:09 +0800

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Tuesday, 20 July 2010 10:05 PM
> 
> Hi Martin,
> 

Not at all, though I am pointing out that GeoRSS provides some of the same capabilities that CAP does: it includes parameters for time, author, and location.  Having duplicated functions might result in an interoperability mismatch - one implementation expects location in CAP, another omits it in favour of the GeoRSS.  Any specification will have to deal with this.  If there is already experience in the matter, then looking at existing behaviour will certainly help.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 21 Jul 2010 11:00:46 +0200

Hi Martin, 

I agree that it would be desirable to have a single format for alerts only. I do, however, not expect this to happen. 

Additionally, there will be a number of ways to convey alerts (the transport aspect, like we have it with other protocols as well). 

Hence, in the context with this specific document I was expecting that LoST would allow us to discover the format/transport mechanism through which a client can obtain these alerts. This would be very much in line with the way how we designed LoST to work for regular emergency services as well. 

Do you think that this makes sense?

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Wed, 21 Jul 2010 06:40:09 +0800
> Von: "Thomson, Martin" <[email-masked]>
> An: Hannes Tschofenig <[email-masked]>
> CC: "[email-masked]" <[email-masked]>
> Betreff: RE: [earlywarning] comment on draft-rosen-atoca-server-discovery

> Not at all, though I am pointing out that GeoRSS provides some of the same
> capabilities that CAP does: it includes parameters for time, author, and
> location.  Having duplicated functions might result in an interoperability
> mismatch - one implementation expects location in CAP, another omits it in
> favour of the GeoRSS.  Any specification will have to deal with this.  If
> there is already experience in the matter, then looking at existing behaviour
> will certainly help.
> 
> > 
> > Ciao
> > Hannes
> >

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 22 Jul 2010 08:28:16 +0800

> Hence, in the context with this specific document I was expecting that
> LoST would allow us to discover the format/transport mechanism through
> which a client can obtain these alerts. This would be very much in line
> with the way how we designed LoST to work for regular emergency
> services as well.

That works.  A URI might not tell the entire story (the same resource might provide multiple MIME types...) but that's no reason not to try.