Subject: [Ecrit] draft-ietf-lost-00 comments

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 2 Jul 2006 20:00:44 -0500

Ecritters, LoST folks,

Here are my comments on the LoST draft.  There are obvious gaps that I know you are still working on, so I'll try to avoid too much in those areas.

Interesting claim:
   o  Mapping can be based on either civic or geospatial location
      information, with no performance penalty for either.

...this could look like a claim about a LoST database implementation, which would be presumptuous.  Suggest that it is made a little clearer.  This leads to my next point...

The findLoSTByGeo and findLoSTByCivic (the capitalization makes those tough to type, BTW) are fundamentally identical, so why is there a need for separate names for these queries?  I preferred the earlier iterations where the location was just a choice element.  The element name is the name of the operation, and, in terms of semantics, there is only one operation here: 'findLoST'.

Examples include xsi namespace prefix declarations.

You refer to the civic location format in RFC 4119 rather than the format in draft-ietf-geopriv-revised-civic-lo.  The RFC 4119 format doesn't include a range of elements that might be necessary.  (You have declared a NS prefix for the revised civic address in the schema, but it isn't used.)

/Section 6/  It is probably worth noting that only one result is returned.  Multiple URIs are only provided as alternative means of contact for that one entity, i.e. different schemes.

/Section 6.1/  Relative URIs are noted as being SHOULD NOT.  However, if it is possible to use them, there needs to be some guidance on how to determine the base URI.  There might be some confusion about whether the service URN is the base URI or not (and I can't see how this would be possible unless you want recursive resolution...and I'm sure you aren't completely insane).  Here is the list you use for base URI resolution:

   1. The base URI is embedded in the document's content.
   2. The base URI is that of the encapsulating entity (message, document, or none).
   3. The base URI is the URI used to retrieve the entity.
   4. The base URI is defined by the context of the application.

I can't see which of these are realistically applicable.  I would prefer if you prevented relative URIs by using a regex:

  <xs:pattern value="[a-zA-Z][-a-zA-Z+\.]*:.*"/>

/Section 6.6/ s/by by/by/

  This section also needs to make it clear that "validated" doesn't apply to geodetic information.

/Section 6.3/ s/one or more civic location/one or more location/

  I would also like to see the Polygon element wrapped in some manner consistent with GML practice:

  <responseGeo>
    <region>
      <gml:Polygon>...</gml:Polygon
    </region>
    ...
  </responseGeo>

Again, the responseGeo and responseCivic elements are largely identical; two different elements give an impression of a separation.

The similarities between the different result types could be further exploited with the definition of the base type lost:resultType. 

In schema, the responseCivic doesn't include a definition for validated.  Both response types don't include the "text" element.

Why is there a lower limit of zero on the URI in the response?  Shouldn't there be an error code for "we can't find it", or is the answer just mysteriously missing when that happens?

The dialstring element should include stricter restrictions than just normalizedString.  Is this digits only?  Or do you want to support 1-800-555-FOOD in the dialstring (and the gamut of localized variations)?

The error codes should not be reflected in different error message elements.  This makes it messy to do things like define MIME types if the root element changes.  Error codes that aren't understood by an implementation are harder to recognize if the element changes.  It also mixes content and structure in a way that I don't like.  I would prefer to see something like:

   <error code="invalidcivic" xml:lang="en">
     That was naughty.
   </error>

How do you want to do error codes?  Will you setup an IANA registry?  Will you permit extensions to the set of errors?  Sorry, I just got into the undefined territory.

Cheers,
Martin 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

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

---

From: Andrew Newton <[email-masked]>
Date: Sun, 2 Jul 2006 21:34:55 -0400

On Jul 2, 2006, at 9:00 PM, Thomson, Martin wrote:
> The findLoSTByGeo and findLoSTByCivic (the capitalization makes  
> those tough to type, BTW) are fundamentally identical, so why is  
> there a need for separate names for these queries?  I preferred the  
> earlier iterations where the location was just a choice element.   
> The element name is the name of the operation, and, in terms of  
> semantics, there is only one operation here: 'findLoST'.

Changing this to a single query is mostly dependent on the outcome of  
the discussion this working group has had regarding multiple  
locations in a query.  We discussed changing this just before  
submitting the draft but determined that the true shape of the query  
will be based on the working groups discussion on this topic, so we  
left it alone.  You are right, it could be converted to a single  
'findLoST'.

Looking at this query from the standpoint of a recursive resolver,  
which hierarchy is used in a composite location scenario?  The actual  
specification of byGeo or byCivic might answer that question.  I  
stress "might" as I have not thought long and hard about this  
particular problem.

> Examples include xsi namespace prefix declarations.

Harmless, but yes they should be removed.  Won't matter when we  
switch to Relax NG.

> The dialstring element should include stricter restrictions than  
> just normalizedString.  Is this digits only?  Or do you want to  
> support 1-800-555-FOOD in the dialstring (and the gamut of  
> localized variations)?

I understand this point, but ultimately if a server wishes to spew  
crap back to a client there is very little a client can do about it.

> The error codes should not be reflected in different error message  
> elements.  This makes it messy to do things like define MIME types  
> if the root element changes.  Error codes that aren't understood by  
> an implementation are harder to recognize if the element changes.   
> It also mixes content and structure in a way that I don't like.  I  
> would prefer to see something like:
>

I really don't care which way this is done, but I'm not sure your  
reason regarding the MIME type is correct.  Otherwise text/xml or  
application/xml would never be used, which we know not to be the  
case.  With regard to recognition of the element names, that's why  
there is an XML namespace.

> How do you want to do error codes?  Will you setup an IANA  
> registry?  Will you permit extensions to the set of errors?  Sorry,  
> I just got into the undefined territory.

Versioning of the protocol is how I would prefer to do it, which  
probably means I lean much more towards keeping the current element  
names.

-andy

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 3 Jul 2006 01:01:32 -0500

Hi Andy,

Thanks for the response; I've replied inline.

Cheers,
Martin

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Monday, 3 July 2006 11:35 AM
> To: Thomson, Martin
> Cc: [email-masked]
> Subject: Re: [Ecrit] draft-ietf-lost-00 comments
> 
> 

This can be separated from the composite location issue.  If the composite happens then it has to be just one query, easy; but if composite doesn't happen, then I think this comment still stands.  I think that a single request is easier to deal with - the choice is in the type of location information provided.

> stress "might" as I have not thought long and hard about this

I think that how a recursive or hierarchical resolver operates can be separated from this as well.

> Harmless, but yes they should be removed.  Won't matter when we

"when"?  I guess the issue tracker isn't up to date.  That's cool.

> crap back to a client there is very little a client can do about it.

True 'nuff, I'll let the design team sort this one out.  Henning just gave me a rundown of the alternatives and I can see the tradeoff here.
 
> there is an XML namespace.

This is why I asked the question below.  Your extension model determines the validity of this approach.  Versioning is only one aspect of that - whether or not you allow extra codes affects the decision.  The MIME type comment was a stray thought - the others actually concern me more.  Carrying values in element names has a long tradition, but it isn't particularly robust with regards to new values.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 03 Jul 2006 11:35:23 +0200

Hi Martin,

thanks for the review. Let me address a few comments below:

Thomson, Martin wrote:
> Ecritters, LoST folks,
> 
> Here are my comments on the LoST draft.  There are obvious gaps that
> I know you are still working on, so I'll try to avoid too much in
> those areas.

We want to discuss the gaps as well.

> 
> Interesting claim: o  Mapping can be based on either civic or
> geospatial location information, with no performance penalty for
> either.
> 
> ...this could look like a claim about a LoST database implementation,
> which would be presumptuous.  Suggest that it is made a little
> clearer.  This leads to my next point...

I have that we should rephrase it a bit. Now, it sounds a little bit 
like a marketing phrase to me.

> 
> The findLoSTByGeo and findLoSTByCivic (the capitalization makes those
> tough to type, BTW) are fundamentally identical, so why is there a
> need for separate names for these queries?  I preferred the earlier
> iterations where the location was just a choice element.  The element
> name is the name of the operation, and, in terms of semantics, there
> is only one operation here: 'findLoST'.

I agree with Andy that we should deal with this aspect once we reached a 
conclusion with regard to the multiple/composite location query question.

> Examples include xsi namespace prefix declarations.

Will be fixed.

> 
> You refer to the civic location format in RFC 4119 rather than the
> format in draft-ietf-geopriv-revised-civic-lo.  The RFC 4119 format
> doesn't include a range of elements that might be necessary.  (You
> have declared a NS prefix for the revised civic address in the
> schema, but it isn't used.)

Could you be more specific about the range of element aspect here?

> 
> /Section 6/  It is probably worth noting that only one result is
> returned.  Multiple URIs are only provided as alternative means of
> contact for that one entity, i.e. different schemes.

Fine.

> 
> /Section 6.1/  Relative URIs are noted as being SHOULD NOT.  However,
> if it is possible to use them, there needs to be some guidance on how
> to determine the base URI.  There might be some confusion about
> whether the service URN is the base URI or not (and I can't see how
> this would be possible unless you want recursive resolution...and I'm
> sure you aren't completely insane).  Here is the list you use for
> base URI resolution:
> 
> 1. The base URI is embedded in the document's content. 2. The base
> URI is that of the encapsulating entity (message, document, or none).
>  3. The base URI is the URI used to retrieve the entity. 4. The base
> URI is defined by the context of the application.
> 
> I can't see which of these are realistically applicable.  I would
> prefer if you prevented relative URIs by using a regex:
> 

Hmmm. Sounds too complicated to me. Hence, we shouldn't use them.

> apply to geodetic information.

You are right.

I am still not happy about the term and the usage in Section 5.8 of 
draft-rosen-ecrit-emergency-framework-00.txt (for both geo and civic) is 
confusing.

> <responseGeo> <region> <gml:Polygon>...</gml:Polygon </region> ... 
> </responseGeo>

Ok.

> 
> Again, the responseGeo and responseCivic elements are largely
> identical; two different elements give an impression of a separation.
> 
> 
> The similarities between the different result types could be further
> exploited with the definition of the base type lost:resultType.

We could do that.

> 
> In schema, the responseCivic doesn't include a definition for
> validated.  Both response types don't include the "text" element.

That's true. It seems that we haven't copied the latest schema from
http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/Schema/

to the draft.

> 
> Why is there a lower limit of zero on the URI in the response?
> Shouldn't there be an error code for "we can't find it", or is the
> answer just mysteriously missing when that happens?

Needs to be fixed.

> 
> The dialstring element should include stricter restrictions than just
> normalizedString.  Is this digits only?  Or do you want to support
> 1-800-555-FOOD in the dialstring (and the gamut of localized
> variations)?

In some sense we noted this issue already at:

http://www.tschofenig.priv.at:8080/lost/issue8

> elements.  This makes it messy to do things like define MIME types if
> the root element changes.  Error codes that aren't understood by an
> implementation are harder to recognize if the element changes.  It
> also mixes content and structure in a way that I don't like.  I would
> prefer to see something like:
> 
> <error code="invalidcivic" xml:lang="en"> That was naughty. </error>
> 
> How do you want to do error codes?  Will you setup an IANA registry?
> Will you permit extensions to the set of errors?  Sorry, I just got
> into the undefined territory.

Error codes are certainly an open issue of the current version.
http://www.tschofenig.priv.at:8080/lost/issue15

Ciao
Hannes

> Cheers, Martin
>  This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise private information. If you
> have received it in error, please notify the sender immediately and
> delete the original.  Any unauthorized use of this email is
> prohibited. 
> ------------------------------------------------------------------------
> 
> 
> _______________________________________________ Ecrit mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 3 Jul 2006 18:30:07 -0500

Hi Hannes,

<snip> 
> conclusion with regard to the multiple/composite location query question.

I think that a single query/operation is more suitable, even if we decide not to support multiple/composite locations.

<snip>
> Could you be more specific about the range of element aspect here?

The revised civic draft contains ~12 elements that 4119 doesn't.  These elements are all defined in the civic draft, and may be necessary for routing in some countries.  In particular, the road structure elements are new.

<snip>

Cheers,
Martin

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 04 Jul 2006 09:33:25 +0200

Hi Martin,

Thomson, Martin wrote:
>>> there a need for separate names for these queries?  I preferred
>>> the earlier iterations where the location was just a choice
>>> element.  The element name is the name of the operation, and, in
>>> terms of semantics, there is only one operation here: 'findLoST'.
>>> 
>> 
>> I agree with Andy that we should deal with this aspect once we
>> reached a conclusion with regard to the multiple/composite location
>> query question.
>> 
> 
> 
> I think that a single query/operation is more suitable, even if we
> decide not to support multiple/composite locations.

I agree. We started with the discussion about sending multiple location 
information within a single query and the tendency was that this is not 
a good approach. During the discussion the aspect of composite location 
showed up. It made some sense to me although we are certainly talking 
about corner cases.

We need to make a decision about it soon.

> 
> <snip>
> 
>>> You refer to the civic location format in RFC 4119 rather than
>>> the format in draft-ietf-geopriv-revised-civic-lo.  The RFC 4119
>>> format doesn't include a range of elements that might be
>>> necessary.  (You have declared a NS prefix for the revised civic
>>> address in the schema, but it isn't used.)
>> 
> The revised civic draft contains ~12 elements that 4119 doesn't.
> These elements are all defined in the civic draft, and may be
> necessary for routing in some countries.  In particular, the road
> structure elements are new.

Got your point. You are right that the reference to 
draft-ietf-geopriv-revised-civic-lo would be more appropriate.

Ciao
Hannes