[Sip] Re: WGLC: Comments on draft-ietf-sip-consent-framework-00.txt

[Gonzalo Camarillo <[e-mail]>]

Hi AC,

thanks for your comments. Answers inline:

Mahendran, AC wrote:
> Hi Gonzallo,
> 
> Here are my comments on draft-ietf-sip-consent-framework-00.
> 
> 1) Section 2 (editorial) " Translation operation: Operation by which
> a relay translates the request URI of an incoming request (i.e., the
> target URI) into one or more URIs (i.e., recipient URIs) which are
> used as the request URIs of one or more outgoing requests.
> 
> Replace 2 instances of the "request URI" with "Request-URI".

Done.

> 
> 2) Section 3 (editorial)
> 
> "Thus, an essential aspect of a relay is that of translation.  When a
>  relay receives a request, it translates, following its translation 
> logic, the Request-URI into one or more additional URIs."
> 
> Add "(target URI)" after "Request-URI" and "(recepient URIs)" after
> "one or more additional URIs".

Done. Taking into account Mary's comments as well, this text now looks 
as follows:

    Thus, an essential aspect of a relay is that of translation.  When a
    relay receives a request, it translates the Request-URI (target URI)
    into one or more additional URIs (recipient URIs).  Through this
    translation operation, the relay can create outgoing requests to one
    or more additional URIs, thus creating the consent problem.

> 3) Section 4 (Editorial)
> 
> It would be good to add a few descriptive words to describe the
> ordering in the sequence of operations (i.e., manipulation,
> permission request, permission grant). Though strictly there is no
> ordering, normally, manipulation triggers permission requests, which
> then triggers permission grant.
> 

I have added the following sentence:

   The manipulation of a relay's translation logic typically causes the
   relay to send a permission request, which in turn causes the recipient
   to grant or deny the relay permissions for the translation.


> 4)Section 4.3 (Editorial):
> 
> "Nevertheless, users are not on-line all the time and, so, sometimes
> are not able to receive MESSAGE requests."
> 
> Replace "Nevertheless" with "However".

Done.

> 
> 5) Section 4.4:
> 
> "Consequently, recipients provide relays with permissions using SIP 
> PUBLISH requests or HTTP GET requests."
> 
> What are the contents/body of the PUBLISH request?

I already clarified that they contain empty bodies when addressing Ben's
comments on this document.

> Why only HTTP GET? Why can't the recepient use HTTP(XCAP) PUT to
> update the permissions document in the relay?

There is no need to define multiple methods to do one thing. With one
method is enough. Note that this framework is applicable to clients that
do not support XCAP.

> Btw, is PUBLISH the only SIP method for the recepient to provide 
> permissions? Why not allow MESSAGE as well?

The same reason as above. We want a single method to do this.


> 6) Section 5.6.1:
> 
> "Otherwise, the PUBLISH request SHOULD be responded with a 401 
> (Unauthorized) response and MUST NOT be processed further."
> 
> The reason for SHOULD (as supposed to MUST) needs to be explained
> here. (The same comment applies to 5.6.2, 5.6.4).

when talking about response codes, specs generally use "SHOULD" because
the server may have a reason to use a different status code. This is a
general practice and I do not think we should spend time explaining it
in this document.


> 7) Section 5.8
> 
> "At any time, if a client wants to revoke any permission, it uses the
>  URI it received in the permission document to deny the permissions
> it previously granted.  If a client loses this URI for some reason,
> it needs to wait until it receives a new request produced by the 
> translation. "
> 
> The usage of "client" in this paragraph is confusing. Based on the 
> architecture diagram, it'd be better if we use "recepient" instead of
>  "client".

Done.

> 
> 8) Section 5.8
> 
> In figure 5, when the relay receives the REFER message, it needs to
> know which permissions document to the send to the recepient (for
> example, the recepient may be a part of multiple SIP URI lists). How
> does the relay server know which document [e-mail] is requesting
> for?

because the relay created the URI that was placed in the Trigger-Consent
header field when it performed the translation. Therefore, the relay can
correlate the incoming REFER (note that we have agreed in a different
thread to use PUBLISH instead, although that does not affect this
discussion) with the translation the relay performed previously.


I have posted a working copy of the new revision of this draft at:

http://users.piuha.net/gonzalo/temp/draft-ietf-sip-consent-framework-01.txt

Cheers,

Gonzalo


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