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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.