Re: INFO

On 9/26/07 5:35 PM, Brian Stucker wrote:
> I think the key point being made on the other side is
that there's
> nothing special about an event package. It is an
identifier that
> disambiguates the NOTIFY. In some cases other header
values could serve
> the same purpose (i.e. content-type w/ DTMF). 
>   

But that's a point solution that puts a band-aid on INFO for
precisely 
one use case and leaves it broken for others. It doesn't
scale to other 
uses for INFO.

That points to really only two sane approaches: either (a)
come up with 
an unambiguous differentiator for various INFO usages (in
the style of 
event packages), or (b) grandfather current approaches
(band-aids and 
all) and forbid any other applications of INFO.

Eric's document basically takes the second approach,
grandfathering all 
uses of INFO that are currently published in an RFC or an
active 
internet-draft, and forbidding any others. The list is not
long; I'll 
replicate it here:

  1. RFC 3372

You want more than that, you really need packages.

/a


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

 

> -----Original Message-----
> From: Adam Roach [mailto:adamnostrum.com] 
> Sent: Wednesday, September 26, 2007 5:50 PM
> To: Stucker, Brian (RICH1:AR00)
> Cc: Hadriel Kaplan; sipietf.org
> Subject: Re: [Sip] INFO
> 
> On 9/26/07 5:35 PM, Brian Stucker wrote:
> > I think the key point being made on the other side
is that there's 
> > nothing special about an event package. It is an
identifier that 
> > disambiguates the NOTIFY. In some cases other
header values could 
> > serve the same purpose (i.e. content-type w/
DTMF).
> >   
> 
> But that's a point solution that puts a band-aid on
INFO for 
> precisely one use case and leaves it broken for others.
It 
> doesn't scale to other uses for INFO.
> 
> That points to really only two sane approaches: either
(a) 
> come up with an unambiguous differentiator for various
INFO 
> usages (in the style of event packages), or (b)
grandfather 
> current approaches (band-aids and
> all) and forbid any other applications of INFO.
> 
> Eric's document basically takes the second approach, 
> grandfathering all uses of INFO that are currently
published 
> in an RFC or an active internet-draft, and forbidding
any 
> others. The list is not long; I'll replicate it here:
> 
>   1. RFC 3372
> 
> You want more than that, you really need packages.

Expand that list to include application/dtmf and I think
you'll largely
end the debate.

> 
> /a
> 


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip