Subject: RE: [Sipping] Comment on request history discussion

From: "Mark Watson"<[email-masked]>
Date: Tue, 19 Mar 2002 13:41:05 -0000

Ben,

Noone is arguing that your approach below is not valid, but it too has
limits. I don't think you can argue in general that one approach is 'more
limiting' than another - both approachs have their applications.

As Mary pointed out, there are scenarios where it is not easy to embed the
required service knowledge in the 'core device' and it is better to let the
'downstream device' (which after all is providing the actual service) do
what it will with the information provided.

The only knowledge needed in the 'core device' is that the request be
forwarded to a particular URI - it does not need to 'make the decision to
forward the request to the voice mail server' as you suggest below - it does
not need to know what the 'downsteam device' is, just that the user wants
the request to go there.

Indeed, if the 'core device' *does* know that the service is 'voice mail',
i.e. it has voicemail-specific logic embedded in it, then your approach, or
a mixture of the two, does provide additional possibilities.

Regards...Mark

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: 18 March 2002 16:35
> To: Sipping
> Subject: [Sipping] Comment on request history discussion
> 
> 
> Apologies for not airing this in the meeting--we ran out of 
> time on the
> subject just as I was figuring out how to word my concern.
> 
> Robert and Dean (and others) pointed out the distinction 
> between a  core
> device telling a downstream device the history of a request 
> and letting it
> choose its behavior vs. the core device specifically telling 
> the downstream
> device what to do.
> 
> In a voice mail example, the core device (I will assume it is 
> a proxy for
> the rest of this note) must make the decision to forward the 
> request to the
> voice mail server in the first place. That in itself was a choice of
> behavior. The history draft makes an implicit assumption that 
> the proxy
> knows that all voice mail like behavior goes to the same 
> device, that is,
> the history approach forces us into a certain service decomposition.
> 
> But what if I want to build a voice mail service where busy 
> conditions and
> no-answer conditions result in forwarding to two separate devices?
> 
> IMO, the history approach in this particular application is 
> considerably
> _more_ limiting than the approach of allowing the proxy to select the
> end-point behavior through a well selected URL.
> 
> 
> _______________________________________________
> 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
>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 19 Mar 2002 11:25:40 -0600

Mark Watson wrote:
> limits. I don't think you can argue in general that one approach is 
> 'more limiting' than another - both approachs have their applications.
> 
> As Mary pointed out, there are scenarios where it is not easy to embed 
> the required service knowledge in the 'core device' and it is better to 
> let the 'downstream device' (which after all is providing the actual 
> service) do what it will with the information provided.
> 
> forwarded to a particular URI - it does not need to 'make the decision 
> to forward the request to the voice mail server' as you suggest below - 
> it does not need to know what the 'downsteam device' is, just that the 
> user wants the request to go there.
> 
> Indeed, if the 'core device' *does* know that the service is 'voice 
> mail', i.e. it has voicemail-specific logic embedded in it, then your 
> approach, or a mixture of the two, does provide additional possibilities.

I think I made my point badly. All the core device need to know is that, 
when a certain condition occurs, it forwards the request to a certain 
URI. It in know way had to know that that URI represents a voice mail 
service. That knowledge belongs to a higher layer (i.e the brain of the 
user, or the provisioning system.)