Subject: [Sipping] Structure of Service Indicator draft

From: Eric Burger <[email-masked]>
Date: Mon, 14 May 2007 14:58:53 -0400

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."

* I would offer that such a filter will look at much more than document
type.  In particular, it probably would make sure the document type matches
the authenticated source.  I doubt if you were paranoid enough to have a
network message spam filter you would accept device configuration commands
from any random sender.

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

_______________________________________________
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