Generalisations (was RE: [Sip] Why not ISUP?)

["Mark Watson" <[e-mail]>]

While we're on the topic of generalisations...

I haven't been following the REFER header authentication debate, but
wouldn't a generic way to authenticate/sign any header be potentially useful
? (apologies if this is the current proposal anyway)

Perhaps a 'Previous-Header-authenticate:' header ?

Potentially we will have other headers in future where some entity needs to
vouch for their integrity.

Or a generic way to encrypt a single header. The 'Encrypted-header:' header.
Or do we already have that ?

Just a thought.

Regards...Mark


> -----Original Message-----
> From: Henning Schulzrinne [mailto:[e-mail]]
> Sent: 07 September 2001 13:50
> To: Matt Holdrege
> Cc: Nathan Nelson; 'P Villa'; [e-mail]
> Subject: Re: [Sip] Why not ISUP?
> 
> 
> The whole idea is *not* to make changes to the core protocol. 
> Leave the
> core protocol generic and application-agnostic, and add 
> extensions that
> only affect people that are interested in the particular feature.
> Examples include, so far, the event model, reliable provisional,
> manyfolks, refresh and a few others - if you don't care about these
> features or they don't apply to your environment, you can blissfully
> ignore them. This does cause us some pain now, as we have to avoid the
> usual "design feature X into the protocol" trap, but yet allow enough
> tools. The extension mechanisms and the now-emerging cleaned-up
> generalized routing mechanism allow for this. (With hindsight, a
> generalized reliability mechanism that avoided the 100rel and INVITE
> special cases would have been nice, too, but that's hard to backfit.)
> 
> Matt Holdrege wrote:
> > 
> > At 08:34 PM 9/6/2001, Nathan Nelson wrote:
> > >ISUP is a traditionally ridge protocol that has limit 
> capacity to adapt to
> > >changes.  Each time a new feature is added it takes 18 
> months of debate, 18
> > >months of development, and then you get Calling Name 
> Delivered.  If it does
> > >not work in SIP send an email and next month you have an 
> RFC.  If people
> > >like it they develop to it, if not next month you have a new RFC.
> > 
> > I don't know whether to laugh or cry. If it were that easy 
> to create an RFC
> > we would have chaos. In reality, as SIP is further 
> deployed, making changes
> > to the core protocol will likely be much more difficult 
> than updating ISUP.
> > 
> > _______________________________________________
> > Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use [e-mail] for questions on current sip
> > Use [e-mail] for new developments on the application of sip
> 
> _______________________________________________
> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip
>