Re: [emergency-adopt-docs] Groups - CAP Example Practices uploaded

[Jacob Westfall <jake@jpw.biz>]

Hi,
	The CAP practices draft looks like a really good start.  Some quick comments below and I'll follow up later with a more detailed review.

- Atom is not an acronym, its just spelt "Atom"
- A mimeType for CAP needs to be registered and standardized on.  Too many feeds are using different types causing confusion.
- When embedding a CAP alert in the content element for Atom, a proper mimeType should be used, not a generic text/xml.
- When linking to a CAP alert, the proper mimeType should again be used.
- For RSS, enclosure elements are used instead of links, so the RSS section is wrong about multiple linkages.
- Feed security, an RSS or Atom feed itself can also be digitally signed.
- Updating alerts.  If they are removed too soon from the feed after an update, systems who aren't polling as frequently won't be able to download any messages that are referenced by the update, breaking the reference chain and missing potential changes they should be aware of.  My rule of thumb is that if the CAP message "refers" to a past alert, then it should be available in the feed for someone to find and download it.  Removing after expiration or cancellation is okay.  Or an alternate is to set a duration time, keeping any message in the feed for say 24 hours maximum to allow infrequent polling systems to catch up.
- The Alert updates bullet about "overwriting existing alerts" is confusing.  I think it refers to the west coast tsunami center practice but needs to be clearer.
- The advice given in Alert updates about generating references is confusing and potentially incorrect.  What is the "ID" being discussed here, CAP or feed based?

-- 
Jacob Westfall <jake@jpw.biz>