Subject: [Ecrit] AD Evaluation: draft-ietf-ecrit-lost-servicelistboundary-04

From: Robert Sparks <[email-masked]>
Date: Tue, 23 Nov 2010 12:58:00 -0600

I've requested IETF Last call of this document.

A question:

The examples use a civic address boundary (of Lower Austria). Do you expect automata to be able to recognize when they have
left these regions? (Would a phone be able to turn "Lower Austria" into a polygon so that it would know when it left?). Would it have
made more sense to have constructed these examples with geospatial regions?

----
Some suggestions:

Since the introduction is long, it would help to move the main point of the introduction (currently in the last paragraph) to the front of the section.

On page 4, 2nd to last paragraph, the sentence "Nevertheless, the client does not detect this, because only the mapping of the initially discovered services (police, ambulance, fire) are refreshed." is hard to parse.
I suggest "Since the client is only required to refresh the mappings for the initially discovered services, the new service is not detected."

At the top of page 10, the phrase "so no boundary information is reasonable" is ambiguous. Is it trying to say
"there is no boundary information that is reasonable to send" or "it is reasonable to send no boundary information"?

---

From: Brian Rosen <[email-masked]>
Date: Tue, 23 Nov 2010 14:03:46 -0500

Yes, I think it will recognize when it left that area.  If it's using civic, then it gets a civic address, and it can check. If it's getting geo locations, it needs a geo boundary.

We don't have any instances of any element needing to geocode or reverse geocode, and I don't want to have any.

Brian

On Nov 23, 2010, at 1:58 PM, Robert Sparks wrote:

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

---

From: Karl Heinz Wolf <[email-masked]>
Date: Wed, 24 Nov 2010 13:17:04 +0100

Robert,

> made more sense to have constructed these examples with geospatial regions?

For clients knowing their civic address a civic boundary makes sense,
no geocoding desired.
In order to ensure that each client gets suitable boundary information
Section 3.3 says:

   The server ... MUST use at least one profile that the client used in
   the request in order to ensure that the client is able to process the
   boundary information.

> Since the introduction is long, it would help to move the main point of the introduction (currently in the last paragraph) to the front of the section.

ok

> I suggest "Since the client is only required to refresh the mappings for the initially discovered services, the new service is not detected."

ok

> "there is no boundary information that is reasonable to send" or "it is reasonable to send no boundary information"?

Would putting the sentence this way make it clearer:
The <listServices> request is purely for diagnostic purposes and does
not contain location information at all, so boundary information
cannot be calculated.

Thank you for your suggestions, I'll note them.

Karl Heinz

---

From: Robert Sparks <[email-masked]>
Date: Wed, 24 Nov 2010 07:58:37 -0600

<trim/>

> not contain location information at all, so boundary information

Yes - thanks!