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

From: "Ganesan Sam-W00184" <[email-masked]>
Date: Fri, 4 Apr 2008 08:11:02 -0400

I just around to reading the entire draft in some detail, probably less
detail than it deserves.  First, I think this is worthy of being worked
on as a WG item.  There are some detailed comments below on the current
rev of the draft.  The comments are a combination of nits and some
philosophical questions that need addressing in my mind.

Section 2...
This document uses... the following terms... 	
	No terms follow...

Section 3...
	I think there a mixing of profile data that can be part of
user-profile and the application-profile in this section.  It would be
better to cleanly separate the common application from applications tied
to a user and describe the cases that pertain just to he applications.

	Bandwidth brings up an interesting question.  The other profiles
tell you values for max bandwidth while the application profile demands
a min bandwidth.  This immediately brings in a temporal factor in when
the app profile data is usable.  NOTIFY's for the other profiles have to
be in before the decision on whether we have enough bandwidth for an
application and hence should that application even be enabled and come
up.  In the case of the other profiles you just needed a function to
merge the data but the data themselves were not interdependent.

	Also the behavior of the device when one of these dependencies
are not satisfied needs to be clarified in the draft

Section 5.1...

	Given that the absence of an appid parameter is treated as an
error by the pds, it behooves this parameter to be a MUST rather than a
SHOULD.  IMHO, even if there is only one appid, we should put it in
there.  Makes things clearer and easier to debug!!! (I end up writing
code sometimes...)

	What follows is a bit of a ramble on this topic.   One could
potentially have multiple application's requesting profile data.  There
could be more than one pds involved in this exchange.  If a pds does not
serve a profile out of the list it gets, what are the expectations on
the behaviour of the user agent.  Resend the ones it has got to a
different pds??  If the original pds expected to provide a list of other
pds's it knows about.  This could be a pain... a series of cascading
"300 multiple choices" yow!!!

Section 5.3...

	My choice would be to actually have empty bodies that match up
in a multipart body.  I like one to one correspondences... cleaner to
implement.

That's all for now.  I am sure there are better minds than I that have
better comments than these...

Having rambled with nit picky comments, I still think we should work on
this issue

Sam

Exeunt stage left!!!

___
Sam Ganesan
Distinguished member, Technical Staff
Advanced Engineering
On Demand Solutions, Motorola
Tel:   978 264-7921
Mob: 978 328-7132
[email-masked]

_______________________________________________
Sipping mailing list  https://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, 4 Apr 2008 16:33:10 -0600

Appreciate your comments, Sam. Find enclosed some responses to your
comments... 

on as a WG item.  

[S] Thanks. It would be nice to get feedback from the other WG members
to see if there is sufficient WG interest in this work.

         Bandwidth brings up an interesting question.  The other
profiles tell you values for max bandwidth while the application profile
demands a min bandwidth.  This immediately brings in a temporal factor
in when the app profile data is usable.  NOTIFY's for the other profiles
have to be in before the decision on whether we have enough bandwidth
for an application and hence should that application even be enabled and
come up.  In the case of the other profiles you just needed a function
to merge the data but the data themselves were not interdependent.

[S] I think this would be a problem for the profile data set I-D to deal
with, since there can be overlaps between what the local-network
instructs v/s what the device is configured to do and is not something
that we considered within the scope of this I-D (the profile-data-set
I-D would need to deal with it :^) ). 

[S] The usage of app-ids is specific to deployments, which is why it is
a recommendation. However, I agree that we do not explicitly indicate
behavior when it is omitted, and should probably be aligned.

different pds??  

[S] The UA resends a profile enrollment request (SIP SUBSCRIBE) which
can get routed to a different PDS.

Section 5.3... 

[S] This is what is specified, so unless we have other opinions (and
reasons) to change it, it will stay.

Thanks!

- S

---

From: Josh Littlefield <[email-masked]>
Date: Mon, 07 Apr 2008 12:04:17 -0400

Thanks, Sam.  More comments below:

Sumanth Channabasappa wrote:
> profiles tell you values for max bandwidth while the application 
> profile demands a min bandwidth.  This immediately brings in a 
> temporal factor in when the app profile data is usable.  NOTIFY's for 
> the other profiles have to be in before the decision on whether we 
> have enough bandwidth for an application and hence should that 
> application even be enabled and come up.  In the case of the other 
> profiles you just needed a function to merge the data but the data 
> themselves were not interdependent.
>
> [S] I think this would be a problem for the profile data set I-D to 
> deal with, since there can be overlaps between what the local-network 

I agree that the specific application profile definition needs to deal 
with these relationships (temporal and data relationships), since the 
issues (if any) will come directly from each application's data set.

> error by the pds, it behooves this parameter to be a MUST rather than 
> a SHOULD.  IMHO, even if there is only one appid, we should put it in 
> code sometimes…)
> [S] The usage of app-ids is specific to deployments, which is why it 
> is a recommendation. However, I agree that we do not explicitly 
> indicate behavior when it is omitted, and should probably be aligned.
>

We (the authors) did go back and forth on this a bit.  We determined to 
leave the issue open (though I think we neglected to document it as 
such) as to whether there was a good use case for a SUBSCRIBE with no 
appids, such as operator/deployment-specific behavior when subscribing 
to a specific URI, or in a specific and known context.  For example, 
this could allow a device to determine available applications in certain 
contexts.

We are very interested in input as to whether the appid should be 
required on SUBSCRIBE or not, and if not, then what behavior or 
expectation should be defined in this document for that case.  It does 
seem to me that leaving the behavior unspecified is likely to lead to 
operational issues.

> potentially have multiple application's requesting profile data.  
> There could be more than one pds involved in this exchange.  If a pds 
> does not serve a profile out of the list it gets, what are the 
> expectations on the behaviour of the user agent.  Resend the ones it 
> has got to a different pds?? 
>

Yes, I think the expectation is to resend with the unfulfilled appids 
again to the same URI, anticipating a potentially different routing for 
those appids.  If this fails, then those appids are not available, as 
least as a group.  In practice, we expect that the device will know, 
through the definition of the application profiles, that some appids are 
combinable in a SUBSCRIBE, and others are not.  The device always has 
the option of subscribing one-at-a-time for appids.  I think the 
instances where it makes sense to combine them will be more clear when 
these application profiles are specified.

-josh

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                             1414 Massachusetts Avenue
tel: 978-936-1379  fax: 978-936-2226       Boxborough, MA  01719-2205

---

From: "Ganesan Sam-W00184" <[email-masked]>
Date: Wed, 9 Apr 2008 23:37:38 -0400

The situation of when a given SUBSCRIBE contains more than one appid to
a given pds is an interesting one.  For example, I can think of a
situation when it is an interdependent group of applications, in which
case the dataset should almost have the means of describing
interdependence.  ..... Profile datasets has to have means of expressing
not just merging rules but dependency rules??? Oh dear...

You might want to add a line or two about how multiple pds's are
discovered on a per app basis or per groups of interdependent app basis.
As I recall, pds discovery is not granular enough to cover per app pds
discovery.  

More nits as I think about it.  Other input from the WG would be good
too...

Sam

-----Original Message-----
From: Josh Littlefield [mailto:[email-masked]] 
Sent: Monday, April 07, 2008 12:04 PM
To: Ganesan Sam-W00184
Cc: Sumanth Channabasappa; sipping
Subject: Re: [Sipping] Draft-channabasappa-sipping-app-profile-type-02

-josh