Subject: [sipcore] Declaring SIP 1.0 historic?

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 13 Jul 2016 16:15:14 +0200

Friends,

Is it time to declare SIP 1.0 historic? I haven’t met a SIP 1.0 implementation in use for many, many years.

https://tools.ietf.org/html/rfc2543

/O

---

From: Roman Shpount <[email-masked]>
Date: Wed, 13 Jul 2016 10:23:39 -0400

Yes, please. I would be happy to remove the RFC 2543 transaction matching.

_____________
Roman Shpount

On Wed, Jul 13, 2016 at 10:15 AM, Olle E. Johansson <[email-masked]> wrote:

> Friends,
>
> Is it time to declare SIP 1.0 historic? I haven’t met a SIP 1.0
> implementation in use for many, many years.
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Brett Tate <[email-masked]>
Date: Wed, 13 Jul 2016 10:28:35 -0400

Hi,

RFC 2543 is version 2.0.

Are you wanting to declare RFC 2543 as historic or whatever defined version
1.0 as historic?

What would be the benefit of declaring RFC 2543 (or version 1.0) as
historic?  For instance, are you wanting to remove some of the backward
compatibility related mandates contained within RFC 3261?

Thanks,
Brett

> -----Original Message-----
> From: sipcore [mailto:[email-masked]] On Behalf Of Olle E.
> Johansson
> Sent: Wednesday, July 13, 2016 10:15 AM
> To: [email-masked]
> Cc: Olle E Johansson
> Subject: [sipcore] Declaring SIP 1.0 historic?
>
> Friends,
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 13 Jul 2016 16:41:10 +0200

> On 13 Jul 2016, at 16:28, Brett Tate <[email-masked]> wrote:
> 
> Hi,
> 
> RFC 2543 is version 2.0.
My mistake.
> Are you wanting to declare RFC 2543 as historic or whatever defined version
RFC 2543 to historic
> compatibility related mandates contained within RFC 3261?
I don’t really know - but I suspect there are a lot of legacy stuff hanging around
like Roman pointed out. Maybe we can make things more simple.

Just wanting to open a discussion and some housecleaning.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 13 Jul 2016 16:57:19 +0200

> On 13 Jul 2016, at 16:28, Brett Tate <[email-masked]> wrote:
I started googling for version 1.0 and it seems half of the Internet believes that 2543 is version 1.0.

"Session Initiation Protocol was first introduced in March 1999 by IETF RFC 2543. This RFC (Request for Comments) was the original core specification and was obsolete by IETF RFC 3261 in June 2002. These RFC’s are more commonly known as SIP 1.0 (2543) and SIP 2.0 (3261). There are many related RFCs that are summarized at the end of this document.”

http://www.whichvoip.com/voip/protocols/sip.htm

“the protocol was standardized as RFC 2543 in 1999 (SIP 1.0). In November 2000, SIP was accepted as a 3GPP signaling protocol and permanent element of the IP Multimedia Subsystem (IMS) architecture for IP-based streaming multimedia services in cellular systems. As of 2014, the latest version (SIP 2.0) of the specification is RFC 3261, published in June 2002,[2] with extensions and clarifications since then.[3]”

https://en.wikipedia.org/wiki/Session_Initiation_Protocol

As Brett says, RFC 2543 is indeed version 2.0:
"4.3.1 SIP Version

   Both request and response messages include the version of SIP in use,
   and follow [H3.1] (with HTTP replaced by SIP, and HTTP/1.1 replaced
   by SIP/2.0) regarding version ordering, compliance requirements, and
   upgrading of version numbers. To be compliant with this
   specification, applications sending SIP messages MUST include a SIP-
   Version of "SIP/2.0”.”

Realising I’ve been fooled by folklore I am still searching for version 1.0. Any pointers?

If we have 2.0 according to 2543 and 2.0 according to 3261 it’s going to be hard to get
rid of 2543.

I would have no problem hearing that story - why did we keep the 2.0 version in 3261 - while gently
SIPping a german beer in Berlin next week :-)

/O

---

From: "Neelakantan, Neel" <[email-masked]>
Date: Wed, 13 Jul 2016 15:32:15 +0000

If you go over the archives of 2543bis this got discussed based on the SIP Guru

http://www.cs.columbia.edu/sip/talks/ietf0008_draft0.pdf

This keep popping up in the mailing lists.  Searching through I came across this which pretty much provides rationale

http://www.ietf.org/mail-archive/web/sip/current/msg18436.html

If you want some history, rfc2543bis is a good place to start.

Having said that, it makes sense to deprecate legacy or breaking functionality that hinders ease of deployments.  Time to start a ID and list things that are scrub worthy?

Thanks,
Neel.

> Sent: Wednesday, July 13, 2016 9:57 AM
> To: Brett Tate <[email-masked]>
> Cc: [email-masked]; Olle E Johansson <[email-masked]>
> Subject: Re: [sipcore] Declaring SIP 1.0 historic?
> 
> 
> "Session Initiation Protocol was first introduced in March 1999 by IETF RFC
> 2543. This RFC (Request for Comments) was the original core specification
> and was obsolete by IETF RFC 3261 in June 2002. These RFC’s are more
> commonly known as SIP 1.0 (2543) and SIP 2.0 (3261). There are many related
> RFCs that are summarized at the end of this document.”
> 
> “the protocol was standardized as RFC 2543 in 1999 (SIP 1.0). In November
> 2000, SIP was accepted as a 3GPP signaling protocol and permanent element
> of the IP Multimedia Subsystem (IMS) architecture for IP-based streaming
> multimedia services in cellular systems. As of 2014, the latest version (SIP 2.0)
> of the specification is RFC 3261, published in June 2002,[2] with extensions
> and clarifications since then.[3]”
> 
> If we have 2.0 according to 2543 and 2.0 according to 3261 it’s going to be
> hard to get rid of 2543.
> 
> I would have no problem hearing that story - why did we keep the 2.0
> version in 3261 - while gently SIPping a german beer in Berlin next week :-)
> 
> /O
> 
> >
> > historic?  For instance, are you wanting to remove some of the
> > backward compatibility related mandates contained within RFC 3261?
> >
> > Thanks,
> > Brett
> >

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 13 Jul 2016 11:36:08 -0400

> Realising I’ve been fooled by folklore I am still searching for version 1.0. Any pointers?

There never was a SIP/1.0.  The 2.0 number was chosen to make sure that SIP
wouldn't be confused with HTTP/1.x on the wire, and also in a vague (and it
turned out, vain) hope that it'd be possible to run SIP through HTTP
proxies.

> If we have 2.0 according to 2543 and 2.0 according to 3261 it’s going to be hard to get

It'd be possible to deprecate the old 2543-compatible transaction matching
and source routing.  I don't know how much of a gain that is for
implementors, though.
 
> SIPping a german beer in Berlin next week :-)

We kept it because SIP routing rules (notably forking) mean that there's no
good way to try to send a request with a newer version, and then if it
fails, fall back to an older version.  This is why all backward
compatibility in SIP has to be single-pass.

-- 
Jonathan Lennox
[email-masked]

---

From: Brett Tate <[email-masked]>
Date: Wed, 13 Jul 2016 12:13:45 -0400

> RFC 2543 transaction matching.

I find RFC 3261 section 17.2.3 transaction matching to be overly lenient
when using the magic cookie.

For instance, the matching rules don't even include Call-ID and CSeq.  Thus
if you follow RFC 3261 section 17.2.3, you have to allow requests containing
different Call-ID and CSeq to match because of the magic cookie flexibility.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Jul 2016 13:01:23 -0400

> Realising I’ve been fooled by folklore I am still searching for version 1.0. Any pointers?

I don't know about documents for it. But I bet Henning was involved. So 
he is where I would start.

> SIPping a german beer in Berlin next week :-)

I became involved just a bit before 3261. I don't recall, but I expect 
that it was because there were deployments of 2543 and there is no good 
way to be agile wrt version number.

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Wed, 13 Jul 2016 13:41:37 -0400

> There never was a SIP/1.0.  The 2.0 number was chosen to
> make sure that SIP wouldn't be confused with HTTP/1.x on
> the wire, and also in a vague (and it turned out, vain)
> hope that it'd be possible to run SIP through HTTP proxies.

Thanks for the information.  I had assumed that there was a version 1.0
somewhere (for instance maybe based upon a Henning Schulzrinne document or
RFC 2543 section F's acknowledgement of [37,38]).

> > If we have 2.0 according to 2543 and 2.0 according to
> > 3261 it’s going to be hard to get rid of 2543.
>
> It'd be possible to deprecate the old 2543-compatible
> transaction matching and source routing.  I don't know
> how much of a gain that is for implementors, though.

I don't think there is much gain concerning transaction matching or strict
routing.  The desire to deprecate occasionally arises concerning To and From
URI mandates.

For instance, RFC 3261 section 12.2.1.1 indicates an expectation that the
"mandatory reflection of the original To and From URI in mid-dialog requests
will be deprecated in a subsequent revision".  I'm not sure why; however
some vendors and operators want to allow the To/From URI to change without
any restrictions (e.g. they don't want to be restricted by RFC 4916).

---

From: Adam Roach <[email-masked]>
Date: Wed, 13 Jul 2016 12:42:16 -0500

On 7/13/16 10:36, Jonathan Lennox wrote:
> There never was a SIP/1.0.

That doesn't quite match my memory.

I beleive there were early implementations of Handly/Schooler's SIP/1.0 
spec 
<http://www.cs.columbia.edu/sip/drafts/mmusic/draft-ietf-mmusic-sip-00.pdf>in 
one or both of the UCL/Caltech labs. This was subsequently merged with 
Schulzrinne's Simple Conference Invitation Protocol (SCIP/1.0) 
<https://tools.ietf.org/html/draft-ietf-mmusic-scip-00>, and the merged 
version was dubbed SIP/2.0.

Poking around, this paper's introduction matches my personal 
recollection of the history:

http://www.jocm.us/uploadfile/2013/0416/20130416114634804.pdf

/a

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 13 Jul 2016 14:50:29 -0500

> believes that 2543 is version 1.0.

A brief history of SIP (including 1.0) is provided in [1].  The PDF for
this paper is available for free download (open access) at [2].

Have fun spelunking the origin of SIP.

[1] Salman Abdul Baset, Vijay K. Gurbani, Alan B. Johnston,
  Hadriel Kaplan, Brian Rosen and Jonathan D. Rosenberg , "The Session
  Initiation Protocol (SIP): An evolutionary study", In Journal of
  Communications (JCM), pp. 89-105, Vol. 7., No. 2, February 2012

[2] 
http://ojs.academypublisher.com/index.php/jcm/article/download/jcm070289105/4295

Cheers,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: [email-masked] / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 13 Jul 2016 21:55:16 +0200

> On 13 Jul 2016, at 21:50, Vijay K. Gurbani <[email-masked]> wrote:
> 
> [2] http://ojs.academypublisher.com/index.php/jcm/article/download/jcm070289105/4295

Thank you to everyone that have been responding to my spelunking!

I will read up on this. (And update my training materials).
Always great to learn.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 13 Jul 2016 21:59:56 +0200

> On 13 Jul 2016, at 19:41, Brett Tate <[email-masked]> wrote:
> 

There are many call transfer scenarios involving b2bua’s that need
to modify/update caller IDs and there are too many implementations
pre-4916 out there.

/O

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 13 Jul 2016 15:12:15 -0500

On 07/13/2016 10:36 AM, Jonathan Lennox wrote:
>> I would have no problem hearing that story - why did we keep the
>> 2.0 version in 3261 - while gently SIPping a german beer in Berlin
>> next week :-)
>
> We kept it because SIP routing rules (notably forking) mean that
> there's no good way to try to send a request with a newer version,
> and then if it fails, fall back to an older version.  This is why all
> backward compatibility in SIP has to be single-pass.

Right, that matches my recollection as well.  When we were designing
what eventually became rfc3261, a prime directive was do no harm and
be backwardly compatible.  Because rfc2543 was deployed and being used,
a forklift upgrade by changing the protocol version was not looked at
kindly.

Almost a decade ago, a brief email exchange surfaced to entertain the
idea of a SIP/3.0 [1].  It was ignominiously short lived :-)

[1] https://www.ietf.org/mail-archive/web/sip/current/thrd19.html#18421

Cheers,

- vijay

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 13 Jul 2016 22:28:05 +0200

> On 13 Jul 2016, at 22:12, Vijay K. Gurbani <[email-masked]> wrote:
> 

Just love this quote by Dale Worley:

"SIP 3.0 is like fully participatory democracy, the ultimate form of
communism, and the earthly Kingdom of God -- a thorough reform of what
presently exists that will remove all of its flaws.

Similar to those other three projects, there is no WG timeline yet for
SIP 3.0 development.”

Let’s start SIP 4.0 :-)

/O

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Thu, 14 Jul 2016 01:00:11 +0000

So can you be clear on where you are trying to get to.

1)	deprecate SIP 1.0 --> but it never existed.

2)	deprecate RFC 2543 --> but this RFC is historic and therefore is of that status.

3)	deprecate mechanisms for interoperability of RFC 3261 with RFC 2543?

Regards

Keith Drage

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Olle E. Johansson
Sent: 13 July 2016 21:28
To: Gurbani, Vijay (Nokia - US)
Cc: [email-masked]; Olle E Johansson
Subject: Re: [sipcore] Declaring SIP 1.0 historic?

> be backwardly compatible.  Because rfc2543 was deployed and being 
> used, a forklift upgrade by changing the protocol version was not 
> looked at kindly.
> 
> [1] 
> https://www.ietf.org/mail-archive/web/sip/current/thrd19.html#18421

"SIP 3.0 is like fully participatory democracy, the ultimate form of communism, and the earthly Kingdom of God -- a thorough reform of what presently exists that will remove all of its flaws.

Similar to those other three projects, there is no WG timeline yet for SIP 3.0 development.”

Let’s start SIP 4.0 :-)

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 14 Jul 2016 08:44:28 +0200

> On 14 Jul 2016, at 03:00, Drage, Keith (Nokia - GB) <[email-masked]> wrote:
> 
Where can I see that status? I only see “standard track” and “proposed standard”.
https://www.rfc-editor.org/search/rfc_search_detail.php

I don’t agree with you here. It’s obsoleted by never declared historic as far as I
understand. What would happen if we did?
> 3)	deprecate mechanisms for interoperability of RFC 3261 with RFC 2543?
Maybe that would be the effect. Can we try to figure out what would happen?
One clear benefit highlighted seems to be to get rid of the restrictions on 
changes of the from/to headers. Now, how would that work with STIR?

/O

---

From: "A. Jean Mahoney" <[email-masked]>
Date: Thu, 14 Jul 2016 12:23:44 -0500

> understand. What would happen if we did?

The IESG has a statement on moving RFCs to Historic:

https://www.ietf.org/iesg/statement/designating-rfcs-as-historic

Basically - If the technology has been "retired", then its RFC can be 
given an "Historic" designation. If the tech is still in use, but has 
been updated by a replacement version, then the RFC is "Obsolete".

RFC 2543 is correctly classified as "Obsoleted by RFC 3265, RFC 3264, 
RFC 3261, RFC 3262, RFC 3263".

Jean

---

From: Brett Tate <[email-masked]>
Date: Thu, 14 Jul 2016 14:04:35 -0400

> > For instance, RFC 3261 section 12.2.1.1 indicates
> > an expectation that the "mandatory reflection of
> > the original To and From URI in mid-dialog requests
> > will be deprecated in a subsequent revision".  I'm
> > not sure why; however some vendors and operators want
> > to allow the To/From URI to change without any
> > restrictions (e.g. they don't want to be restricted
> > by RFC 4916).
>
> There are many call transfer scenarios involving b2bua’s
> that need to modify/update caller IDs and there are too
> many implementations pre-4916 out there.

Yes; support for RFC 3325 and RFC 5876 appears to be more common.

Updating RFC 3261 isn't necessarily going to increase support of RFC 4916 or
allow To/From URI changes in a non-controlled fashion.  As far as I know,
RFC 4916 was the solution to allow To/From URI changes; however I guess that
another one can be defined.

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 14 Jul 2016 14:23:25 -0400

> [1] https://www.ietf.org/mail-archive/web/sip/current/thrd19.html#18421

What ever happened to the proposal for "peer-to-peer-to-peer-to-peer"
SIP?  My vague memory is that it was "SIP/4.0" and was an April fool's
RFC, but its not in the Wikipedia list of same.

Dale

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 14 Jul 2016 21:08:22 +0200

> On 14 Jul 2016, at 19:23, A. Jean Mahoney <[email-masked]> wrote:
> 
> 
> 
> Basically - If the technology has been "retired", then its RFC can be given an "Historic" designation. If the tech is still in use, but has been updated by a replacement version, then the RFC is "Obsolete".
> 
> RFC 2543 is correctly classified as "Obsoleted by RFC 3265, RFC 3264, RFC 3261, RFC 3262, RFC 3263”.
THank you for the explanation Jean!

/Olle

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Fri, 15 Jul 2016 00:05:38 +0000

RFC 2026 section 4.2.4:

4.2.4  Historic

   A specification that has been superseded by a more recent
   specification or is for any other reason considered to be obsolete is
   assigned to the "Historic" level.

Datatracker page for RFC 2543:

Document 	Type 		RFC - Proposed Standard (March 1999; No errata)
Obsoleted by RFC 3265, RFC 3264, RFC 3261, RFC 3262, RFC 3263
Was draft-ietf-mmusic-sip (mmusic WG)

Regards

Keith

-----Original Message-----
From: Olle E. Johansson [mailto:[email-masked]] 
Sent: 14 July 2016 07:44
To: Drage, Keith (Nokia - GB)
Cc: Olle E Johansson; Gurbani, Vijay (Nokia - US); [email-masked]
Subject: Re: [sipcore] Declaring SIP 1.0 historic?

I don’t agree with you here. It’s obsoleted by never declared historic as far as I understand. What would happen if we did?
Maybe that would be the effect. Can we try to figure out what would happen?
One clear benefit highlighted seems to be to get rid of the restrictions on changes of the from/to headers. Now, how would that work with STIR?

/O
>>> and then if it fails, fall back to an older version.  This is why 
>>> all backward compatibility in SIP has to be single-pass.
>>