Subject: [Sipping] draft-channabasappa-sipping-app-profile-type-02

From: "Sumanth Channabasappa" <[email-masked]>
Date: Fri, 22 Feb 2008 10:13:35 -0700

Folks,

Thanks again for your comments and feedback on the initial versions of
draft-*-app-profile-type. As you recall, the document proposes an
extension to the SIP Configuration Framework, specifically the addition
of the application profile type.

Sal presented the I-D at the last WG meeting, and we have made an
attempt to address the comments provided, and to incorporate your
suggestions. 

A new version is now available at:

http://tools.ietf.org/wg/sipping/draft-channabasappa-sipping-app-profile
-type-02.txt

Further comments and feedback would be appreciated!

- Sumanth, Josh and Sal

_______________________________________________
Sipping mailing list  http://www.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: "Rajagopal Priya-W00138" <[email-masked]>
Date: Fri, 22 Feb 2008 17:24:35 -0500

Hi Sumanth , Sal ,Josh
The draft does not contain any specifics on the subscription URI to be
used with the "application" profile-type- more specifically ,the
request-URI. Are there any requirements on user part/host part of
request-URI and its relationship (if any) to the application profile
provider/PDS. 
I think inclusion of text clarifying the same will be useful

Regards
-Priya

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sumanth Channabasappa
Sent: Friday, February 22, 2008 12:14 PM
To: [email-masked]
Subject: [Sipping] draft-channabasappa-sipping-app-profile-type-02

Folks,

- Sumanth, Josh and Sal

_______________________________________________
Sipping mailing list  http://www.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
_______________________________________________
Sipping mailing list  http://www.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: "Sumanth Channabasappa" <[email-masked]>
Date: Fri, 22 Feb 2008 16:22:57 -0700

Folks,

At the last IETF it was mentioned that the proposal in
draft-dotson-sip-mutual-auth-00 is not to be considered an essential
correction. We listened! So a new version that presents the proposal as
an extension has been uploaded:

http://tools.ietf.org/id/draft-dotson-sip-mutual-auth-01.txt

As a refresher, the I-D proposes the use of the
Proxy-Authentication-Info header for Proxy-to-User authentication within
SIP. This header allows for a UA to authenticate the client during
digest authentication, thus enabling mutual authentication. This is
similar to the currently specified use of Authentication-Info header for
User-to-User authentication. It also enables limited integrity
protection, and for the proxy to provide additional details such as the
nonce to use for future authentication responses (next nonce).

We would request the WG to review the proposal and let us know if this
can be considered as a potential item for the WG or, more importantly,
if there are any objections.

Thanks!
Sumanth, Stuart and Steve

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Mon, 25 Feb 2008 15:44:22 -0700

Priya,

We can certainly add information related to profile enrollment. To
answer your question, I expect the requirements to closely follow what
has been specified for requesting the user profile currently, i.e., the
Request-URI and From fields contain the user AoR requesting application
configuration. (The user AoR can be pre-configured or obtained via a
previous profile.)

- S

-----Original Message-----
From: Rajagopal Priya-W00138 [mailto:[email-masked]] 
Sent: Friday, February 22, 2008 3:25 PM
To: Sumanth Channabasappa; [email-masked]
Subject: RE: [Sipping] draft-channabasappa-sipping-app-profile-type-02

Hi Sumanth , Sal ,Josh

Regards
-Priya

-----Original Message-----

Folks,

- Sumanth, Josh and Sal

---

From: "Rajagopal Priya-W00138" <[email-masked]>
Date: Tue, 26 Feb 2008 12:21:24 -0500

Actually, I was curious if the request-uri should in fact be the user
AoR. Couple of points -
 (1) What if the application profile is not really specific to a given
user (2) Also, what if there were multiple sources of application
profile information (like the VOD data in your example in draft)
 and client chooses one source(based on some criteria - ), then we'd
need enough information in the URI to ensure that this request gets
routed to this specific application profile source. Not sure if having
this as user AoR helps..

Based on above,doesn't it seem more appropriate for the request-uri to
point to the resource (such as the PDS hosting the application
profile(s) in our case?)
Thanks!
-Priya

-----Original Message-----
From: Sumanth Channabasappa [mailto:[email-masked]] 
Sent: Monday, February 25, 2008 5:44 PM
To: Rajagopal Priya-W00138; [email-masked]
Subject: RE: [Sipping] draft-channabasappa-sipping-app-profile-type-02

Priya,

- S

-----Original Message-----
From: Rajagopal Priya-W00138 [mailto:[email-masked]]
Sent: Friday, February 22, 2008 3:25 PM
To: Sumanth Channabasappa; [email-masked]
Subject: RE: [Sipping] draft-channabasappa-sipping-app-profile-type-02

Hi Sumanth , Sal ,Josh

Regards
-Priya

-----Original Message-----

Folks,

- Sumanth, Josh and Sal

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 27 Feb 2008 11:53:02 +0200

Priya,

I agree with Sumanth, I expect we closely follow what has been specified 
for requesting the user profile
(i.e. Request-URI and From fields contain the user AoR).

see in line.

Cheers
Sal

Rajagopal Priya-W00138 wrote:
> user 
[Sal] if the application profile is not really specific to a given user, 
the it is, so to say, general for all the user.
Or maybe you mean, what happen if the request arrives to PDS that doe 
not contain the right profile for the user.
Well, in that case the PDS should be able to understand it, and possibly 
reply with an error code.

> (2) Also, what if there were multiple sources of application
[Sal] if we want to consider the scenario where there are multiple 
source of application profile information,
and the user is aware of that, then we first need to specify how the 
user becomes aware of the fact that there are multiple source.
Moreover it would be complicate specify how a user chooses one source 
based on some criteria:
that implies the user does not only is aware that there are multiple 
source of application profile information,
but also that those sources are different, and also which are the 
differences.

IMO, the information that the user inserts in the SUBSCRIBE request 
(e.g. AoR, local network, device, user and appid)
are enough to let the request to be routed to the right PDS.

Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping

---

From: "Rajagopal Priya-W00138" <[email-masked]>
Date: Wed, 27 Feb 2008 13:35:56 -0500

Hi Sal
My responses:

Priya> Yes, if application profile is general to all users, there is no
real need to specify the end users AoR in request-URI (event is not tied
to a user, so makes more sense for request-uri to specify the
application resource if available). If app profile server needs to know
about the end-user, it can always look it up from To field 

[Sal] if we want to consider the scenario where there are multiple
source of application profile information, and the user is aware of
that, then we first need to specify how the user becomes aware of the
fact that there are multiple source.
Moreover it would be complicate specify how a user chooses one source
based on some criteria:
that implies the user does not only is aware that there are multiple
source of application profile information, but also that those sources
are different, and also which are the differences.

[Priya] There may be several ways how the PDS of app profile may be
identified and I don't think it has to be in scope of this doc. For
example, consider multiple IPTV SP environment wherein a user may be
serviced by multiple SPs- Each SP has own PDS(es) with some app service
information(example- VoD service information). The end user identifies
the SP domain and associated PDS that the user needs to connect first
via configuration obtained during remote config of device, DHCP options
etc. . Client then sends request to specific PDS. Ofcourse if end client
does not have this info, then it does not specify that in request-uri
and routing infrastructure takes care of it.

Anyway, I don't have an issue with user AoR being specified in
request-URI as long as the user AoR does not necessarily correspond to a
specific user on the device. It can be a user AoR that is associated
with a list of applications. 

All I would like is flexibility to enable end client to choose from
where it needs to get application profile from (in circumstances when it
has this information available). Don't see any reason why this should be
restricted.

regards

-Priya
-----Original Message-----
From: Salvatore Loreto [mailto:[email-masked]] 
Sent: Wednesday, February 27, 2008 4:53 AM
To: Rajagopal Priya-W00138
Cc: Sumanth Channabasappa; [email-masked]
Subject: Re: [Sipping] draft-channabasappa-sipping-app-profile-type-02

Priya,

I agree with Sumanth, I expect we closely follow what has been specified
for requesting the user profile (i.e. Request-URI and From fields
contain the user AoR).

see in line.

Cheers
Sal

> (2) Also, what if there were multiple sources of application profile 
> information (like the VOD data in your example in draft)  and client 
> chooses one source(based on some criteria - ), then we'd need enough 
> information in the URI to ensure that this request gets routed to this

> specific application profile source. Not sure if having this as user 
> AoR helps..
>   
[Sal] if we want to consider the scenario where there are multiple
source of application profile information, and the user is aware of
that, then we first need to specify how the user becomes aware of the
fact that there are multiple source.
Moreover it would be complicate specify how a user chooses one source
based on some criteria:
that implies the user does not only is aware that there are multiple
source of application profile information, but also that those sources
are different, and also which are the differences.

IMO, the information that the user inserts in the SUBSCRIBE request
(e.g. AoR, local network, device, user and appid) are enough to let the
request to be routed to the right PDS.

> has been specified for requesting the user profile currently, i.e., 
> the Request-URI and From fields contain the user AoR requesting 
> application configuration. (The user AoR can be pre-configured or 
> obtained via a previous profile.)
>
> - S
>

> extension to the SIP Configuration Framework, specifically the 
> addition of the application profile type.
>

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Wed, 27 Feb 2008 11:43:55 -0700

Priya,

I agree that the application profile delivery should support multiple
scenarios, such as the ones you indicate. The idea behind the AoR
suggestion that Sal and I suggested is not to be restrictive. If an
implementation chooses to provide a specific AoR for use within the
Request-URI, it should be able to do so (e.g., via other profiles that
are provided). Such an AoR will also be included in the "From" field and
can be used for authentication of application profile requests. 

In summary, per my understanding, you want us to clarify the population
of the mentioned fields in the document. If so, I concur.

WG,
Are there any other comments and suggestions (from Priya or other
interested parties on the mailing list)?

Thanks!
- S

-----Original Message-----
From: Rajagopal Priya-W00138 [mailto:[email-masked]] 
Sent: Wednesday, February 27, 2008 11:36 AM
To: Salvatore Loreto
Cc: Sumanth Channabasappa; [email-masked]
Subject: RE: [Sipping] draft-channabasappa-sipping-app-profile-type-02

Hi Sal
My responses:

regards

-Priya
-----Original Message-----
From: Salvatore Loreto [mailto:[email-masked]] 
Sent: Wednesday, February 27, 2008 4:53 AM
To: Rajagopal Priya-W00138
Cc: Sumanth Channabasappa; [email-masked]
Subject: Re: [Sipping] draft-channabasappa-sipping-app-profile-type-02

Priya,

see in line.

Cheers
Sal

---

From: "Rajagopal Priya-W00138" <[email-masked]>
Date: Wed, 27 Feb 2008 17:03:52 -0500

Thanks for the clarification, Sumanth.

I agree with your summary/proposal

-Priya 

-----Original Message-----
From: Sumanth Channabasappa [mailto:[email-masked]] 
Sent: Wednesday, February 27, 2008 1:44 PM
To: Rajagopal Priya-W00138; Salvatore Loreto
Cc: [email-masked]
Subject: RE: [Sipping] draft-channabasappa-sipping-app-profile-type-02

Priya,

WG,

Thanks!
- S

-----Original Message-----
From: Rajagopal Priya-W00138 [mailto:[email-masked]]
Sent: Wednesday, February 27, 2008 11:36 AM
To: Salvatore Loreto
Cc: Sumanth Channabasappa; [email-masked]
Subject: RE: [Sipping] draft-channabasappa-sipping-app-profile-type-02

Hi Sal
My responses:

regards

-Priya
-----Original Message-----
From: Salvatore Loreto [mailto:[email-masked]]
Sent: Wednesday, February 27, 2008 4:53 AM
To: Rajagopal Priya-W00138
Cc: Sumanth Channabasappa; [email-masked]
Subject: Re: [Sipping] draft-channabasappa-sipping-app-profile-type-02

Priya,

see in line.

Cheers
Sal