Francois

I don't believe it is a glitch so much as it is an initial range, which can be expanded with a PS RFC, especially one with an update to 3261 (which you are doing).

I was using 7XX (assigning 701 through 739) - though I pulled the Warning codes from the conveyance draft, therefore I am no longer using these codes (since I created a new SIP header (Geolocation-Error) to accomplish the same task as the Warning codes plus add new information with header parameters for the new header).

My point was that it is possible to go outside the 3XX range for SIP... you just have to define it.

BTW - I am ok with the 480+Warning Code, but am cautious about the Warning header (with its 'why' information) being stripped along the way back to the UAC.

Ultimately, do we want zero communications between this UAC and UAS (because the UAC can always get a 480 without additional information letting it know what was really wrong with the request), or do we want to send the UAC something it can understand about this scenario?

At 08:49 AM 7/31/2007, Francois Audet wrote:
Ok, that's fine with me. It's just a glitch in 3261 then. I'd rather we
stick with the Warn-Codes approach.

Did you assign a purpose for 7XX-series warn-codes yet? I'm wondering
what
range should be used for this purpose.

James, I didn't see your codes on IANA's web site. What values are you
using?
I don't want to overlap.


> -----Original Message-----
> From: James M. Polk [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 30, 2007 21:44
> To: Audet, Francois (SC100:3055); Alan Hawrylyshen; Kyzivat
> Paul; Mahy Rohan
> Cc: IETF SIP List; [EMAIL PROTECTED]
> Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418
>
> At 10:54 AM 7/30/2007, Francois Audet wrote:
> >RFC 3261, p. 181:
> >
> >         "The first digit  of warning codes beginning with "3"
> >indicates warnings
> >         specific to SIP."
> >
> >Then it explains within the 3XX space, how they are used.
>
> btw -- for location-conveyance-07, I created 15 new Warning codes (#s
> 701 through 712, then 720, 721, and 722).  All this at the
> suggestion of Henning (who knows something about 3261 text...  ;-)
>
> btw II - I have since replaced the Warning header indication
> with a new Geolocation-Error header, but this was so I could
> stuff more into the new header than the Warning header would allow.
>
> In all this, I did not get one person claiming Warning codes
> were limited to 3XX.  Henning merely said the "first batch of
> codes were in the 300s, and that there was nothing limiting a
> new ID from defining new codes in any other number range"...
>
>
> > > -----Original Message-----
> > > From: James M. Polk [mailto:[EMAIL PROTECTED]
> > > Sent: Saturday, July 28, 2007 18:25
> > > To: Audet, Francois (SC100:3055); Alan Hawrylyshen; Kyzivat Paul;
> > > Mahy Rohan
> > > Cc: IETF SIP List; [EMAIL PROTECTED]
> > > Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418
> > >
> > > A 399 Miscellaneous?  That doesn't make sense...
> > >
> > > Warning codes are not limited to 3XX, so if a new Warning code is
> > > what Rohan wants to convey more information in the
> response (which I
> > > believe should be done one way or another)
> > > - it can be almost any value other than 300-379 or 399 IMO.
> > >
> > > At 10:32 AM 7/27/2007, Francois Audet wrote:
> > > >On the Warning header...
> > > >
> > > >Values 300-379 are reserved for SDP-related stuff.
> > > >
> > > >Values 380-389 are unassiged (but there is no text on it).
> > > >
> > > >Values 390-398 are unassigned (but don't fall into the
> SDP related
> > > >stuff.
> > > >
> > > >399 means Miscellaneous and the text can be provided to the user.
> > > >It further says that Automata MUST NOT take action based on this.
> > > >
> > > >Rohan, are you advocating using 399, or defining a new code from
> > > >the
> > > >390-398 space?
> > > >
> > > > > -----Original Message-----
> > > > > From: Alan Hawrylyshen [mailto:[EMAIL PROTECTED]
> > > On Behalf Of
> > > > > Alan Hawrylyshen
> > > > > Sent: Friday, July 27, 2007 08:27
> > > > > To: Kyzivat Paul; Mahy Rohan
> > > > > Cc: Audet, Francois (SC100:3055); IETF SIP List;
> > > > > [EMAIL PROTECTED]
> > > > > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418
> > > > >
> > > > >
> > > > > On 27-Jul-2007, at 10:06 , Paul Kyzivat wrote:
> > > > >
> > > > > > I understand that if the user entered a sips URI then it
> > > > > should be the
> > > > > > user that must decide to downgrade. But if the user didn't
> > > > > > know whether to use sip or sips in the first place,
> and the UA
> > > > > decides to
> > > > > > try sips first then I see no problem in the UA
> having a policy
> > > > > > that causes it to downgrade.
> > > > >
> > > > > I was under the impression (based on meeting
> discussion) that :
> > > > > 1 - the downgrade was undesirable because it reveals
> > > > > (possibly) information about the targeted party in the clear,
> > > > > and;
> > > > > 2 - The 480 with a Warning header was an option to provide
> > > > > automata- friendly indication of the failure reason.
> > > > >
> > > > > Alan Hawrylyshen
> > > > >
> > > > > a l a n a t p o l y p h a s e d o t c a
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >_______________________________________________
> > > >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

Reply via email to