Subject: [Sip] Steps to Draft

From: Robert Sparks <[email-masked]>
Date: Wed, 2 Jul 2008 17:10:49 -0500

Please look over
http://www.ietf.org/internet-drafts/draft-sparks-sip-steps-to-draft-00.txt

as input into our discussion on advancing SIP to Draft.

Thanks,

RjS

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 03 Jul 2008 10:57:15 +0100

Robert,

This is a very good first draft. I agree that "-> Trying to progress
3261 and dependencies including widely
      implemented small updates (such as rport [RFC3581] and the non-
      INVITE fixes [RFC4320])"
is probably about the right level.

As a general point, each SIP RFC that is not normatively referenced and
mandated by RFC 3261 is an optional part of SIP. So some "core" things
like support for receipt of REFER and support for receipt of Replaces
cannot be assumed. This has encouraged B2BUAs to use 3PCC techniques to
cover common functions such as call transfer. Another non-mandatory
capability is support of receipt of UPDATE, which is a much cleaner way
of doing things like session timer refresh, for example (avoids a
further SDP offer-answer exchange). Maybe it can't be included in the
scope of advancement to Draft Standard, but mandating some of these
things (at least support on receipt) might be worth considering.

I haven't thought about it in detail, but some initial comments:

- I am sure we will find quite a few things that have to be taken out,
because of lack of implementation. One big one might be S/MIME.
- If we no longer include RFC 2543 compatibility, we might also consider
incorporating those aspects of RFC 4916 that allow the From URI to
change mid-dialog (but not the SIP Identity bits).
- I was surprised to see RFC 3204 in the dependencies, but it seems it
is just for the handling parameter. Perhaps that could just be moved
into the Draft Standard rather than trying to move RFC 3204 to Draft.
- I am sure the implementation report will need some explicit statements
on SIPS.
- SDP is now RFC 4566 (mentioned in 1.2 but not in section 2).
- Under extensibility mechanisms, handling of unknown bodies or body
parts.
- " - Demonstrate that someone will cut and paste this list into some
         inappropriate place without reading it before it's had review"
- this will probably be the easiest one to demonstrate!

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Robert Sparks
> Sent: 02 July 2008 23:11
> To: [email-masked] List
> Subject: [Sip] Steps to Draft
> 
> Please look over

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Jul 2008 13:11:05 -0400

Robert,

Thanks much for taking a stab at this.

The first thing that probably merits discussion is whether we really 
actually want to move SIP to draft. Looking through the normative 
dependencies, plus the amount of work it will require to agree upon and 
complete the interoperability reports, seems quite daunting. At the end 
of the day, do we think that exercise will improve SIP interoperability? 
Make the life of an implementor easier? Not clear.

Are folks able and willing to commit the time to doing this? That 
includes working out the implementation report contents, collecting 
data, revising the specs, chasing down dependencies, etc. We've had this 
item on our charter for a long time, yet typically make little progress 
on it. Thats kind of a sign that, folks are not viewing it as something 
that is pressing to address.

The biggest complaints I hear about the SIP specs are:

1. there are so many of them; its impossible to figure out what I need 
and figure out which ones are definitely implemented by other folks so 
that we can interoperate,

2. the specs don't line up with reality - SIP barely even mentions 
B2Buas and phone numbers yet these are the more common case

3. there are lots of interop issues - many of which were raised at the 
sip forum session a few meetings ago - that need to get solved

I don't hear too much of, "RFC3261 is confusing since it tells me to 
implement the S/MIME thing and I don't actually need to". That would be 
the main thing we'd get by moving RFC3261 to draft, I think.

So I think the first step is to really figure out, what is the PROBLEM 
out there today, that we are trying to solve here. is it just, "IETF 
process says we should go to draft?". If thats the sole problem, I'm not 
sure its worth the effort.

Flame away...

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 09 Jul 2008 14:16:15 -0700

Jonathan,

> Flame away...

These are valid considerations, but it would be much easier to move SIP to
draft standard for _Internet use only_.

Using SIP for closed networks, for a myriad of business plans and models and
B2BUA and other intermediaries is definitely not be doable, though highly
entertaining to watch. Not to mention all those successors to the IN and AIN
(no names mentioned here, but we know them well).

So my vote is in support of what Robert Sparks has proposed, just keep the
scope limited to the Internet model - see the AIB docs what that means.

Lat but not least: Both you and Robert have done a fantastic job to prove
that Internet-style SIP is interoperable, so you have a huge stake in it.

Henry

---

From: Eric Burger <[email-masked]>
Date: Wed, 23 Jul 2008 12:54:30 -0400

I would offer two courses of action:

1. Bring SIP to Draft the easy way (3261-bis), as it will eliminate a  
bunch of options that are really proprietary extensions.

2. Bring SIP to Draft the hard way (bring all related drafts  
together), as it will reduce the number of (sometimes conflicting)  
documents as well as start the clock on reducing the options that just  
don't go together.

My personal vote is for #2, but I do not think there is enough energy  
behind the effort to get it done.

On Jul 9, 2008, at 1:11 PM, Jonathan Rosenberg wrote:

> dependencies, plus the amount of work it will require to agree upon  
> and complete the interoperability reports, seems quite daunting. At  
> the end of the day, do we think that exercise will improve SIP  
> interoperability? Make the life of an implementor easier? Not clear.
>
> data, revising the specs, chasing down dependencies, etc. We've had  
> this item on our charter for a long time, yet typically make little  
> progress on it. Thats kind of a sign that, folks are not viewing it  
> as something that is pressing to address.
>
> 1. there are so many of them; its impossible to figure out what I  
> need and figure out which ones are definitely implemented by other  
> folks so that we can interoperate,
>
> 3. there are lots of interop issues - many of which were raised at  
> the sip forum session a few meetings ago - that need to get solved
>
> implement the S/MIME thing and I don't actually need to". That would  
> be the main thing we'd get by moving RFC3261 to draft, I think.
>
> So I think the first step is to really figure out, what is the  
> PROBLEM out there today, that we are trying to solve here. is it  
> just, "IETF process says we should go to draft?". If thats the sole  
> problem, I'm not sure its worth the effort.
>
> Flame away...
>
> -Jonathan R.
>
>
>
>
> Robert Sparks wrote:
>> Please look over