RE: [Geopriv] What was conclusion to <provided-by>?

All,

The NENA VoIP Location WG has agreed to provide an XML schema definition for
<provided-by> that includes: a NENA ID, a 24x7 Telephony Number, and a URL.
Vis a vis the concerns about international applicability, this could be
included as an example. The proposed XML schema is still under review by
the WG, but might look something like the following.

<xs: complexType name=<provided-by>
                <xs:complexType name="DataProviderIDType">
                        <xs:annotation>
                                <xs:documentation>NENA registered Company ID
for Service Provider supplying ALI record source
information</xs:documentation>
                        </xs:annotation>
                        <xs:all>
                                <xs:element name="DataProviderID"
type="tns:NENACompanyIDType" minOccurs="0"/>
                                <xs:element name="TN" type="tns:TN_24x7Type"
minOccurs="0"/>
                                <xs:element name="URL" type="xs:anyURI"
minOccurs="0"/>
                        </xs:all>
                </xs:complexType>
                <xs:simpleType name="NENACompanyIDType">
                        <xs:annotation>
                                <xs:documentation>NENA registered Company
ID.</xs:documentation>
                        </xs:annotation>
                        <xs:restriction base="xs:string">
                        <xs:maxLength value="5"/>
                        </xs:restriction>
                </xs:simpleType>
                <xs:simpleType name="TN_24x7Type">
                        <xs:annotation>
                                <xs:documentation>24x7 TN for the caller's
facility based service provider. To be used for Trap/Trace, emergency line
interrupts. Possible values TN number, SPID Errors.</xs:documentation>
                        </xs:annotation>
                        <xs:union memberTypes="tns:TNType">
                                <xs:simpleType>
                                        <xs:restriction base="xs:string">
                                                <xs:maxLength value="10"/>
                                                <xs:enumeration value="NOT
FOUND"/>
                                                <xs:enumeration
value="UNAVAILABL"/>
                                        </xs:restriction>
                                </xs:simpleType>
                        </xs:union>
                </xs:simpleType>
</xs:complexType>

(Actually, we have in hand a whole XML schema using NENA definitions of the
entire civil location object, but I realize that's too late for
consideration at this point.)

More coming when I hear back from the WG.....

Regards,

Nadine Abbott, ENP
Senior Engineer
Telcordia Technologies, Inc.
(732) 758-5257
nabbott@telcordia.com

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Friday, April 02, 2004 1:24 PM
To: 'Abbott, Nadine B.'; geopriv@ietf.org
Subject: RE: [Geopriv] What was conclusion to <provided-by>?

The problem with this is that I really doubt the international
bodies will be happy with a NENA registry as the only choice,
and yet there is no current alternative registry. Thus, I think
the original proposal is more appropriate.

Brian

> -----Original Message-----
> From: Abbott, Nadine B. [mailto:nabbott@telcordia.com]
> Sent: Wednesday, March 31, 2004 1:16 PM
> To: geopriv@ietf.org
> Subject: RE: [Geopriv] What was conclusion to <provided-by>?
>
>
> James and all,
>
> Andy had suggested a possible alternative of
>
> <provided-by> <nena> abc-123 </nena> </provided-by>
>
> Where abc-123 represents a NENA ID.
>
> I think this could be an acceptable alternative from NENA's
> point of view
> (although the contents should probably be defined as an
> alphanumeric string
> of text rather than as abc-123). I think I could provide you with a
> reference to a NENA XML schema to be referenced here instead
> as an example,
> if that would be helpful.
> However, if this would mean deferring inclusion of ANY
> identifier, it's
> probably not a good idea.
>
> I think that the URL was proposed as potentially more
> universal/internationally applicable form of <provided-by>.
>
> Nadine
>
>
> -----Original Message-----
> From: geopriv-admin@ietf.org [mailto:geopriv-admin@ietf.org]
> On Behalf Of
> James M. Polk
> Sent: Wednesday, March 31, 2004 12:22 PM
> To: geopriv@ietf.org
> Subject: [Geopriv] What was conclusion to <provided-by>?
>
>
> All
>
> As few things "stand still" or "are in a vacuum".... I'd like
> to know what
> the conclusion was to our <provided-by> discussions. I
> understand what Ted
> stated in his last email - but feel the pressure is not just
> about getting
> a workable protocol document out, but one that is usable. The
> Emergency
> case is one of (if not "the") first uses of our LO, and there
> is a function
> that's desired that is in dispute
>
> <provided-by>
>
> I would like to know the status or progress of this element
> into the LO.
>
> BTW - I feel, even if it's written right now and posted
> tomorrow, anything
> "Phase II" will be more than a year away from going to the
> IESG.... so I'm
> less than enthused to gracefully let this feature slide out.
>
> cheers,
> James
>
> *******************
> Truth is not to be argued... it is to be presented
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Fri, 2 Apr 2004 14:43:11 -0500