Subject: [Ecrit] Add'l-Data-22: GCaron substantive comments

From: "Caron, Guy (A162859)" <[email-masked]>
Date: Fri, 18 Jul 2014 15:38:44 -0400

Hi ECRIT,

This email contains comments that may require technical changes to the document to address.

Thanks for considering these.

Guy

==============
Section 3.1.4. Type of Data Provider

COMMENT 1: It is not clear to me why the type of data provider is strictly associated with Data Provider ID and not extended to Data Provider String which is the mandatory element of this structure. I note that the XML schema does not enforce this, only the text seems to provide that limitation. It seems to me that allowing the type of provider to be associated with the data provider string would provide the same benefits, but to a larger community of providers. Since <DataProviderString> is mandatory, I suggest making <TypeofProvider> mandatory as well. 

SUGGESTED CHANGE FOR COMMENT 1:

Current text:
Use:  Conditional.  If Data Provider ID is provided, Type of Data Provider ID is required.

Proposed text:
Use:  Required.

==============
Section 3.1.5. Data Provider Contact URI

COMMENT 2: The guidance provided in relation to URI formats is confusing. First, it is not clear in the text that a generic SIP URI is supported or appropriate (the XML schema allows it).

COMMENT 3: In relation to telephone numbers, perhaps it should be explicitly stated that E.164 format is REQUIRED/RECOMMENDED/PREFERRED to ensure global numbers are provided?

SUGGESTED CHANGE FOR COMMENTS 2 & 3:

Current text: If a telephone number is the contact address then it MUST be a tel URI.

Proposed text: Generic SIP URIs are supported however, if a telephone number is the contact address then it MUST be a tel URI in E.164 format.

COMMENT 4: The guidance with respect to supporting telephone numbers is unclear. Sentence "If it is provided as a SIP URI then it MUST be in the form of sip:telephonenumber@serviceprovider:user=phone." seems to conflict with "If a telephone number is the contact address then it MUST be a tel URI." previously stated.

SUGGESTED CHANGE FOR COMMENT 4: Drop the sentence about sip:telephonenumber@serviceprovider:user=phone.

==============
Section 3.2.2. Service Type, Figure 3

COMMENT 5: MLTS that are hosted, like Centrex service, bear specific regulatory requirements in some jurisdictions in support of emergency calling. Knowing it is such a service can be very useful to the PSAPs. A distinct value would be warranted in my view.

SUGGESTED CHANGE FOR COMMENT 5: Add a new token to the registry (e.g., "Hosted") which combined with "MLTS" would cover the case.

==============
Section 3.2.3. Service Mobility Environment

COMMENT 6: The description states that a registry reflects the initial entries however I haven't found a corresponding registry in section 9. Has the registry been created by another RFC? If so, a reference to that RFC should be provided. Otherwise, there should be an entry for this registry in section 9.

SUGGESTED CHANGE FOR COMMENT 6: Either add the reference to the RFC that created the registry or add a section to section 9 if the registry is created by this document.

==============
Section 3.3.1. Device Classification, Figure 5

COMMENT 7: The list currently contains both physical and application type "devices". However, I don't see a token to capture softclients as part of the list. I believe it should be added. Device Classification can be reported by the device/application itself or a service provider. For some type of service providers, being a softclient might be the only thing they know about the device as they may not have visibility to the type of hardware the softclient is riding on. If the device does not participate in providing additional data then no useful information would be provided to the PSAP in that case. I note that the token "SoftPhn" was introduced in -12 but dropped somehow in -21. My preference would be "SoftClnt" as it implies more than just voice.

SUGGESTED CHANGE FOR COMMENT 7: Add "SoftClnt" to the Device Classification registry.

==============
Section 3.4.  Owner/Subscriber Information

COMMENT 8: This block can describe subscriber information (when provided by a service provider) however it seems not possible to indicate the context under which the information was originally captured. For example, the information provided by the service provider may be derived from a billing system (e.g., billing address), a subscriber profile system (e.g., registered user information), from a user-inputting system (e.g., alternate/emergency contacts) or a mix thereof. The nature of the information can provide useful hints on how to treat the information which might change the way it will be processed by the call taker.

SUGGESTED CHANGE FOR COMMENT 8: A few options are available depending on the level of granularity we want to achieve. One option would be to add a new element in the ProviderInfo allowing the characterization of all the info being provided by the service provider. The downside of this is that it does not support the characterization of multiple sources. Another option would be to add a new element to xCard with an associated text enumeration to be used in the xCard for Subscriber data. This option would allow segmentation by source but would require that a distinct xCard be provided for each source. A third option would be to add a new parameter to the xCard that would allow to characterize each field within the same xCard structure. There might be others but that's what comes to mind right now.

==============
Section 5.  Examples, Figure 11

COMMENT 9: As currently drawn, the diagram seems to suggest that the originating UA is owned and operated by the access network provider.

SUGGESTED CHANGE FOR COMMENT 9: Move the human and the UA to the left, outside the ASP box, and keep the signalling line flow through the ASP box to show that the ASP is not participating in the call setup.

==============
Section 6.2.  EmergencyCallData.ServiceInfo XML Schema

COMMENT 10: The XML optional element "Link" is defined in the schema but there is no describing text in section 3.2 nor is the element present in the example of section 3.2.4.

SUGGESTED CHANGE FOR COMMENT 10: Either remove the element from the schema or add descriptive text to section 3.2 and update the affected examples in the document.

==============
END OF COMMENTS