Re: Re: [Geopriv] How Location Conveyance specifies the allowedURI
"Jeroen van Bemmel" <[email protected]>
| Newsgroups | gmane.ietf.sip,gmane.ietf.geopriv |
|---|---|
| Message-ID | <00d001c6b1c9$f2bc7e20$31713b51@BEMBUSTER> |
Brian, Yes, but there is one big difference with what you are proposing: extensions to SIP specialize existing, clearly defined extension points in the RFC3261 ABNF. For example, "generic-param = token [ EQUAL gen-value ]" is often extended by giving a specific definition of 'token' and 'gen-value', for a specific header parameter Some headers currently don't allow parameters. That sometimes limits possible solutions, since extensions are not allowed to add parameters to such headers (since it would break backwards compatibility). In other words, modifications to the ABNF are not arbitrary. SIP elements are required to ignore headers that are not understood (RFC3261 section 8.2.2). However, early implementations of location conveyance will read the Location header. If there is no generic "AbsoluteURI" (the equivalent of generic-param) as part of the ABNF for the Location header, then additions to this field will give parsing errors for these early implementations. A typical implementation will then return "400 Bad Request", which does not help debugging. And what if the location is not critical to processing the request? then there should not be an error response, but the parser cannot make that distinction Regards, Jeroen ----- Original Message ----- From: "Rosen, Brian" <[email protected]> To: "James M. Polk" <[email protected]>; "IETF SIP List" <[email protected]>; "GEOPRIV" <[email protected]> Sent: Thursday, July 27, 2006 11:48 PM Subject: RE: [Sip] Re: [Geopriv] How Location Conveyance specifies the allowedURI I could be wrong, but I think it is possible to define such an extension as not updating the original document. Nearly every SIP extension effectively modifies one or more ABNF lines in 3261, but none of them are considered updates to 3261. Brian > -----Original Message----- > From: James M. Polk [mailto:[email protected]] > Sent: Thursday, July 27, 2006 5:28 PM > To: Rosen, Brian; IETF SIP List; GEOPRIV > Subject: Re: [Sip] Re: [Geopriv] How Location Conveyance specifies the > allowed URI > > At 04:20 PM 7/27/2006 -0500, James M. Polk wrote: > >>Can we accept this "allowed-URI" proposal and move on? Does it have to > >>be standards track, or is Informational okay? > > > >A vote for Standards Track, as this ensures IETF LC for everyone's chance > >at a proposal., also so some other WG doesn't attempt to slip something > by > >anyone (meaning "by Geopriv") > > As a WG chair, I should know this off the top of my head, but I'm > bewildered by some of the comments here (and in another area), therefore > confused... > > I believe that each subsequent schema proposed would be an official > 'update' to this SIP RFC (to be), which is Standards Track, meaning I > don't > believe an INFO RFC can officially 'update' a Standards Track RFC. This > would mean updating this RFC (to be) would take a Standards Track RFC, if > my math is right... > > > >>I would think > >>informational is okay, provided geopriv reviews. _______________________________________________ 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