Looks like the Warning Codes approach is preferred. I'm glad I'm now reading http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-08.txt.
I almost fell off my chair when I saw the following two Error codes defined in James' draft: 3.4.12 Warning code 720 Unsupported Schema - sip desired A Warning header with the code 720 "Unsupported Schema - sip desired" means the location dereferencer cannot dereference using the location-by-reference URI schema supplied because it does not support the necessary protocol to do this. This Warning code means the location recipient can dereference the target's location using a sip-URI schema. There can be more than one Warning code in a Warning header, indicated in this context the recipient can dereference using each schema protocol included in the Warning header. A typical reaction to receiving this warning code would be for the location sender to send a URI with the sip schema. Recommended warn-text: unsupported schema An example usage in a SIP 424 response: Warning: 720 alice.example.com "unsupported schema - sip desired" 3.4.12 Warning code 721 Unsupported Schema - sips desired A Warning header with the code 721 "Unsupported Schema - sips desired" means the location dereferencer cannot dereference using the location-by-reference URI schema supplied because it does not support the necessary protocol to do this. This Warning code means the location recipient can dereference the target's location using a sips-URI schema. There can be more than one Warning code in a Warning header, indicated in this context the recipient can dereference using each schema protocol included in the Warning header. Recommended warn-text: unsupported schema An example usage in a SIP 424 response: Warning: 721 alice.example.com "unsupported schema - sips desired" As James pointed out, in -07, those were Warning headers, now they are Geoprive headers. If we are going to use 2 new Warning Headers in draft-ietf-sip-sips (say 380 and 381), wouldn't it make more sense if draft-ietf-sip-location-conveyance-09 use those values (with 424) instead of 720/721? It seems to me that error 720-723 would be potentially applicable to more than just Location. 700-711 however are specific to location, and should remain as defined. Any toughts? > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 31, 2007 09:20 > To: Rohan Mahy; Audet, Francois (SC100:3055) > Cc: Cullen Jennings; IETF SIP List; [EMAIL PROTECTED]; > Robert Sparks; Dean Willis > Subject: RE: [Sip] Re: Warn-Codes and draft-ietf-sip-sips > > As Jame's has already remarked, we did discuss this in the > context of location-conveyance. > > I believe the SIP list conclusion at that point was that the > RFC 3261 text was not preventing usage, but the IANA registry > text did. > > The Warning header registry was created by RFC 3261 in the > days before formal IANA considerations sections in RFCs. As > draft-ietf-sip-sips updates RFC 3261, it would seem to me > that it is entirely appropriate for that document to update > the IANA registry for Warning headers. By this I mean you > need to update the registry definition itself, as well as add > new values to it. > > This is of course assuming that we decide that Warning > headers are the way to go. > > Regards > > Keith > > > -----Original Message----- > > From: Rohan Mahy [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, July 31, 2007 4:12 PM > > To: Francois Audet > > Cc: Cullen Jennings; Rohan Mahy; IETF SIP List; DRAGE, > Keith (Keith); > > Robert Sparks; [EMAIL PROTECTED]; Dean Willis > > Subject: [Sip] Re: Warn-Codes and draft-ietf-sip-sips > > > > François, > > > > I think the IANA paragraph you described is too restrictive. > > The text in RFC3261 section 20.43 seems perfectly fine with > > registering non-SDP errors. I would allocate warn-code 380 > "No SIPS > > contacts registered". > > > > thanks, > > -rohan > > > > On Jul 30, 2007, at 3:23 PM, Francois Audet wrote: > > > > > Now that we have everybody exited about the prospect of using a > > > Warn-Code for "SIPS Not Allowed" and "SIP Required" with > > Response 480, > > > instead of using new response codes, here is a quote from > 27.2/RFC > > > 3261. > > > > > > Warning codes provide information supplemental to the > > status code > > > in > > > SIP response messages when the failure of the > transaction results > > > from a Session Description Protocol (SDP) (RFC 2327 > [1]) problem. > > > > > > My reading of this is that Warn-Codes are ONLY usable for > > SDP errors. > > > > > > Doesn't this disqualify the idea of using a Warn-Code for > > SIP/SIPS URI > > > problems?????? > > > > > > If so, aren't we back to 418/419, or 418+New header (Allow/ > > Require), > > > or > > > 480+Response text? > > > > > > > > _______________________________________________ > > 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 > _______________________________________________ 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
