Subject: [Ecrit] Fwd: New Version Notification for draft-rosen-ecrit-lost-return-li-00

From: Brian Rosen <[email-masked]>
Date: Tue, 29 Mar 2011 14:02:16 +0200

I have just submitted a new draft that does one simple thing: allow location information to be returned in a <findServiceResponse>, when validation is requested, the LI in the request was valid, but the LoST server knew more CAtypes for the location than were in the request.

A simple example is an address with a postal code, but without an A1, A2 or A3 CAtypes.  The LoST server may discover that it knows precisely where the the LI is, but it would be helpful for the querier to get the A1, A2 and A3 values back from the server.  This allows the LoST sever to return LI.

Please forgive the RELAX stuff.  I am clueless, and need to find someone to help me do it right.

Brian

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: March 29, 2011 1:27:34 PM GMT+02:00
> To: [email-masked]
> Subject: New Version Notification for draft-rosen-ecrit-lost-return-li-00 
> 
> 
> A new version of I-D, draft-rosen-ecrit-lost-return-li-00.txt has been successfully submitted by Brian Rosen and posted to the IETF repository.
> 
> Filename:	 draft-rosen-ecrit-lost-return-li
> Revision:	 00
> Title:		 Returning a Location Information in a Location to Service Translation query
> Creation_date:	 2011-03-29
> WG ID:		 Independent Submission
> Number_of_pages: 7
> 
> Abstract:
> This document defines an extension to LoST (RFC5222) to permit a
> location information to be returned in a findservice response.  When
> the validation is requested in the findservice request, the location
> information supplied in the request may have enough valid address
> components (CAtypes) to be considered valid, but the LoST server may
> wish to return address components CAtypes not found in the query.
> 
> 
> 
> The IETF Secretariat.
> 
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 29 Mar 2011 14:13:40 +0200

How does this relate to Roger's "similar location" draft?
--Richard

On Mar 29, 2011, at 2:02 PM, Brian Rosen wrote:

> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Brian Rosen <[email-masked]>
Date: Tue, 29 Mar 2011 14:18:08 +0200

He sends LI when the input LI is invalid.  This sends LI when the input LI is valid.

Brian

---

From: Brian Rosen <[email-masked]>
Date: Tue, 29 Mar 2011 14:19:59 +0200

Also, his may have one or more CAtypes that are different from the input LI.

Brian

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 29 Mar 2011 14:21:33 +0200

So couldn't we just merge the two and send LI the same way regardless?  Maybe with a tag to say whether the input LI is valid or not?
--Richard

---

From: Brian Rosen <[email-masked]>
Date: Tue, 29 Mar 2011 14:30:36 +0200

The thought occurred to me.  You get the validity tag already.  They really are different things, but it terms of extensions, it's very close (adding LI in the findserviceresponse).

Brian

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 29 Mar 2011 22:49:51 +0800

I think that you could probably merge the two even if they aren't precisely the same thing.

On 2011-03-29 at 14:30:36, Brian Rosen wrote:
> The thought occurred to me.  You get the validity tag already.  They 
> really are different things, but it terms of extensions, it's very 
> close (adding LI in the findserviceresponse).
> 
> Brian
> 
> > So couldn't we just merge the two and send LI the same way
> regardless?  Maybe with a tag to say whether the input LI is valid or 
> not?
> > --Richard
> >
> >
> >>>> I have just submitted a new draft that does one simple thing:
> allow location information to be returned in a <findServiceResponse>, 
> when validation is requested, the LI in the request was valid, but the 
> LoST server knew more CAtypes for the location than were in the 
> request.
> >>>>
> >>>> A simple example is an address with a postal code, but without an
> A1, A2 or A3 CAtypes.  The LoST server may discover that it knows 
> precisely where the the LI is, but it would be helpful for the querier 
> to get the A1, A2 and A3 values back from the server.  This allows the 
> LoST sever to return LI.
> >>>>
> >>>>> A new version of I-D, draft-rosen-ecrit-lost-return-li-00.txt 
> >>>>> has
> been successfully submitted by Brian Rosen and posted to the IETF 
> repository.
> >>>>>
> >>>>> location information to be returned in a findservice response.
> >>>>> When the validation is requested in the findservice request, the 
> >>>>> location information supplied in the request may have enough
> valid
> >>>>> address components (CAtypes) to be considered valid, but the 
> >>>>> LoST server may wish to return address components CAtypes not 
> >>>>> found in
> the query.
> >>>>>
> >>>>>
> >>>>>
> >>>>> The IETF Secretariat.
> >>>>>
> >>>>>
> >>>>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 29 Mar 2011 16:53:45 +0200

Authors have concluded merging makes sense. 

Brian