Subject: [Sipping] Re: Review of draft-ietf-sipping-policy-package-03

From: Volker Hilt <[email-masked]>
Date: Wed, 08 Aug 2007 23:03:01 -0400

Roni,

thanks much for reviewing this document.
> 
> In section 3.8 " For example, if the session was rejected due to a 
> temporary shortage of resources and the notifier expects that these 
> resources will become available again shortly it should keep the 
> subscription alive"
> 
> How does the notifier keep the session alive what is sent in the notify 
> body, is it an empty body?
> 
An empty body indicates that the notifier does not have enough 
information for making a decision.

To reject a session (independent of whether the subscription is kept 
alive or not) the notifier includes a policy document that says the 
session has been rejected. Interestingly, an attribute for this is 
missing in the policy format and needs to be added.

An alternative might be to define an event parameter. But I think the 
policy decision should really be contained in the policy document.

> Nits
All fixed!

Thanks much!

Volker

>  
> 
> 1.    In the document you mention "session-policy+xml" as defined in the 
> data set draft, I think it should be
> 
> "media-policy-dataset+xml". This text appears in a couple of places 
> starting in 3.3
> 
>  
> 
> 2.    In section 4.  "Authenticating the two parties can performed using 
> X.509" to "Authenticating the two parties can be performed using X.509".
> 
>  
> 
>  
> 
> Roni Even
> 
>  
> 

_______________________________________________
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: "Even, Roni" <[email-masked]>
Date: Thu, 9 Aug 2007 09:14:52 +0300

Volker,

I was wondering how a subscriber will distinguish if he was rejected in general or if he was rejected due to temporary shortage of resources. 

The subscriber may decide to terminate the subscription if rejected and discard the call, he may take a different approach if he can know that his is a temporary problem; it is not only to the notifier to keep the subscription alive. 

Also shortly will not mean much (minutes, seconds, hour)in the notification. 

If this is relevant in the notification than it should carry enough information to explain the response. If it is only an internal decision for the notifier, the text should calrify it.

Thanks

Roni

> -----Original Message-----

> From: Volker Hilt [mailto:[email-masked]]

> Sent: Thursday, August 09, 2007 6:03 AM

> To: Even, Roni

> Cc: [email-masked]; [email-masked]

> Subject: Re: Review of draft-ietf-sipping-policy-package-03

---

From: Volker Hilt <[email-masked]>
Date: Thu, 09 Aug 2007 13:24:02 -0400

Roni,
> 
> I was wondering how a subscriber will distinguish if he was rejected in 
> general or if he was rejected due to temporary shortage of resources.
> 
> The subscriber may decide to terminate the subscription if rejected and 
> discard the call, he may take a different approach if he can know that 
> his is a temporary problem; it is not only to the notifier to keep the 
> subscription alive.
> 
The notifier will terminate the subscription when sending the NOTIFY 
with the reject decision if this is a permanent problem. Thus, the fact 
that the subscription is not closed indicates that there is a temporary 
problem that may be fixed.

> Also shortly will not mean much (minutes, seconds, hour)in the 
I think it is impossible to guarantee that the problem will be fixed in 
a certain amount of time. Even a temporary shortage of resources may 
take longer than expected. I think it is up to the subscriber to 
eventually decide that he does not want to wait any longer.

> If this is relevant in the notification than it should carry enough 
> information to explain the response. If it is only an internal decision 
> for the notifier, the text should calrify it.
> 
I think it is an internal decision of the notifier to keep the 
subscription alive. The main purpose is to have the UAs stick around if 
this is only a temporary problem. I'll clarify this in the text.

Thanks,

Volker

> ------------------------------------------------------------------------
>

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 9 Aug 2007 23:56:26 +0300

Volker,

Thanks, I got it now and the when you clarify maybe you should point out that is the request was rejected and the subscription terminated, the UA should have to wait for sometime before trying to subscribe again and ask for resources. 

Roni

> Sent: Thursday, August 09, 2007 8:24 PM

> Subject: Re: [Sipping] RE: Review of draft-ietf-sipping-policy-package-03

> > Also shortly will not mean much (minutes, seconds, hour)in the

> > notification.

> >>  > How does the notifier keep the session alive what is sent in the

> notify

> >>  > 1.    In the document you mention "session-policy+xml" as defined in

> the

> >>  > 2.    In section 4.  "Authenticating the two parties can performed

> using

> >>  > X.509" to "Authenticating the two parties can be performed using

> X.509".

---

From: Volker Hilt <[email-masked]>
Date: Thu, 09 Aug 2007 19:10:18 -0400

Even, Roni wrote:
> Volker,
> 
> Thanks, I got it now and the when you clarify maybe you should point out 
> that is the request was rejected and the subscription terminated, the UA 
> should have to wait for sometime before trying to subscribe again and 
> ask for resources.
> 
I'll make this clarification in the draft.

Thanks!

Volker