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

From: Salvatore Loreto <[email-masked]>
Date: Fri, 16 May 2008 10:34:54 +0300

Hi,

in line you find a comment on the behavior when the app-ids is omitted

regards
Sal

Josh Littlefield wrote:
> Thanks, Sam.  More comments below:
>
> Sumanth Channabasappa wrote:
>   
>>          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 :^) ).
>>
>>     
>
> 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.
>
>   
>>         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…)
>>
>> [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.
>   
I agree with the fact that we have to add same text in the document 
describing the
behavior when the app-ids is omitted.
We have two possibilities here:
1) make the app-ids required in the SUBSCRIBE, that means the when a UA
SUBSCRIBE to the 'application' profile type, it has to insert the 
app-ids parameter
and of course the app-ids parameters must not be empty
2) give the possibility to SUBSCRIBE to the 'application' profile type 
without insert the
app-ids parameter or with an app-ids empty. In this case however we have 
to specify
a standard behavior for the PDS. I am quite sure that if we do not 
specify we will end up
in a scenario where different PDS will answer in different way, making 
more complicate the
application configuration.

on this issue I d like have an open and large discussion.

>   
>>         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?? 
>>
>> [S] The UA resends a profile enrollment request (SIP SUBSCRIBE) which 
>> can get routed 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
>
>   

_______________________________________________
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: Salvatore Loreto <[email-masked]>
Date: Fri, 16 May 2008 10:50:03 +0300

Hi Sam,

maybe I am wrong, but I am not sure we have to discuss also how to 
subscribe to an interdependent group
of applications and how to discover the right PDS.
Conditional subscription to an application, e.g. I want subscribe to app 
A only if I can subscribe also to App B
will make the PDS discovery more complicate.
Sumanth what do you think?

/Sal

Ganesan Sam-W00184 wrote:
> 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
>
>> code sometimes...)
> --
> =====================================================================
> Josh Littlefield                                  Cisco Systems, Inc.
> [email-masked]                             1414 Massachusetts Avenue
> tel: 978-936-1379  fax: 978-936-2226       Boxborough, MA  01719-2205
>