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

[Gonzalo Camarillo <[e-mail]>]

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

Hannes Tschofenig wrote:
> 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