Subject: [Sipping] comments on draft-ott-sip-serv-indication-notification-00.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Jul 2007 10:52:48 -0400

It is very hard to understand what these headers are used for. There is 
just a few sentences on each header and what it means. It also uses the 
term 'service' which can mean a million things.

Looking at the values for one of the two P-headers:

P-Service-Notification = "P-Service-Notification"
                               HCOLON notification
     notification          = "user-suspended" /"user-resumed" /
                             "conference-established" /
                             "conference-disconnected" /
                             "other-party-added" /
                             "isolated" / "reattached" /
                             "other-party-isolated" /
                             "other-party-reattached" /
                             "other-party-split" /
                             "other-party-disconnected" /
                             "conference-floating" /
                             "call-is-a-waiting call" /
                             "diversion-activated" /
                             "call-transfer-alerting" /
                             "call-transfer-active" / "remote-hold" /
                             "remote-retrieval" / "call-is-diverting" /
                              TOKEN

This seems to convey a whole bunch of different things, many of which 
there exist standards today (for example, dialog package).

I think a lot more clarity is required on what these are for. I have a 
feeling it plays into the whole BLISS discussion, as my guess is that 
these are needed based on some assumed model on how features like call 
waiting works, and clearly we would not have interoperability for that 
feature if the mechanisms defined here were utilized.

<rant>
Increasingly, P-headers are being seen as a vehicle for defining 
completely different and non-interoperable versions of SIP. For a long 
time, I have argued that SIP is an Internet protocol, and like other 
Internet protocols (IP, TCP, UDP), there are no "regional variants" as 
there are in PSTN. Well, little by little we are being pushed in that 
direction, with seemingly innocuous P-headers that completely redefine 
how SIP works, ensuring that a phone that someone produces for one 
"variant" of SIP does not interwork with another. Indeed, there is also 
an increasing trend to put in P-header specs that are nothing more than 
syntax. That is also unacceptable, IMHO. It is not appropriate for 
another standards body to define semantics for SIP extensions, and 
merely use IETF as a registration body for the syntax of the header. I 
believe RFC 3427 is pretty clear that IETF owns the SIP protocol and its 
extensions. A similar trend is that other organizations are defining new 
behaviors in SIP elements that don't require new syntax per se, but 
result in non-interoperable changes to the protocol. The recent 
discussions on services in SIP and the usage of the Accept-Contact 
header field is an example of that.

This is all bad.

SIP should be SIP, and it should be the same SIP everywhere.
</rant>

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Jul 2007 12:33:47 -0400

Wow! I hadn't noticed this draft until I saw Jonathan's comments.
Now having read it I must agree with Jonathan.

What is the point of a standard if it doesn't give enough information 
for someone to implement it? For instance:

>     4.2.1 Applicability statement for the P-Service-Indication header 
>   
>     The P-Service-Indication header is applicable when an entity needs 
>     to indicate a service specific proceeding of a request or a 
>     response to an UA or a proxy. 
>      
>     4.2.2 Usage of the P-Service-Indication header 
>      
>     The P-Service-Indication header field provides an UA or a proxy 
>     with an indication how to proceed the SIP request or response in 
>     the context of a specific service. 

How does

    P-Service-Indication: CCBS

tell me, as a UA developer, what my UA should do to proceed? And under 
what circumstances would I add such a header?

This clearly seems to fall within the scope of BLISS. For this to make 
any sense I think there would need to be a service framework that gave 
meaning to all of these things.

	Paul

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 23 Jul 2007 14:12:05 +0200

I would understand that at least as far as the notification is concerned, it is mapping semantics that exist in the ISDN.

However in the ISDN the semantics for notifications were:

-	all intermediate entities pass on, with no impact on state of the entity
-	the end terminal renders to the user, with no impact on state of the entity

If we proceed with this, this probably needs to be stated in the document, using SIP terminology of course.

There were also semantics associated with these individual notifications which could probably be brought out. 

Regards

Keith

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Friday, July 13, 2007 5:34 PM
> To: Jonathan Rosenberg
> Cc: IETF Sipping List
> Subject: Re: [Sipping] commentson 
> draft-ott-sip-serv-indication-notification-00.txt
> 
> What is the point of a standard if it doesn't give enough 
> information for someone to implement it? For instance:
> 
> tell me, as a UA developer, what my UA should do to proceed? 
> And under what circumstances would I add such a header?
> 
> This clearly seems to fall within the scope of BLISS. For 
> this to make any sense I think there would need to be a 
> service framework that gave meaning to all of these things.
> 
> 	Paul
> 
> > It is very hard to understand what these headers are used 
> for. There 
> > is just a few sentences on each header and what it means. 
> It also uses 
> > the term 'service' which can mean a million things.
> > 
> > "variant" of SIP does not interwork with another. Indeed, there is 
> > also an increasing trend to put in P-header specs that are nothing 
> > more than syntax. That is also unacceptable, IMHO. It is not 
> > appropriate for another standards body to define semantics for SIP 
> > extensions, and merely use IETF as a registration body for 
> the syntax 
> > of the header. I believe RFC 3427 is pretty clear that IETF 
> owns the 
> > SIP protocol and its extensions. A similar trend is that other 
> > organizations are defining new behaviors in SIP elements that don't 
> > require new syntax per se, but result in non-interoperable 
> changes to 
> > the protocol. The recent discussions on services in SIP and 
> the usage 
> > of the Accept-Contact header field is an example of that.
> > 
> > This is all bad.
> > 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: [email-masked]
Date: Mon, 23 Jul 2007 17:09:34 -0400

The title gives almost no hint of the contents:

         Private Header (P-Header) Extensions to the Session Initiation 
           Protocol (SIP) for the support of the Services for the  
              European Telecommunications Standards Institute, 

How about:

    Private Header (P-Header) Extensions to the Session Initiation
   Protocol (SIP) within the European Telecommunications Standards
  Institute "Next Generation Networks" architecture to carry service
		    notifications and indications

Dale