Subject: Re: [sipcore] New Version Notification for draft-winterbottom-sipcore-locparam-01.txt

From: <[email-masked]>
Date: Tue, 23 May 2017 13:04:50 +0000

Dear all,

After reworking the draft due to the comments made by Dale, I have uploaded a new version
https://www.ietf.org/internet-drafts/draft-winterbottom-sipcore-locparam-01.txt

I didn't get any comments on my answers given to Dales mail which also covered the comments made within the meeting report.

ETSI is still looking forward on processing this document for their solution on Emergency Call due to the Project of  the European Union Mandate: M493.
 
Comments and improvements are welcome.

Question is how to proceed further since I did not get any further comments since my last mail on 4th April.

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]
> Gesendet: Dienstag, 23. Mai 2017 14:45
> An: Jesske, Roland; Bruno Chatras; James Winterbottom; Andrew Hutton
> Betreff: New Version Notification for draft-winterbottom-sipcore-
> locparam-01.txt
> 
> 
> A new version of I-D, draft-winterbottom-sipcore-locparam-01.txt
> has been successfully submitted by Roland Jesske and posted to the IETF
> repository.
> 
> Name:		draft-winterbottom-sipcore-locparam
> Revision:	01
> Title:		Location Source Parameter for the SIP Geolocation
> Header Field
> Document date:	2017-05-23
> Group:		Individual Submission
> Pages:		8
> URL:            https://www.ietf.org/internet-drafts/draft-winterbottom-
> sipcore-locparam-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-winterbottom-
> sipcore-locparam/
> Htmlized:       https://tools.ietf.org/html/draft-winterbottom-sipcore-
> locparam-01
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-
> winterbottom-sipcore-locparam-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-winterbottom-
> sipcore-locparam-01
> 
> Abstract:
>    There are some circumstances where a geolocation header field may
>    contain more than one location value.  Knowing the identity of the
>    node adding the location value allows the recipient more freedom in
>    selecting the value to look at first rather than relying solely on
>    the order of the location values.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> The IETF Secretariat

---

From: Brian Rosen <[email-masked]>
Date: Tue, 23 May 2017 09:42:40 -0400

<as individual>
I had asked a question on this, which was, why isn’t <provided-by> an acceptable solution to the problem?

I didn’t see an answer.

Brian
> On May 23, 2017, at 9:04 AM, [email-masked] wrote:
> 
> Dear all,
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: James Winterbottom <[email-masked]>
Date: Wed, 24 May 2017 05:35:11 +1000

Hi Brian,

Provided-by doesn’t work for two reasons.

1) Provided-by says who determined the location, not who put the thing into the geolocation header
2) provided-by only works if you sending location by value, which in the European case we are not.

Cheers
James

> On 23 May 2017, at 11:40 pm, Brian Rosen <[email-masked]> wrote:
> 
> <as individual>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 23 May 2017 15:51:27 -0400

Is there a practical difference between who determined location and who put it in the header?

Is there a reason you can’t (or even more likely, wouldn’t normally) dereference the URI, and thus get the <provided-by> 
in every circumstance where the locparam would be used?

Brian

> On May 23, 2017, at 3:35 PM, James Winterbottom <[email-masked]> wrote:
> 
> Hi Brian,
>

---

From: James Winterbottom <[email-masked]>
Date: Wed, 24 May 2017 05:54:49 +1000

In the M/493 case yes they are very different.
If the Geolocation header field contains multiple values, then the locparam allows the node using the location to decide which one it likes best without having to go and fetch them all.

So yes, I think it does provide a differentiator.

Cheers
James

> On 24 May 2017, at 5:51 am, Brian Rosen <[email-masked]> wrote:
>