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

[Hannes Tschofenig <[e-mail]>]

Hi Gonzalo,

Gonzalo Camarillo wrote:
> Hi Hannes,
>
> thanks for your comments. Answers inline:
>
> Hannes Tschofenig wrote:
>> 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.
>
> Yes, that's correct.
>
>> 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.
>
> 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.
The problem is that you have chosen a field that has a different semantic.

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

>
> Cheers,
>
> Gonzalo



_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP