Subject: [Sipping] WGLC closed, requesting IETF LC on draft-ietf-sipping-3pcc-00.txt

From: "Dean Willis" <[email-masked]>
Date: Mon, 13 May 2002 13:05:23 -0500

Just a heads-up, we've requested IETF Last Call on the 3PCC draft

Well, actually, it's technically IESG Review for s BCP instead of IETF
Last Call, but the process is essentially similar -- discuss,  change
(cycle) bless, publish as RFC . . .

In any case, this is basically your chance to get any final comment in.

--
Dean

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

---

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Wed, 15 May 2002 09:48:25 -0400

Inline [RRR]

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: Tuesday, May 14, 2002 7:14 PM
To: Roy, Radhika R, ALASO
Cc: Sipping (E-mail)
Subject: Re: [Sipping] WGLC closed, requesting IETF LC on
draft-ietf-sipping-3pcc-00.txt

> > Figure 11 - Mid-Call Announcement (Flow 11 - BYE):

Sounds like a job for the call events package with SUBSCRIBE/NOTIFY. I
strongly agree that INFO is not the right way to do it. Besides, INFO is not
allowed to affect call state.

[RRR] Can we mention in the draft that SUBSCRIBE/NOTIFY is another alternative in SIP (instead of mentioning HTTP only as an example)?

cheers,
(-:bob

---

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Thu, 16 May 2002 11:43:43 -0400

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Thursday, May 16, 2002 10:15 AM
To: [email-masked]
Cc: Bert Culpepper; 'Bob Penfield'; Roy, Radhika R, ALASO; 'Sipping
(E-mail)'

Inline [RRR]

Eric Burger wrote:
> 
> My $0.02:
> 
> 1. From RFC2976:
>      The intent of the INFO method is to allow for the carrying
>      of session related control information that is generated
>      during a session.
> 
> That tells me that a media server telling an application server that
> something's happened is very much in scope.

To be honest, I really regret that we ever published INFO as an RFC. It
has become the repository for people to do all kinds of non-standard,
non-interoperable stuff and call it "standards based". I have proposed
that RFC 2976 be revved to tighten its usage scenarios, and I feel even
more strongly now based on this discussion. In fact, I would go so far
as to propose that INFO be limited to ONLY carry PSTN signaling as in
the current SIP-T usage. If you want to do anything else, we need to
look at the specific problem and define the appropriate mechanism for
it.

[RRR]	The best way to solve problems is the revise INFO RFC 2976
immediately. We do not like to see that vendors are supplying
non-interoperable (SIP) products.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com