Re: [Ecrit] draft-winterbottom-ecrit-priv-loc

That’s a really good idea Randy, I shall do that.

The other idea I have been toying with is, if the LIS has it, allowing the LIS to return the address of the LoST server in place of the routing information itself. This would allow areas that deploy LoST servers but not forest guide networks, islands if you like, to still have the authoritative server queried directly. This won’t work in all cases, as the draft describes, but it could assist in some environments.

Cheers
James

> On 23 Dec 2014, at 11:08 pm, Randall Gellens <randy@qti.qualcomm.com> wrote:
> 
> Hi James,
> 
> So the draft currently specifies that only sos and children of sos are returned?  I'd missed that when I read and re-read the draft.  If so, that's fine with me, but maybe it can be made more clear.
> 
> For example, Section 4 says:
> 
>   The routing information in the location response consists of one or
>   more service elements which is identified by a service name.  The
>   service name is a URI and might contain a general emergency service
>   urn such as urn:service:sos or might contain a specific service urn.
> 
> To me, this says that sos is just an example of a service that might be returned.
> 
> What might be better would be to modify my suggestion so that a <service> element can be included, and if not, the default is 'sos' and any children of 'sos'.
> 
> 
> At 9:48 PM +1100 12/23/14, James Winterbottom wrote:
> 
>> Hi Randy,
>> 
>> That could work, but that implies that you know what services that the system supports.
>> I think that I would rather make an assumption that emergency and the subset thereof are all we support and leave an extension point for people to extend from if the need ever arises.
>> 
>> 
>> Cheers
>> James
>> 
>> 
>>> On 23 Dec 2014, at 8:36 pm, Randall Gellens <randy@qti.qualcomm.com> wrote:
>>> 
>>  > I have a technical question about the draft.  From my reading, it appears that the extension is to add an empty <requestRoutingInformation> element to a HELD request, and if the server supports it, it includes a <routingInformation> element with all possible values that could be returned.  Is this correct or am I missing something?  If it is correct, why is the <requestRoutingInformation> element empty rather than contain the desired service?  Wouldn't it be simpler to include the specific service of interest (e.g., 'sos'), as in the <service> element from LoST and then the server only needs to look that up and return only that?
>>  >
>>> 
>>> At 4:19 PM +0000 12/22/14, Marc Linsner (mlinsner) wrote:
>>> 
>>>> All,
>>>> 
>>>> There is consensus to move forward with this work.
>>>> 
>>>> The chairs will request to the milestone addition for this draft to be submitted to the IESG by September 2015, of course earlier completion is always a good thing.
>>>> 
>>>> James, please submit a version as an IETF draft and we will approve.
>>>> 
>>>> Thanks,
>>>> 
>>>> Marc & Roger
>>>> ECRIT co-chairs
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> Ecrit@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>> 
>>> 
>>> --
>>> Randall Gellens
>>> Opinions are personal;    facts are suspect;    I speak for myself only
>>> -------------- Randomly selected tag: ---------------
>>> Go placidly amid the noise and waste, and remember what value there may
>>> be in owning a piece thereof.                        --National Lampoon
> 
> 
> -- 
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> Those are my principles. If you don't like them I have others.
>   --Groucho Marx