Subject: [Ieprep] IEPREP SIP REQ other comments

From: "Gunn, Janet" <[email-masked]>
Date: Mon, 14 Oct 2002 17:54:46 -0400

In section 5, network models:

            "Restricted SIP networks: In restricted SIP networks, users may
             be restricted to particular SIP applications and cannot add
             SIP protocol elements such as header fields or use SIP
             methods beyond a proscribed set. It appears likely that
             3GPP/3GPP2 networks will fall into this category, at least
             initially."

It should be "prescribed", not "proscribed".

In section 7 the "mechanism" seems to be "the mechanism to provide priority
service", whereas in section 6 it seems to be the "mechanism for marking
call requests".

One requirement that seems to be missing, is that SIP should be able to
handle both a marking that says "I am requesting priority treatment foo for
this call, but have not yet been authorized for this call" (analogous to
dialing the prefix 710) AND a marking that says "This call has already been
authorized for priority treatment foo" (analogous to having the "calling
party category" set to "HPC").  Or am I missing something?
 
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 14 Oct 2002 20:12:34 -0400

> service", whereas in section 6 it seems to be the "mechanism for marking

I've gone through the document and tried to replace the generic 
"mechanism" by a more concrete term or omitted it where it wasn't needed.

> party category" set to "HPC").  Or am I missing something?

There are, I believe, four cases:

(1) want priority, but not yet authorized -> system should challenge 
user, which leads to case (2)

(2) priority + credentials (e.g., in SIP, a Digest authorization or an 
S/MIME-signed body)

(3) priority + network-asserted identity (NAI): The recipient of the 
request somehow has reason to believe that the NAI is correct and then 
check that the identity can request the service.

(4) priority approved by third party: Here, the recipient has reason to 
believe that the request has been vetted by a trusted third party.

I can spell out these different scenarios if people believe this to be 
helpful. For (2), (3) and (4), there are likely several different 
solutions in SIP.