Re: [Ecrit] Does anyone support Planned-Changed?

[Dan Mongrain <[e-mail]>]

Just to be clear, RFC 5222 specifies a normative Relax NG schema for LoST,
it is found in section 15. Appendix A is simply the non-normative verbose
version of the schema. In my opinion any extension must include a normative
schema (pick your favourite schema language, as long it is unambiguous and
relatively well supported) and also clearly specify where in the previous
schema the extension is expected to be inserted (this is sometimes not well
specified).

Thanx,
Dan


*Dan Mongrain, eng.*Principal Engineer, Standards
*Motorola Solutions*

*o*: +1.819.931.2129
*m*: +1.613.558.0764
e: [e-mail]
www.linkedin.com/in/DanMongrain

*[image:
https://www.motorolasolutions.com/content/dam/msi/images/logos/corporate/msiemailsignature.png]*




On Wed, Sep 13, 2023 at 6:21 PM Dan Banks <dbanks=[e-mail]>
wrote:

> Well, I have been using the RelaxNG schema since the beginning of my
> involvement with LoST, and pretty much exclusively so.  I even used RelaxNG
> to define the extensions that I contributed to NENA years ago.  So I must
> dispute the notion that no one uses it.
>
>
>
> I do not agree that extensions need to be maintained in the same schema
> language (or in multiple languages), and I’ll point out that the location
> used in every findService request is included by way of an extension point
> and both civic and geodetic location schemas are defined by traditional XML
> schemas (RFC 5139 for civic, OGC 06-142r1 for geodetic) rather than RelaxNG.
>
>
>
> As I have expressed previously, I prefer that we NOT make the new xsd for
> LoST normative and that we avoid calling it a replacement.  I believe it
> should only be a non-normative alternative like we find in Appendix A of
> RFC 5222.
>
>
>
> I also believe that while point-in-time validation by a LoST server could
> be theoretically useful, in practice it would introduce substantial
> complication (to the GIS, the LoST server, and the LIS) while providing
> very little benefit.  It has been my experience that the quality and
> completeness of the underlying GIS data NOW is a far greater concern than
> the possibility (or even inevitability) that some portion will become
> invalid at a known time in the future.  For these reasons, I have not
> expressed support for this draft.
>
>
>
> At this point, it is my preference that this draft be allowed to expire
> and that the complete and similar location draft be updated to remove all
> references to planned changes and be moved forward on its own.  However, I
> have done a limited review of the -09 version and if it continues to be
> worked on, there are several issues that I see:
>
>
>
> The exceptionContainer defined on page 12 does not include the
> <SRSinvalid> element as a choice, but it should.
>
>
>
> There is a group and an attributeGroup both named “anyElement” that are
> defined but unused.  It is unclear if these were intended to be used to
> define extension points.  I believe the original LoST schema intended to
> allow attributes of any namespace at every extension point, and I think the
> xsd needs an attributeGroup at every occurrence of the extension point to
> accomplish that.  However, it is not clear to me if the original definition
> in compact form correctly expresses this.  Note that the non-normative
> version in 5222 Appendix A does seem to include attributes of any name at
> the extension point.
>
>
>
> Section 5 identifies the new expires element with single quotes, and says
> it takes the form of the ‘expires’ attribute pattern from 5222 (includes
> tokens) but the schema includes type=”xs:dateTime”.  This doesn’t work with
> ref, but the ref doesn’t work because expires doesn’t exist in the target
> namespace.  asOf is broken similarly.
>
>
>
> Further, the expiration pertains most specifically to the validation
> portion of the response.  I believe it would be less confusing to declare
> an attribute of a different name (such as ‘validUntil’) and place this
> directly into the <locationValidation> element rather than the
> <findServiceResponse>.
>
>
>
> Section 5 also makes reference to “coordinate changes”, and this is
> problematic given that validation only pertains to civic location.  And
> presumably, the exemplar use case of annexation would not involve any
> coordinate changes.  Nor would coordinate changes of a GIS feature by
> themselves necessarily impact the validation portion of the response.  This
> line should say something else.
>
>
>
> The draft defines a new interface to poll for changes, but provides no new
> mechanism for discovery.  Presumably this would work by modifying the URI
> discovered via U-NAPTR in some way, but first, this is not explained.
> Second, I am strongly opposed to mixing XML with a Rest/JSON interface at
> the same endpoint (even with a different http route).  Third, I do not
> believe that a service to provide a list of changes should be implemented
> within the same piece of software as a LoST server, although that is
> clearly an implementation decision.  However, lack of independent discovery
> of such a service would effectively require the use of a reverse proxy or
> similar mechanism in order to allow separate implementations.  Instead, if
> such a service is to exist, it should be independently discoverable using
> U-NAPTR using the name (application unique string) of the LoST server that
> provided validation as input along with a new service tag.  Then
> implementers can build the services however they wish.
>
>
>
> Section 9 includes text related to the server sending an HTTP request back
> to the client, which is functionality that is no longer included in the
> draft.  This affects a substantial portion of section 9.
>
>
>
> Finally, the introduction refers to RFC 4119.  It would be more
> appropriate to refer to RFC 5139.
>
>
>
> Dan Banks
>
>
>
>
>
> *From:* Ecrit <[e-mail]> *On Behalf Of * Brian Rosen
> *Sent:* Friday, September 8, 2023 1:12 PM
> *To:* [e-mail]
> *Cc:* ECRIT <[e-mail]>
> *Subject:* Re: [Ecrit] Does anyone support Planned-Changed?
>
>
>
> I will expand LIS, and change entry points to end points.  I’ll add the
> reference to Section 8.
>
>
>
> WRT to the XML schema:  we now have quite a bit of deployment experience
> with LoST.  No one (and I mean NO ONE) uses the RelaxNG schema.  They use
> an xml schema, normally one that NENA created because no one in NENA had
> ever used RelaxNG.
>
> I based the schema in the draft on the NENA schema.
>
>
>
> I would be very happy to obsolete the RelaxNG schema and replace it with
> the XML Schema.  That would avoid the necessity to maintain both in future
> extensions.  That would mean that this draft updates a few other RFCs that
> have LoST RelaxNG schemas.
>
>
>
> We did have discussions long ago about where to make the change to XML
> Schemas, and this was the draft we decided to do it in.  I would not want
> to split the draft at this point.
>
>
>
> I did engage an expert (Peter Saint Andre)  to verify that the XML Schema
> matched the RelaxNG schema.  He helped me fix several errors I made.  I’m
> pretty confident they are the same, but there is no tool that could
> validate it.
>
>
>
> Brian
>
>
>
> On Sep 8, 2023, at 10:24 AM, [e-mail] wrote:
>
>
>
> Resending
>
>
>
> *From:* [e-mail] <[e-mail]>
> *Sent:* Freitag, 8. September 2023 14:55
> *To:* 'Randall Gellens' <[e-mail]>; 'ECRIT' <
> [e-mail]>
> *Subject:* RE: [Ecrit] Does anyone support Planned-Changed?
>
>
>
> Hi Randy,
>
>
>
> I have read the document and I believe it is a useful and important
> extension.
>
>
>
> Here are my high-level comments.
>
>
>
> 1. On the editorial side, please expand LIS when first used.
>
>
>
> 2. Section 3 talks about "entry points" in context of the new RESTful
> APIs. The correct terminolgy would, however, be "endpoints". The
> description of the API in that section is incomplete. A reference to
> section 8 would be appropriate, which uses the OpenAPI functionality (which
> I am not familiar with).
>
>
>
> 3. The more substantive comment concerns the introduction of the XML
> schema for LoST. Since the title does not indicate the presence of this
> description in the document it is a bit surprising. I was wondering why you
> didn't just produce a new draft that contains the XML schema where the
> title clearly indicates it.
>
>
>
> There is one annoying consequence: if you introduce two schema languages
> for LoST, namely RelaxNG and the XML schema, then every extension going
> forward should actually specify the extension in both schema languages to
> deal with the installed base.
>
>
>
> FWIW I have not checked the XML schema against the Relax NG schema and
> validated the examples against this new schema. I hope Brian did it. It
> would be unfortunate if the newly proposed XML schema is not in sync with
> the previously published functionalty or even buggy.
>
>
>
> Ciao
>
> Hannes
>
>
>
>
>
>
>
> *From:* Ecrit <[e-mail]> *On Behalf Of *Randall Gellens
> *Sent:* Mittwoch, 30. August 2023 18:39
> *To:* ECRIT <[e-mail]>
> *Subject:* [Ecrit] Does anyone support Planned-Changed?
>
>
>
> Members of IETF ECRIT WG:
>
> The two-week IETF WG Last Call on the Planned Changes drat closes *TODAY*.
> Supposedly, this is a document that NENA i3 needs and has been waiting on.
>
> To date the IETF ECRIT mailing list has received exactly *ZERO* comments
> on the draft during this WG last call. The logical conclusion is that no
> one cares about the draft and it should die. Is that accurate? Or is it
> just that everyone is still on August break/doldrums? I need to know.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-planned-changes/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Decrit-2Dlost-2Dplanned-2Dchanges_&d=DwMFAg&c=q3cDpHe1hF8lXU5EFjNM_C93KOmcBXCBnhee2v6PYlc&r=n9aaU9xSQM4-mK_yF4tJzi7SeOWS3tTUWut1BhcRBI5vMR5LUWrTKzC_1DF8wC_4&m=X2768NzoyAFm1ieVgbUsRQVdR5awqUaTH36DFAM9shf_cQuM7BGM52KI0_NgKtVK&s=wajjbtm2X6DVifuGkOqQBxKQSJoMFHM9YvOZa6HWB2k&e=>
>
> There is also an HTML version available at:
>
> https://www.ietf.org/archive/id/draft-ietf-ecrit-lost-planned-changes-08.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dietf-2Decrit-2Dlost-2Dplanned-2Dchanges-2D08.html&d=DwMFAg&c=q3cDpHe1hF8lXU5EFjNM_C93KOmcBXCBnhee2v6PYlc&r=n9aaU9xSQM4-mK_yF4tJzi7SeOWS3tTUWut1BhcRBI5vMR5LUWrTKzC_1DF8wC_4&m=X2768NzoyAFm1ieVgbUsRQVdR5awqUaTH36DFAM9shf_cQuM7BGM52KI0_NgKtVK&s=RN_60M30Bgt2Vf6il2RxOvYy1FBRMr1ZYLoHx9ASjzk&e=>
>
> A diff from the previous version is available at:
>
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ecrit-lost-planned-changes-08
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__author-2Dtools.ietf.org_iddiff-3Furl2-3Ddraft-2Dietf-2Decrit-2Dlost-2Dplanned-2Dchanges-2D08&d=DwMFAg&c=q3cDpHe1hF8lXU5EFjNM_C93KOmcBXCBnhee2v6PYlc&r=n9aaU9xSQM4-mK_yF4tJzi7SeOWS3tTUWut1BhcRBI5vMR5LUWrTKzC_1DF8wC_4&m=X2768NzoyAFm1ieVgbUsRQVdR5awqUaTH36DFAM9shf_cQuM7BGM52KI0_NgKtVK&s=iS1DIUpuIB6xNSOThp58iGJ1AUUzmNDZnlbE2jwSLLs&e=>
>
> --Randall
>
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ecrit&d=DwMFAg&c=q3cDpHe1hF8lXU5EFjNM_C93KOmcBXCBnhee2v6PYlc&r=n9aaU9xSQM4-mK_yF4tJzi7SeOWS3tTUWut1BhcRBI5vMR5LUWrTKzC_1DF8wC_4&m=X2768NzoyAFm1ieVgbUsRQVdR5awqUaTH36DFAM9shf_cQuM7BGM52KI0_NgKtVK&s=MZhnoO__1sQuhWThBJT9VohDeVgErdMyH0mCGhMH-Qo&e=>
>
>
> _______________________________________________
> Ecrit mailing list
> [e-mail]
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ecrit&d=DwICAg&c=q3cDpHe1hF8lXU5EFjNM_C93KOmcBXCBnhee2v6PYlc&r=n9aaU9xSQM4-mK_yF4tJzi7SeOWS3tTUWut1BhcRBI5vMR5LUWrTKzC_1DF8wC_4&m=X2768NzoyAFm1ieVgbUsRQVdR5awqUaTH36DFAM9shf_cQuM7BGM52KI0_NgKtVK&s=MZhnoO__1sQuhWThBJT9VohDeVgErdMyH0mCGhMH-Qo&e=
>

-- 


*For more information on how and why we collect your personal 
information, please visit our Privacy Policy 
<https://www.motorolasolutions.com/en_us/about/privacy-policy.html?elqTrackId=8980d888905940e39a2613a7a3dcb0a7&elqaid=2786&elqat=2#privacystatement>.*