Subject: [Sipping] WGLC: Comments on draft-ietf-sip-consent-framework-00.txt

From: "Mahendran, AC" <[email-masked]>
Date: Tue, 17 Oct 2006 14:13:13 -0700

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

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

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.

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

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? Why only HTTP GET?
Why can't the recepient use HTTP(XCAP) PUT to update the permissions
document in the relay?

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

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

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

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 [email-masked] is requesting for? 

Thanks,
AC

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 25 Oct 2006 16:18:48 +0300

Hi AC,

thanks for your comments. Answers inline:

Mahendran, AC wrote:
> 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.
> 

Done.

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

> "Nevertheless, users are not on-line all the time and, so, sometimes
> are not able to receive MESSAGE requests."
> 

Done.

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

> permissions? Why not allow MESSAGE as well?

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

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

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

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 [email-masked] 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