Subject: [sipcore] location conveyance ABNF

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 16 Jul 2010 14:04:42 +0800

I've been looking at the ABNF in draft-ietf-sipcore-location-conveyance-03 and it looks like it could use a little cleaning up.

If the intent is to have a locationValue, a routing-param, or both, then this is the correct form:

   Geolocation-header = "Geolocation" HCOLON Geolocation-value
   Geolocation-value  = ( locationValue [ COMMA routing-param ] )
                        / routing-param

If the intent is to require use of content indirection (RFC 4483), then there is no need to support different URI schemes here.

   locationValue      =  LAQUOT cid-url RAQUOT *(SEMI geoloc-param)
                         ; cid-url from RFC 2392

However, it might be better to allow for a little more flexibility.

   locationValue      =  LAQUOT locationURI RAQUOT *(SEMI geoloc-param)
   locationURI        =  cid-url / absoluteURI
                         ; cid-url from RFC 2392, absoluteURI from RFC 3986

I don't know what the implications of referencing RFC 3986 is, but it seems more appropriate than the definition in RFC 3261, which seems to copy from RFC 1738.

Geolocation-Error is OK, but it might be shorter - the locationErrorValue rule adds no value.  I'd also use text to note that this builds on the syntax defined in RFC 3261, rather than identifying each rule from the 3261 ABNF individually.

   Geolocation-Error        = "Geolocation-Error" HCOLON location-error-arg
   location-error-arg       = location-error-code
                               *(SEMI location-error-params)
   location-error-code      = 1*3DIGIT
   location-error-params    = location-error-code-text / generic-param
   location-error-code-text = "code" EQUAL quoted-string

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 16 Jul 2010 09:09:26 -0400

>                         ; cid-url from RFC 2392, absoluteURI from  

I would really like it if we could preserve this flexibility.

--Richard

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 19 Jul 2010 08:11:12 +0800

> From: Richard L. Barnes [mailto:[email-masked]]
> 

Agreed.  No need to cut off flexibility when it costs so little.