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

["Christer Holmberg \(JO/LMF\)" <christer.holmberg at ericsson.com>]

Hi, 

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

I guess so.

My understaning of "service" is something which is provided to a user.
Based on the service definition you choose thee tools (protocols and
protocol elements) to implement that service.

Your definition is the complete opposite. You (and many other protocol
people) define the service based on the protocol, which also makes the
service protocol specific.
 
>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.

I do think they are different services, because they have different
definitions.

Yes, in this case, from a SIP perspective, you may be able to implement
the service in a similar way, but in my view that doesn't mean that they
are the same services.

Regards,

Christer


_______________________________________________
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