Subject: [atoca] Fwd: New Version Notification for draft-barnes-atoca-cap-mime-00.txt

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 5 Oct 2011 18:53:27 -0400

This document is a very brief request to register a MIME type for CAP, basically completely split out of draft-ietf-atoca-cap.  I was thinking that there seems to be less interest in that document now, but there's still a need for a CAP MIME type, e.g., for ESCAPE.

I would ask that the chairs consider this for adoption as a working group item, so that it's easier to make use of CAP later on.

Thanks,
--Richard

Begin forwarded message:

> From: [email-masked]
> Date: October 5, 2011 6:46:07 PM EDT
> To: [email-masked]
> Cc: [email-masked]
> Subject: New Version Notification for draft-barnes-atoca-cap-mime-00.txt
> 
> A new version of I-D, draft-barnes-atoca-cap-mime-00.txt has been successfully submitted by Richard Barnes and posted to the IETF repository.
> 
> Filename:	 draft-barnes-atoca-cap-mime
> Revision:	 00
> Title:		 Media Type Registration for Common Alerting Protocol
> Creation date:	 2011-10-06
> WG ID:		 Individual Submission
> Number of pages: 5
> 
> Abstract:
>   This document registers the media type &quot;application/
>   common-alerting-protocol+xml&quot; for Common Alerting Protocol (CAP)
>   format .
> 
> 
> 
> 
> 
> The IETF Secretariat

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 05 Oct 2011 17:44:56 -0600

On 10/5/11 4:53 PM, Richard L. Barnes wrote:
> This document is a very brief request to register a MIME type for
> CAP, basically completely split out of draft-ietf-atoca-cap.  I was
> thinking that there seems to be less interest in that document now,
> but there's still a need for a CAP MIME type, e.g., for ESCAPE.
> 
> I would ask that the chairs consider this for adoption as a working
> group item, so that it's easier to make use of CAP later on.

I agree that it would be good to register this media type.

A pointer to the URL of the CAP spec would be helpful:

http://www.oasis-open.org/committees/download.php/15135/emergency-CAPv1.1-Corrected_DOM.pdf

The registration is using the old template. Please use the newer one
(which includes, for example, encoding considerations):

http://tools.ietf.org/html/rfc4288#section-10

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 05 Oct 2011 23:03:44 -0500

>thinking that there seems to be less interest in that document now,

err... huh?

when did this come about?

James

> > A new version of I-D, draft-barnes-atoca-cap-mime-00.txt has been 
> successfully submitted by Richard Barnes and posted to the IETF repository.
> >
>_______________________________________________
>atoca mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/atoca

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 6 Oct 2011 01:57:13 -0400

Well, it's expired, for one thing.  It wasn't my impression from the design team and the interim that the SIP event package for CAP was a high priority.  

Getting a MIME type for CAP, on the other hand, needs to be, so that other stuff can progress.

--Richard

On Oct 6, 2011, at 12:03 AM, James M. Polk wrote:

>> This document is a very brief request to register a MIME type for CAP, basically completely split out of draft-ietf-atoca-cap.  I was thinking that there seems to be less interest in that document now,
> 
> err... huh?
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 6 Oct 2011 09:09:11 +0300

Hi Richard, 

> This document is a very brief request to register a MIME type for CAP, basically completely split out of draft-ietf-atoca-cap.  I was thinking that there seems to be less interest in that document…

Brian and I put a CAP MIME registration in http://tools.ietf.org/html/draft-rosen-sipping-cap-04#page-12

> I would ask that the chairs consider this for adoption as a working group item, so that it's easier to make use of CAP later on.
The problem is that this document does not solve our underlying problem, namely how do we carry these big objects over UDP. 
If you carry them over TCP (as it could be done in SIP or XMPP) for point-to-point delivery then you can easily use XML digital signature as well (as specified in the CAP specification itself) without the need to describe a new security format. Using this new signature format will essentially make all existing usages (that happen to use XML signatures) incompatible. 

Ciao
Hannes

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 6 Oct 2011 13:06:19 +0200

Why are we talking specifics.

It was my impression that none of the charter items of this working group are a high priority.

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Richard L. Barnes
> Sent: 06 October 2011 06:57
> To: James M. Polk
> Cc: [email-masked]
> Subject: Re: [atoca] Fwd: New Version Notification for draft-barnes-atoca-
> cap-mime-00.txt
> 
> Well, it's expired, for one thing.  It wasn't my impression from the
> design team and the interim that the SIP event package for CAP was a high
> priority.
> 
> >> This document is a very brief request to register a MIME type for CAP,
> basically completely split out of draft-ietf-atoca-cap.  I was thinking
> that there seems to be less interest in that document now,
> >
> > err... huh?
> >

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 6 Oct 2011 07:31:58 -0400

I had gotten the impression that CAP was one specific around which there was pretty broad agreement.  It is, for example, in the charter:
"
For example, we expect to make use of the OASIS Common Alerting Protocol (CAP) for the encoding of alerts.
"

Practically speaking, if this group does anything that uses CAP, it's probably going to need a MIME type so that implementations can say they're using CAP.  So going ahead and registering a MIME type makes it simpler to realize the ultimate goals of the working group.  

Doing it separately from protocol work means it's decoupled, from a process point of view, from the protocols; delay in developing one protocol (the one that has the registration) won't cause delay in others.

--Richard

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 6 Oct 2011 07:37:47 -0400

> Brian and I put a CAP MIME registration in http://tools.ietf.org/html/draft-rosen-sipping-cap-04#page-12

You'll notice that I mentioned that draft by name in the very paragraph you quoted :)

> If you carry them over TCP (as it could be done in SIP or XMPP) for point-to-point delivery then you can easily use XML digital signature as well (as specified in the CAP specification itself) with…

As we discussed in the interim, the problem of alert *formatting* is separate from the problem of alert *delivery*.  This draft doesn't need to solve the transport problem.

If you want to discuss which security protocol we should be using, please comment on draft-barnes-atoca-escape.
<http://tools.ietf.org/html/draft-barnes-atoca-escape>

And if you're going to debate message size, please bring data.  Having implemented the current ESCAPE draft, which is pretty minimal, and played around with some parameters, I found that the smallest I could make messages was around 1500 bytes. (and that)  I sort of doubt that you're going to do any better than that with DSIG (or JOSE, for that matter).

--Richard

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 7 Oct 2011 08:19:59 +0800

This seems like a sensible idea.  Getting the non-controversial things out of the way makes sense.  draft-*-atoca-cap contained some controversial parts.  I didn't get the impression that this was one of them.

I'd like to hear what the others think about this approach.  If there are no objections, I'll talk to our area director about add a milestone.

--Martin

On 2011-10-06 at 09:53:27, Richard L. Barnes wrote:
> basically completely split out of draft-ietf-atoca-cap.  I was