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

From: [email-masked]
Date: Mon, 6 Jun 2005 10:12:18 EDT

In a message dated 5/29/2005 5:39:51 PM Eastern Daylight Time, 
[email-masked] writes:

> Note that it says "a subsequent request". This does not imply that the 
> UAC "redials". It simply tells the UAC and its user what values are 
> permitted for future calls, for example. A user agent could, for 
> example, display such values where known. The user interface is clearly 
> beyond the scope of the draft.
> 
> I don't see the need to change this.
> 
> > Section 4.7.1 2nd paragraph states that "Upon receiving a 417, the UAC 
> > MAY attempt a subsequent request with the same or different resource 
> > value." This is contrary to the policies for using priority values and 
> > should not be mentioned. The user (human) is supposed to select the 
> > correct value before requested a call setup. A UAC must never 
> > automatically attempt another request using a different resource value 
> > upon receipt of a 417. Of course, a human user may choose to do whatever 
> > they are authorized to do when trying a new call, but no device can be 
> > allowed to do this automatically, since it would be violating the 
> > policies for the use of priority levels.
> > 
> 
> 
As I commented, the text clearly indicates that the "UAC" (i.e., the physical 
device, not the human) may attempt a subsequent request. There should be no 
implication that it is permissable for the UAC to do this while text that says 
that a human user might do this is okay. It should describe only what the UAC 
"MAY" do in support of this. The current paragraph which says:

   Upon receiving a 417 (Unknown Resource-Priority) response, the UAC
   MAY attempt a subsequent request with the same or different resource
   value.  If available, it SHOULD choose authorized resource values
   from the set of values returned in the 'Accept-Resource-Priority'
   header field.

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.

Then it is clear that it is the human user, not the device, which is making 
the decision and attempting another call.

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: "David R. Oran" <[email-masked]>
Date: Mon, 6 Jun 2005 10:57:59 -0400

On Jun 6, 2005, at 10:12 AM, [email-masked] wrote:

> As I commented, the text clearly indicates that the "UAC" (i.e.,  
> the physical device, not the human) may attempt a subsequent  
> request. There should be no implication that it is permissable for  
> the UAC to do this while text that says that a human user might do  
> this is okay. It should describe only what the UAC "MAY" do in  
> support of this. The current paragraph which says:
>
This seems perfectly reasonable to me.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 6 Jun 2005 11:10:51 -0400

> I strongly prefer the existing text and frankly don't see what the  

I'm obviously with David here.

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.

Henning

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 6 Jun 2005 12:13:10 -0400

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> David R. Oran
>

In that case, the UA should be making the request at the priority level that
policy sets for that robot.  (If there is no resource shortage, submitting a
request at a high priority has the same effect as submitting it at a low
priority.  If there is a resource shortage, submitting it at a low priority
first is a duplication of effort.  Like in a "Vickrey auction", the optimal
behavior is to submit your first request with the highest priority you're
willing to request.)

> I strongly prefer the existing text and frankly don't see what the

On one hand, as Henning says, this isn't really a protocol question.  On the
other hand, what one says in the protocol documents does influence how
people implement the agents that perform the protocol.  From a protocol
point of view, it is OK to say "If a request is rejected due to inadequate
priority, it is acceptable for the UA to submit it again at a higher
priority".  But in practice, these words will cause some idiot to write a UA
that will automatically rachet a request from "routine" to "priority" and
all the way up to "strategic nuclear attack notice" until it gets accepted.

In think that within the human context of this document, we really want to
have some wording that makes it clear that a UA is not allowed to upgrade a
request "on its own", but only under the direction of a user or an
administrative policy.  But most of the time, that should only happen
because a user normally omits to specify the priority of a high-priority
message because normally there is no resource shortage, and it saves dialing
effort.

Dale

---

From: "Ken Carlberg" <[email-masked]>
Date: Mon, 6 Jun 2005 13:13:16 -0400

> On one hand, as Henning says, this isn't really a protocol question.  
> On the other hand, what one says in the protocol documents does 
> influence how people implement the agents that perform the protocol.  
> From a protocol point of view, it is OK to say "If a request is 
> rejected due to inadequate priority, it is acceptable for the UA 
> to submit it again at a higher priority".  But in practice, these 
> words will cause some idiot to write a UA that will automatically 
> rachet a request from "routine" to "priority" and all the way up 
> to "strategic nuclear attack notice" until it gets accepted.

I sympathize with your concern, but there is no assurance that human
discipline (following an organizational policy) will avoid racheting
up the requests.  Systems like AUTODIN, GTPS, etc. were specifically
engineered to take that ability out of the user's hands.  hopefully,
we can do better than those systems in the future.

security credentials, non-user-manipulated distributed policy, and
RFPs are the avenues that will address your concern -- all being 
outside whether new attempts are automated or a function of user
decision.

I'm with Dave and Henning in leaving the text as is.

-ken

---

From: Dean Willis <[email-masked]>
Date: Mon, 6 Jun 2005 17:07:38 -0500

On Jun 6, 2005, at 9:12 AM, [email-masked] wrote:
>
>  As I commented, the text clearly indicates that the "UAC" (i.e., the 
> physical device, not the human) may attempt a subsequent request. 
> There should be no implication that it is permissable for the UAC to 
> do this while text that says that a human user might do this is okay. 
> It should describe only what the UAC "MAY" do in support of this. The 
> current paragraph which says:
>
>     header field. The user may then attempt a subsequent request with 
> the same or different resource
>     value.
>
>  Then it is clear that it is the human user, not the device, which is 
> making the decision and attempting another call.

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?

--
Dean

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 06 Jun 2005 18:22:13 -0500

At 12:13 PM 6/6/2005 -0400, Dale Worley wrote:
> From a protocol

We can write the protocol spec perfectly that can still result in an idiot 
coding it incorrectly. Specs don't prevent this idiocy from occurring 
(unfortunately)

>Dale

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.