Subject: [Sipping] New Version Notification for draft-channabasappa-sipping-app-profile-type-00

From: Salvatore Loreto <[email-masked]>
Date: Tue, 13 Nov 2007 21:39:58 +0200

Hi,

we have submitted the following draft:
 
"Extension to the ua-profile Event Package to Support the Application
Profile Type"

http://www.ietf.org/internet-drafts/draft-channabasappa-sipping-app-profile-type-00.txt

Comments and feedback appreciated.

Salvatore Loreto

On Sun, 2007-11-11 at 23:37 -0500, IETF I-D Submission Tool wrote:
> A new version of I-D, draft-channabasappa-sipping-app-profile-type-00.txt has been successfuly submitted by Sumanth Channabasappa and posted to the IETF repository.
> 
> Filename:	 draft-channabasappa-sipping-app-profile-type
> Revision:	 00
> Title:		 Extension to the ua-profile Event Package to Support the Application Profile Type
> Creation_date:	 2007-11-11
> WG ID:		 Independent Submission
> Number_of_pages: 9
> 
> Abstract:
> The SIP User Agent profile delivery framework describes how a User
> Agent can retrieve its data using a variety of protocols and defines
> a SIP event package for notifications of changes to those profiles.
> This document extends that event package to support the application
> profile type.
>                                                                                   
> 
> 
> The IETF Secretariat.
> 
> 

_______________________________________________
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: "Ganesan Sam-W00184" <[email-masked]>
Date: Wed, 14 Nov 2007 13:41:13 -0500

Preamble to the rest of my message... I just did a quick read through
and my first comment is about section 3.3... Obvously it needs more
thoght but here are my first reactions.

I think I would like it better if 3.3 reads

3.3 SUBSCRIBE Bodies
This draft defines an enhancements to the
[I-D.ietf-sipping-config-framework] specifying a use for the SUBSCRIBE
request body.  If the appid parameter contained a list of applications,
the body of the SUBSCRIBE SHOULD include appropriate bodies for each of
the applications for which the user-agent is subscribing, in the same
order in which they are listed in the appid parameter.  If present in
the SUBSCRIBE request, the body SHALL be used by the each of the
application specific PDS's to tailor the NOTIFY responses to the
subscriber User-agent for each of the applications listed. 

I realize that we could almost end up with a multipart mime body to the
subscribe, but if you stick multiple apps in as a "compound
subscription", I am afraid it is a bit hard to avoid

Sam

-----Original Message-----
From: Salvatore Loreto [mailto:[email-masked]] 
Sent: Tuesday, November 13, 2007 2:40 PM
To: [email-masked]
Subject: [Sipping] New Version Notification for
draft-channabasappa-sipping-app-profile-type-00

Hi,

http://www.ietf.org/internet-drafts/draft-channabasappa-sipping-app-prof
ile-type-00.txt

Salvatore Loreto

On Sun, 2007-11-11 at 23:37 -0500, IETF I-D Submission Tool wrote:
> A new version of I-D,
draft-channabasappa-sipping-app-profile-type-00.txt has been successfuly
submitted by Sumanth Channabasappa and posted to the IETF repository.
> Agent can retrieve its data using a variety of protocols and defines a

> SIP event package for notifications of changes to those profiles.

_______________________________________________
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: Salvatore Loreto <[email-masked]>
Date: Wed, 14 Nov 2007 21:50:35 +0200

Hi Sam,

thanks for your comments.

This is a first version of the draft and as you have certainly seen
reading the draft there are different open issues and open points to be
discussed.

The idea of multiple to have multiple apps within of the appid parameter
in the SUBSCRIBE has been thought as an optimization.

Normally an UA will subscribe to receive data profile for different or
also for all the application that are installed. So the idea is to avoid
if possible multiple SUBSCRIBE or at least reduce the number to the
minimum possible.

Of course if a user subscribes with an single SUBSCRIBE request to
multiple applications, it should be possible insert different bodies
(for filtering) in the subscribe each related to one of the different
applications, following the same order in which they are listed in the
appid parameter.
In this scenario multipart mime body seems also to me an acceptable
solution.

Sal

---

From: "Ganesan Sam-W00184" <[email-masked]>
Date: Wed, 14 Nov 2007 15:56:58 -0500

My thoughts on compund subscriptions are that I would like to avoid them
if at all possible and revert to individual subscriptions.  Compund
subscribe's can lead to some complicated cases, like for example

The recipient of the compund subscribe then has to say break out
individual subscribes to individual pds entities.  Now it becomes a
NOTIFY aggregator of some sort. Or does it send a 3xx of some sort and
get out of the way.  Does it do it to each of the individual apps?? Or
is grouped redirects allowed.  All fo these lead to some implementation
difficulties that can be painful.  So if anything I would consider the
compund subscribe very very carefully... Having said that if the
requirements for this draft are that it supports subscriptions against
multiple apps....

Enough rambling, I am getting off my soap box

Sam

-----Original Message-----
From: Salvatore Loreto [mailto:[email-masked]] 
Sent: Wednesday, November 14, 2007 2:51 PM
To: Ganesan Sam-W00184
Cc: [email-masked]
Subject: RE: [Sipping] New Version Notification
fordraft-channabasappa-sipping-app-profile-type-00

Hi Sam,

Sal

> request body.  If the appid parameter contained a list of 
> applications, the body of the SUBSCRIBE SHOULD include appropriate 
> bodies for each of the applications for which the user-agent is 
> subscribing, in the same order in which they are listed in the appid 
> parameter.  If present in the SUBSCRIBE request, the body SHALL be 
> used by the each of the application specific PDS's to tailor the 
> NOTIFY responses to the subscriber User-agent for each of the
applications listed.
> 
> 
> I realize that we could almost end up with a multipart mime body to 
> the subscribe, but if you stick multiple apps in as a "compound 
> draft-channabasappa-sipping-app-profile-type-00.txt has been 
> successfuly submitted by Sumanth Channabasappa and posted to the IETF
repository.

> > a

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 14 Nov 2007 17:31:51 -0500

Within draft-channabasappa-sipping-app-profile-type-00 section 3.1, the
application-value ABNF does not comply with the generic-param provided
by RFC 3265.  One alternative is to comma separate them within a single
quoted string instead of comma separating the quoted strings
(appid="app1,app2").  Another alternative is to allow multiple appid
parameters (appid=app1;appid=app2) within the header.

-brett

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Wed, 14 Nov 2007 15:46:25 -0700

Brett,

You are right (Josh indicated it) - and we added a last minute note to
verify this, and modify later.

- S

-----Original Message-----
From: Brett Tate [mailto:[email-masked]] 
Sent: Wednesday, November 14, 2007 3:32 PM
To: Salvatore Loreto; Sumanth Channabasappa; [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] New Version Notification for

-brett

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Nov 2007 18:34:39 -0500

> parameters (appid=app1;appid=app2) within the header.

Multiple instances of the same parameter within a header has never been 
allowed. (Its not in the ABNF because there is no way to say that in 
ABNF, but it is normative in the text.) And I know implementations 
depend on that. So please don't suggest changing it.

	Paul

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 15 Nov 2007 07:04:18 +0200

Hi Sam,

as I said in my previous mail, compound subscription has been thought an
optimization, but I agree that it need to be drafted in a very careful
way to not end up in a complicated scenario.

>From my personal point of view a UA should be free to use individual or
compounded subscription; 
he should choose compound only if he is pretty sure that all the
applications he inserts in the appid parameter are managed by only one
PDS; if he is not sure he should go for several individual
subscriptions.

sal

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 15 Nov 2007 07:13:16 +0200

Hi Paul,

thanks for your suggestion,
as Sumanth has underlined we are conscious of the mistake in the current
version of the draft and will fix in the next one.
Of course we won't use multiple appid parameter within the header, it is
not our intention at all.

Our current idea is instead to list the different application in a
quoted string (or should we call list?) of comma separating value:
appid="app1,app2"
Do you think it is correct?  

Sal

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Nov 2007 09:32:52 -0500

> Do you think it is correct?  

It is certainly a valid way to do it, and I don't have a better way.

	Thanks,
	Paul