Subject: Re: [Sipping] Structure of Service Indicator draft

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 04 Jul 2007 00:26:03 -0400

Eric Burger wrote:
> I love the way it is constructed.  Throughout section 4, I was noting
> comments about how you can disambiguate ALL of the use cases.  Then I got to
> section 6, where we debunk many of the myths.  My guess is folks that do not
> have a clue that want a service indicator will say, "Look the IETF says
> there is a use for it."  Folks with a clue in all the standards bodies will
> say, "Right, and the answer is 'do not do it.'"
> 
> However, I would offer that section 5 is not quite as satisfying for me.
> Again, one can disambiguate all of the use cases in section 5.  The "do not
> filter my IPTV request because I am not calling someone on my white list"
> gets handled by proper construction of the outbound proxy.  If the outbound
> proxy does not understand IPTV, it will always block the IPTV request, even
> if there is an IPTV service indicator.  The "do not filter configuration
> scripts" gets handled by proper handling of document type.*  The dispatch to
> devices case work if we stop the madness and realize that a single physical
> device can have multiple SIP User Agents on it, and simply have the right
> user agents register the right AOR.
> 
> I would almost rather see a rebuttal to each section 5.x scenario close by.
> However, that breaks what I think is a beautiful flow:
>  3.   Reasons you want to identify a service
>  4+5. Reasons you think you need a service identifier
>  6.   Proof a service identifier will screw you
> 
> I would offer that the text in section 6 explicitly tie back to the examples
> in sections 4 and 5, so that we do not have 3GPP coming back to us saying,
> "Yes, but you did not explicitly say use case 5.mumble was handled, so we
> must route on a service identifier."

Fortunately this hasn't been a problem.

I think section 6 does do some of this. Fraud is explicitly discussed 
and that ties directly to the requirements around accounting and 
billing. Interoperability failures are exactly what happens when you try 
and use the explicit identifier for dispatch, and this is called out in 
6.2.2.

So, AFAICT, section 6 does what you want. Can you point to specific 
places where it is lacking?

Thanks,
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