Subject: RE: [Sip] Re: [Geopriv] How Location Conveyance specifies the allowed URI

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 27 Jul 2006 17:48:20 -0400

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-masked]]
> 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.

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 28 Jul 2006 00:13:54 +0200

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-masked]>
To: "James M. Polk" <[email-masked]>; "IETF SIP List" <[email-masked]>; 
"GEOPRIV" <[email-masked]>
Sent: Thursday, July 27, 2006 11:48 PM
Subject: RE: [Sip] Re: [Geopriv] How Location Conveyance specifies the 
allowedURI

Brian

to
chance
something
therefore
This
if

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip