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

[Hannes Tschofenig <[e-mail]>]

I minor follow-up question:

What is the meaning of
"
        <cp:actions>
         <trans-handling
                perm-uri="sip:[e-mail]">grant</trans-handling>
         <trans-handling
                perm-uri="sip:[e-mail]">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:
> 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



_______________________________________________
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