> -----Original Message----- > From: James M. Polk [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 05, 2007 15:35 > To: Audet, Francois (SC100:3055); [email protected] > Subject: RE: [Sip] New draft modifying RFC 4412 for Responses > > Francois > > in-line > > At 11:29 AM 6/18/2007, Francois Audet wrote: > >Hi James, > > > >It might be useful to have some wording on the limitations > of using a > >response to carry a Resource-Priority header in a response. > > Do you have any text (or direction) to offer that you would > want to see in this ID?
Yes, something along the lines of the paragraph below: > >Specifically, a UAS can not use a response to carry the > >Resource-Priority in cases where the Resource-Priority "absolutely > >has" to be delivered to the UAC. It is therefore only useable for > >cases where a forking proxy may discard the response (i.e., forward > >another instead) without breaking anything. > > I have to admit, I do not understand this use-case (as it is > written), since I'm not sure what you are referring to when you say > "..."absolutely has" to be delivered to the UAC". Right now, RPH > isn't in any response, so when did it become a situation of > "..."absolutely has" to be delivered...". What I mean is that the error response may not be delivered to the UAC because a forking proxy will only deliver one final response. If there are multiple error responses on the individual forks, one being the one with the RPH, and the other being some other response, it is up to the proxy to decide which one to forward back. So the UAC can not rely on receiving the RPH to "re-intiate" the session or provide some alternative treatment. This may or may not be a problem depending on the application (that's why I said "if it absolutely has"). > Remind me what HERFP is again... HERFP is the problem described above. It stands for "Heterogeneous Error Response Forking Problem". > >In other words,you need to think about HERFP before using this draft. > > > >In some scenarios, this is probably the desired behavior. > > > >In other scenarios, it may not acceptable. So instead, for > those scenarios, > >the terminating side would have to send a new request with a > >Resource-Priority > >instead of using a response. What I'm looking for is just a description of the limitation of using a response for carrying the information, in order to alert the implementors. I'm not looking for a solution to the HERFP problem in this draft. > > > > > > > -----Original Message----- > > > From: James M. Polk [mailto:[EMAIL PROTECTED] > > > Sent: Saturday, June 16, 2007 14:14 > > > To: [email protected] > > > Subject: [Sip] New draft modifying RFC 4412 for Responses > > > > > > SIP WG > > > > > > Here is a new ID I've written because of implementation > > > considerations to allow a SIP Resource-Priority header (RPH) > > > in responses, which RFC 4412 currently disallows, assuming > > > only that stateful devices will use RPH. There have been > > > many requests to have this "only stateful devices" > > > restriction relaxed, in certain scenarios. This ID does > > > this, and proposes how IANA is changed accordingly wrt RPH. > > > This ID does nothing else. > > > > > > Comments are appreciated. > > > > > > >A New Internet-Draft is available from the on-line > Internet-Drafts > > > >directories. > > > > > > > > Title : Allowing SIP Resource > Priority Header in > > > > SIP Responses > > > > Author(s) : J. Polk > > > > Filename : draft-polk-sip-rph-in-responses-00.txt > > > > Pages : 6 > > > > Date : 2007-6-15 > > > > > > > > The Session Initiation Protocol (SIP) Resource > Priority Header > > > > (RPH), in its current form, is ignored in SIP responses. > > > This was a > > > > design choice during RFC 4412's development. This is now > > > considered > > > > a bad design choice in certain scenarios. This > document corrects > > > > RFC 4412's communications model by optionally allowing a > > > SIP server > > > > or user agent client to process the > Resource-Priority Header in a > > > > response. > > > > > > > >A URL for this Internet-Draft is: > > > >http://www.ietf.org/internet-drafts/draft-polk-sip-rph-in-res > > > ponses-00. > > > >txt > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > [EMAIL PROTECTED] for questions on current sip > > > Use [EMAIL PROTECTED] for new developments on the > application of sip > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
