Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter

[Christer Holmberg <[e-mail]>]

Hi,

>>>> Also to address Pauls comment complete. I would propose then the following:
>>>>
>>>>
>>>>             location-source = "loc-src=" (hostname / other-loc-src)
>>>>             hostname = <defined in RFC3261>
>>>>             other-loc-src = token
>>>>
>>>>                            Figure 1: Location Source
>>>
>>> I'll be ok with this if you also include some text about the intent of other-loc-src. Is it intended only as a hook for future extension - requiring another document to 
>>> define that usage? What should a recipient do if they receive this with something matching other-loc->src and don't understand that usage?
>> 
>> As I indicated in my comments, I'd like to see some justification on why we mandate a FQDN to begin with.
>
> As opposed to *what*?
>
> Surely there ought to be some semantics to this. I presume it is to be an identifier of something, and presumably there then need to be rules for 
> resolution/comparison/etc.

Based on my understanding of the draft (please correct me if I'm wrong), it's only an identifier within a trust domain. What matters is that entities within that trust domain understand the semantics.

But, assuming we want something "real", why is an IP address not allowed?

Regards,

Christer




>>> -----Ursprüngliche Nachricht-----
>>> Von: Asveren, Tolga [mailto:[e-mail]]
>>> Gesendet: Freitag, 22. September 2017 08:24
>>> An: Jesske, Roland <[e-mail]>; Paul Kyzivat 
>>> <[e-mail]>; [e-mail]
>>> Cc: James Winterbottom <[e-mail]>
>>> Betreff: RE: [sipcore] draft-winterbottom-sipcore-locparam-01.txt 
>>> and Liaison Statement to IETF on location source parameter
>>>
>>> I would prefer to keep the existing syntax. Not that I have an 
>>> immediate use case at hand but you never know what future would 
>>> bring. And it would be a pity to have an extension draft just for something like this.
>>>
>>> Thanks,
>>> Tolga
>>>
>>> -----Original Message-----
>>> From: sipcore [mailto:[e-mail]] On Behalf Of Jesske, 
>>> Roland
>>> Sent: Friday, September 22, 2017 1:30 AM
>>> To: Paul Kyzivat <[e-mail]>; [e-mail]
>>> Cc: James Winterbottom <[e-mail]>
>>> Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt 
>>> and Liaison Statement to IETF on location source parameter
>>>
>>> Hi Paul,
>>> Thank you for your comment.
>>> The addition of other-loc-src was discussed in the past and was 
>>> added due to some requests not to restrict this parameter to a hostname.
>>> ETSI does only needs a hostname.
>>>
>>> So I have nothing against to change it as you have proposed it.
>>> So If other people would like to keep this please speak up.
>>>
>>> Thank you and Best Regards
>>>
>>> Roland
>>>
>>>
>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: sipcore [mailto:[e-mail]] Im Auftrag von Paul 
>>>> Kyzivat
>>>> Gesendet: Mittwoch, 20. September 2017 21:12
>>>> An: [e-mail]
>>>> Betreff: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt
>>>> and Liaison Statement to IETF on location source parameter
>>>>
>>>> I'm ok with adopting this.
>>>>
>>>> A minor point on the content:
>>>>
>>>> The syntax of the new parameter is defined as:
>>>>
>>>>              location-source = "loc-src=" (host / other-loc-src)
>>>>              other-loc-src = token
>>>>
>>>> But there is no definition of 'host'. I think the definition you 
>>>> are intending is actually 'hostname' as defined in 3261.
>>>>
>>>> Also, if "Only a fully qualified host name is valid" then what is 
>>>> the point of 'other-loc-src'?
>>>>
>>>> So I would suggest:
>>>>
>>>>              location-source = "loc-src=" hostname
>>>>              hostname = <defined in RFC3261>
>>>>
>>>> 	Thanks,
>>>> 	Paul
>>>>
>>>>
>>>> On 9/20/17 1:09 AM, Jesske, Roland wrote:
>>>>> Dear all,
>>>>>
>>>>> since I did not get any comments on our draft it look for me that 
>>>>> people are happy with the content.
>>>>>
>>>>> So I would like to ask the group for adoption of this draft.
>>>>>
>>>>> Best Regards
>>>>>
>>>>> Roland
>>>>>
>>>>> *Von:*sipcore [mailto:[e-mail]] *Im Auftrag von 
>>>>> *Jesske, Roland
>>>>> *Gesendet:* Dienstag, 29. August 2017 10:59
>>>>> *An:* [e-mail]
>>>>> *Betreff:* [sipcore] draft-winterbottom-sipcore-locparam-01.txt 
>>>>> and Liaison Statement to IETF on location source parameter
>>>>>
>>>>> Dear all,
>>>>>
>>>>> since I have uploaded the latest draft on 
>>>>> draft-winterbottom-sipcore-locparam-01.txt and the last 
>>>>> clarification on questions were given on 23. May I did not get any 
>>>>> further
>>> comment.
>>>>>
>>>>> With a reference to this draft a Liaison from ETSI ( 
>>>>> https://datatracker.ietf.org/liaison/1527/ ) is waiting for action.
>>>>>
>>>>> The liaison from ETSI is asking on the progress of the draft for 
>>>>> their solution on Emergency Call due to the Project of  the 
>>>>> European Union
>>>>> Mandate: M493.
>>>>>
>>>>> My question is, since we have no open questions, if we can now 
>>>>> progress the draft.
>>>>>
>>>>> Thank you for consideration.
>>>>>
>>>>> Best Regards
>>>>>
>>>>> Roland
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> sipcore mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>>>
>>>>
>>>> _______________________________________________
>>>> sipcore mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>
>>> _______________________________________________
>>> sipcore mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>>
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>