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

[Dean Willis <dean.willis at softarmor.com>]

Christer Holmberg (JO/LMF) wrote:

> "Given that the information in the signaling message always conveys
> enough information to identify the service,..."

This is, as I understand it, a cyclical definition of terminology.

The statement in question appears to be completely consistent if one 
believes that the "service" being referred to is specifiable in the 
signaling.

For example, two requests to a given URI with idential URI parameters 
and identical SDP bodies are, by this definition, requests for the same 
service.

If, however, you have a conceptual model wherein those requests might be 
to different services, despite the fact that the network is going to 
experience exactly the same loading factors, then it doesn't apply -- 
you have a different definition of "service".

Take for example two requests to a video robot, where the robot randomly 
chooses whether to display a comedic video or a product advertisement, 
and debits the user for the comedic video or credits them for watching 
the advertisement as appropriate. Both video clips are rendered in 
exactly the same codec, persist for the same duration, require the same 
bandwidth, and transmit the same number of bytes at the same priority.

If you believe that these are somehow different "services" and should be 
treated differently by the intermediate nodes, then you disagree with 
Jonathan's definition of service. If you think they're the same service, 
then you probably agree with Jonathan;s definition.

Some of the proponents of service identifiers have argued that these 
SHOULD be differentiated servcies, and that the robot in the above 
example should somehow signal "the network" appropriately so that the 
access network provider can also differentiate billing to the user.

I find this to be a very awkward idea of "service" and believe it leads 
to insurmountable problems related to the complexity of peering 
agreements (and service definitions) in the resulting environment.

--
Dean


_______________________________________________
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