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

[Gonzalo Camarillo <[e-mail]>]

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.

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



_______________________________________________
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