RE: [Sipping] I-D on service identification now available

[<Markus.Isomaki at nokia.com>]

Hi Jonathan,

Thanks for putting this together. 

One of the points that you make in the draft is that the SIP signaling
itself contains enough information on the "service", without the need
for an additional explicit identifier. In the IPTV vs. multimedia
conferencing case you suggest that it is the target URI that makes the
difference:

   IPTV vs. Multimedia Conferencing:  The two services in Section 4.1
      appear to have identical signaling.  They both involve audio and
      video streams, both of which are unidirectional.  Both might
      utilize the same codecs.  However, there is another important
      difference in the signaling - the target URI.  In the case of
      IPTV, the request is targeted at a media server or to a particular
      piece of content to be viewed.  In the case of multimedia
      conferencing, the target is a conference server.  The
      administrator of the domain can therefore examine the two Request-
      URI, and figure out whether it is targeted for a conference server
      or a content server, and use that to derive the service associated
      with the request.

This is all true. However, what if the caller and the server are in
different domains, and caller's domain wants to enforce some policy
based on what the service is. For instance the one that is explained in
the draft itself:

   Frequently, a network administrator will want to authorize whether a
   user is allowed to invoke a particular service.  Not all users will
   be authorized to use all services that are provided.  For example, a
   user may not be authorized to access IPTV services, whereas they are
   authorized to utilize multimedia processing.  A user might not be
   able to utilize a multiplayer gaming service, whereas they are
   authorized to utilize voice chat services.

Request-URI is totally opaque to the caller and caller's domain. Neither
of them can know without some further information, whether INVITE is
destined to IPTV session or a video conference.

I agree with all the problems that explicit identifiers cause, but how
to deal with this case.

Regards,
	Markus 


>-----Original Message-----
>From: ext Jonathan Rosenberg [mailto:jdrosen at cisco.com] 
>Sent: 07 May, 2007 19:42
>To: IETF Sipping List
>Subject: [Sipping] I-D on service identification now available
>
>During the Prague IETF, we discussed producing a document that 
>is an expository on the architectural principles behind 
>service identification
>- what it means, why people want it, what the perils are. I've 
>now finished this, and posted it. Until it appears, you can 
>pick it up here:
>
>http://www.jdrosen.net/papers/draft-rosenberg-sipping-service-i
>dentification-02.txt
>
>This is a complete rewrite of the previous document, following 
>the outline I proposed in Prague.
>
>Thanks,
>Jonathan R.
>-- 
>Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
>Cisco Fellow                                   Parsippany, NJ 
>07054-2711
>Cisco Systems
>jdrosen at cisco.com                              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 
>sip-implementors at cs.columbia.edu for questions on current sip 
>Use sip at ietf.org for new developments of core SIP
>


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP