Subject: [Ecrit] draft-ietf-ecrit-lost-01.txt

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 04 Sep 2006 20:02:51 +0200

Hi all,

we have just submitted a draft update. Please find it here:
http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit-lost-01.txt

If you look at the diff between -00 and -01 then you will notice the 
following changes:

* XML schema was replaced by a Relax NG schema.
Section 13 contains the Relax NG schema in the compact form. Appendix A 
contains the RELAX NG schema in XML syntax.

Schema elements itself got modified.

This aspect resolved issue 13:
http://www.tschofenig.priv.at:8080/lost/issue13

* Section 7 contains an update to the List Services Query/Response message.

This aspect resolved issue 3:
http://www.tschofenig.priv.at:8080/lost/issue3

* Section 8 contains status codes.

This aspect resolved issue 15:
http://www.tschofenig.priv.at:8080/lost/issue15

* Section 9 provides information about the transport using HTTP & HTTPS.

This aspect resolved issue 14:
http://www.tschofenig.priv.at:8080/lost/issue14

* Section 10 defines LoST URLs.

This is a starting point for addressing issue 5 and 11.
http://www.tschofenig.priv.at:8080/lost/issue5
http://www.tschofenig.priv.at:8080/lost/issue11

* Section 15 provides IANA considerations.

* Other editorial fixes

There are a few more open issues (as you can recognize at 
http://www.tschofenig.priv.at:8080/lost) but we would very much appreciate 
comments to get closer to an implementable specification.

Ciao
Hannes

PS: Just before we submitted the draft we noticed that the 
acknowledgment section is still empty. We are going to fix this with the 
next draft update.

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

---

From: Michael Haberler <[email-masked]>
Date: Tue, 12 Sep 2006 03:58:08 +0200

Hannes -

comment on "Figure 7: Response Message Example providing Civic Location
Servic Boundary Hints":

I think if a "service area" is returned, it should be possible to
interpret it without further processing as an unambiguous geospatial
object - assuming it should drive client behaviour (when do I need to
re-fetch psap destination?) EXCEPT if the intent is usage solely for
human consumption.

if the former is the case, how do I interpret

<A1>Bavaria</A1>
<A3>Munich</A3>
<PC>81675</PC>

e.g as a polygon? I would assume that this could be the intersection of shapes of A1,A3 and PC. 

That would require to fetch shapes for A1, A3 and PC "somehow" and intersect them. 
Or just PC? that would imply "smallest shape counts"; again fetching the shape needed, how?
 
Suggestion: always return geo polygons, and optionally return the civic name for use as a display name.

-Michael

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 12 Sep 2006 08:56:02 -0400

I would want a return like
> <PC>81675</PC>
To mean that as long as I was in 81675, Munich, I could use the same URI.
If I got out of that area, I should ask for a new mapping.  I don't need a
polygon for that.

This is a very practical answer.  If you get a civic address, I don't think
returning a polygon is practical.

Brian

> -----Original Message-----
> From: Michael Haberler [mailto:[email-masked]]
> Sent: Monday, September 11, 2006 9:58 PM
> To: Hannes Tschofenig
> Cc: ECRIT
> Subject: Re: [Ecrit] draft-ietf-ecrit-lost-01.txt - service area
> boundaries
> 
> Hannes -
>

---

From: Andrew Newton <[email-masked]>
Date: Tue, 12 Sep 2006 09:43:54 -0400

> returning a polygon is practical.

Just to further the clarification, if a seeker submits a civic address in a 
query, they will get a civic address back as the service boundary.  If a 
seeker submits a geodetic address, they will get a geodetic shape back as a 
service boundary.

Perhaps the draft ought to be clearer on that point.

-andy