Subject: [sipcore] location conveyance looks good

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 26 Oct 2010 13:50:50 +0800

Reviewing the changes in draft-ietf-sipcore-location-conveyance-04.  Nothing much to add except nits.

I could quibble.  I still don't like or want the entirety of Section 4.3 and the serial nature Figure 2 is a little mysterious to me, but it's down to subjective stuff like that, the effort just doesn't pay off.

So, ship it.
 
--Martin

Nits:

This seems odd, especially since the parameter is MUST-strength mandatory:

   ...  If no routing-allowed parameter	
   is present in a SIP request, a SIP intermediary MAY insert this	
   value with a RECOMMENDED value of "no" by default.

Cross references should capitalize the 's' in Section 3.4.

The MIME multipart headers are still in the wrong place (see Section 5 of RFC 2387 to see how this is done):

OLD:
--boundary

Content-Type: application/pidf+xml
Content-ID: <[email-masked]>
<?xml version="1.0" standalone="true"?>
<presence ...

NEW:
--boundary
Content-Type: application/pidf+xml
Content-ID: <[email-masked]>

<?xml version="1.0" standalone="true"?>
<presence ...

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 26 Oct 2010 23:29:55 -0500

At 12:50 AM 10/26/2010, Thomson, Martin wrote:
>Reviewing the changes in 
>draft-ietf-sipcore-location-conveyance-04.  Nothing much to add except nits.
>
>I could quibble.  I still don't like or want the entirety of Section 4.3

that would be quibbling, and we don't want that, now do we?

>and the serial nature Figure 2 is a little mysterious to me

if I send you a SIP request with a location URI, you need to be able 
to dereference it (or at least try) before you accept the SIP 
request. I know it'll add a bit of time to the 200 OK, but that will 
allow confirmation of location delievery - which isn't the location 
URI, but the location value itself (i.e., the PIDF-LO). If the 
dereference fails after you've sent me a 200 OK, how can you possibly 
tell me that there was something wrong with my delivery of location to you?

>, but it's down to subjective stuff like that, the effort just 
>doesn't pay off.
>
>So, ship it.
>
>--Martin
>
>
>Nits:
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 27 Oct 2010 13:31:47 +0800

> tell me that there was something wrong with my delivery of location to

I can live with that.  It all depends on whether the 200 is contingent on being able to dereference.  I imagine that if this is just a MESSAGE and the location isn't actually needed to process the request, you could send the 200 beforehand, but then you probably don't need the Geolocation header either.

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 27 Oct 2010 13:35:52 -0500

At 12:31 AM 10/27/2010, Thomson, Martin wrote:
>I can live with that.  It all depends on whether the 200 is 
>contingent on being able to dereference.  I imagine that if this is 
>just a MESSAGE and the location isn't actually needed to process the 
>request, you could send the 200 beforehand, but then you probably 
>don't need the Geolocation header either.

I'm thinking that's all true

james