Subject: [Sipping] Question regarding draft-ietf-sipping-consent-format

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 10 Jul 2007 15:15:35 +0200

Hi Gonzalo,
Hi all,

I read through draft-ietf-sipping-consent-format. Maybe I misunderstand 
something but there is potentially a bug in the spec.

Here is my understanding reading through the framework draft. The 
permission document is used in the following way:

The relay sends the permission document to the Recipient with the semantic.
"This is the policy I am going to add to your rule set. Are you OK with it?"
URIs are attached to the message to allow the Recipient to quickly grant 
or deny the permission.

In Section 5.4 of 
http://tools.ietf.org/html/draft-ietf-sip-consent-framework-02#section-5.4 
I see that a permission document must contain
* Identity of the Sender
* Identity of the Original Recipient
* Identity of the Final Recipient
* URIs to Grant Permission
* URIs to Deny Permission

I see that you addressed the first three items in your document. You put 
the identity of the sender in the <sender> element, the identity of the 
original recipient is stored in the <target> element and the final 
recipient is put into the <identity> element.

I believe that there is a bug in the sense that the Common Policy 
<identity> condition is used in a wrong way in this document.
The semantic of the <identity> element corresponds to the identity of 
the sender. Hence, you would delete the <sender> element and create a 
new element instead that denotes the final recipient, for example 
<recipientURI>. It might be useful to call the <target> element 
<targetURI> element since this would be more inline with the terminology 
used in the framework and the consent format document.

Where are the last two elements stored?

Ciao
Hannes

_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Fri, 13 Jul 2007 09:29:31 +0300

Hi Hannes,

thanks for your comments. Answers inline:

> recipient is put into the <identity> element.

Yes, that's correct.

> the sender.

There is a need to store the three elements you pointed out above 
(sender, target URI, and recipient URI). We chose to use the already 
existing <identity> element for one of them and to define two new 
elements for the other two.

We chose to use the <identity> element to store the recipient URI, and 
you suggest that we use a newly defined <recipient> element instead. We 
chose to store the recipient URI in the <identity> element because it 
will be the entity receiving traffic from the relay hosting the 
translation, the same way as a watcher (also stored in an <identity> 
element in presence-rules) receives traffic from the presence server.

As long as what to store in each element is clearly specified, I believe 
we are OK whether we use the exiting <identity> element or a newly 
defined one.

Cheers,

Gonzalo

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Jul 2007 08:53:24 +0200

Hi Gonzalo,

Gonzalo Camarillo wrote:
>> I read through draft-ietf-sipping-consent-format. Maybe I 
>> misunderstand something but there is potentially a bug in the spec.
>>
>> URIs are attached to the message to allow the Recipient to quickly 
>> grant or deny the permission.
>>
>> In Section 5.4 of 
>> I see that you addressed the first three items in your document. You 
>> put the identity of the sender in the <sender> element, the identity 
>> of the original recipient is stored in the <target> element and the 
>> final recipient is put into the <identity> element.
>
> Yes, that's correct.
>
The problem is that you have chosen a field that has a different semantic.

> you suggest that we use a newly defined <recipient> element instead. 
> We chose to store the recipient URI in the <identity> element because 
> it will be the entity receiving traffic from the relay hosting the 
Right. But for the presence authorization document the <identity> 
element has the semantic of the sending host -- not the receiving host.

>
> As long as what to store in each element is clearly specified, I 
> believe we are OK whether we use the exiting <identity> element or a 
> newly defined one.
I am not sure about that given that you then introduce a new element 
<sender> that has exactly the semantic of the <identity> element.
To me this may lead to a lot of confusion given that Common Policy is 
already used quite widely.

I am asking for a small fix. I will send the proposed text today.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Jul 2007 09:21:33 +0200

I minor follow-up question:

What is the meaning of
"
        <cp:actions>
         <trans-handling
                perm-uri="sip:[email-masked]">grant</trans-handling>
         <trans-handling
                perm-uri="sip:[email-masked]">deny</trans-handling>
        </cp:actions>
"
in the example of Section 4 of 
http://www.ietf.org/internet-drafts/draft-ietf-sipping-consent-format-03.txt?
How can a single rule carry both a grant and a deny?

How can a relay make restrictions regarding the sender's identity other 
than putting the identity of the sender into a field who has just send a 
request?
Wouldn't this typically be the job of the final recipient to figure out 
which identities are allowed to make the translation step.
In this particular case you cannot just provide a URI for permit and 
deny, which has the semantic of "YES, I want to add this policy (or "NO, 
I don't want it", respectively.)

Ciao
Hannes

Hannes Tschofenig wrote:
>>> The semantic of the <identity> element corresponds to the identity 
>>> of the sender.
>>
>> We chose to use the <identity> element to store the recipient URI, 
>> and you suggest that we use a newly defined <recipient> element 
>> instead. We chose to store the recipient URI in the <identity> 
>> element because it will be the entity receiving traffic from the 
>> relay hosting the translation, the same way as a watcher (also stored 
>> in an <identity> element in presence-rules) receives traffic from the 
>> presence server.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 13 Jul 2007 10:26:17 +0300

Hi,

one of the URIs can be used to grant the relay permission to perform the 
translation described by the conditions. The other URI can be used to 
deny the relay permission to perform the translation.

The recipient of the translation chooses which URI to click depending on 
whether we want to grant or deny.

There were discussions on placing those URIs in SIP headers instead of 
in the document itself, but at the end we decide to place the in the 
document.

Cheers,

Gonzalo