Subject: Re: [Sip] Comments on Resource Priority -08 (417)

From: [email-masked]
Date: Thu, 9 Jun 2005 10:19:08 EDT

In a message dated 6/6/2005 6:07:42 PM Eastern Daylight Time, 
[email-masked] writes:

> If we're talking about an automated UA (for example, the 
> thermal-overload sensor on a nuclear missile), what keeps local policy 
> (instead of a human user) from making this decision? Is there something 
> about resource-priority that prevents it from being applicable to 
> automated UAs in all possible priority spaces?
> 

In every use of this capability, the first session setup attempt must use the 
correct namespace and priority level for the attempted session. There is 
never a need for the UA to try again with different values when the first attempt 
fails. It could retry with the same values (like an auto redial on a FAX 
machine).

Mike Pierce
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: [email-masked]
Date: Thu, 9 Jun 2005 10:19:06 EDT

In a message dated 6/6/2005 11:02:18 AM Eastern Daylight Time, [email-masked] 
writes:

> > Should be changed to:
> >
> >    Upon receiving a 417 (Unknown Resource-Priority) response, the UAC
> >    MAY display to the user a list of the authorized resource values  
> > returned in the 'Accept-Resource-Priority'
> >    header field. The user may then attempt a subsequent request  
> > with the same or different resource
> >    value.
> >
> This is significantly worse, and treads pretty directly into the  
> freight train of trying to mandate user interfaces. For example, what  
> if the user is blind?
> 
> > Then it is clear that it is the human user, not the device, which  
> > is making the decision and attempting another call.
> >
> What if there isn't a human user? What if it's a robot?
> 
> I strongly prefer the existing text and frankly don't see what the  
> problem is.
> 

I thought I had explained the problem with the current text sufficiently. 
Obviously, if a blind person using a terminal, the reference above to "display" 
is understood to mean some means appropriate to a blind person.
I don't think we're concerned with "robots". If you mean a software 
application, etc. resident in the same physical device as the UA, then my description 
of the problem remains. All session setup attempts must use the correct 
namespace/priority the first time. There is no case in which a device can decide to 
use a different value if the first attempt fails.

If it helps. the word human can be left out of my suggested text above.

In a message dated 6/6/2005 11:12:45 AM Eastern Daylight Time, 
[email-masked] writes:

> In general, my philosophy is that we should stick, to the extent  
> possible, with observable behavior. If an external observer can't  
> tell if a human or a robot made the decision to call again, it seems  
> futile to try to have the protocol spec mandate human intervention. I  
> understand the need to preserve a place for humans in the world, but  
> protocol specs are probably the wrong place to prevent human-to-robot  
> outsourcing. (Similarities to the Turing test are noted.)
> 
> I suspect a better place for this is a requisition document that  
> describes how a device should indicate failures and how a user (or  
> robot) is allowed to act on these.
> 

I believe that the above is exactly what my suggested text above did.

Mike Pierce