Re: [Ecrit] Review of draft-ietf-ecrit-additional-data-01

[Hannes Tschofenig <[e-mail]>]

Hi James, 

thank you for your response. 

On Sep 1, 2011, at 2:43 AM, Winterbottom, James wrote:

> Hi Hannes,
> 
> Thanks for the response. Please see comments inline.
> 
> Cheers
> James
> 
> James Winterbottom
> Global Product Manager
> CommScope GeoLENs
> IP Location Product Portfolio
> Email: [e-mail]
> Phone: [phone]
> Mobile: [phone]
> 
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:[e-mail]]
>> Sent: Tuesday, 30 August 2011 3:55 AM
>> To: Winterbottom, James
>> Cc: Hannes Tschofenig; [e-mail]
>> Subject: Re: [Ecrit] Review of draft-ietf-ecrit-additional-data-01
>> 
>> Hey James,
>> 
>> thank you for your timely review.
>> 
>> On Aug 16, 2011, at 9:15 AM, Winterbottom, James wrote:
>> 
>>> Hi All,
>>> 
>>> I have been reading this document closely with an eye to implementing
>> it, and have the following substantial comments:
>>> 
>>> 1) Much of the document describes specific XML elements, but without
>> having an up to date schema this becomes very hard follow. I see the
>> schema as being a critical update required by this document. If you need
>> or want help in producing the schema please let me know and I will try to
>> help.
>> 
>> While I fully agree that we need to get this document finished I am not
>> sure we really need an XML schema at all. Over the time I have gotten the
>> impression that an XML schema is really a waste of time. It creates the
>> illusion that there is something that provides help (to implementers and
>> to those who read the specification) but in reality it doesn't.
> 
> [AJW] I don't agree with this. I think that this means that we need to compile ALL examples and make sure that they are valid against the provided schema. I also think that developers that are hardcoding this stuff are in for a likely world of hurt when it comes to interoperability with vendors that do implement against the schema. For me the schema is the place that I go to see if things are correctly formatted or not. In most cases, we use XML parsers that require schema in order to work optimally. Not providing a schema means that there is no definitive place to look when interoperability issues arise.


If there is no schema then you need to validate the examples against the schema either. 

In our case the XML schema will not tell a lot anyway given that we have structures in there that aren't even XML encoded (such as the VCard, as it is currently specified). 

Furthermore, the extensibility mechanism of XML would prevent you from getting any meaningful validation anyway. 


I would be more in favor of us providing some tools (as reference implementation) that 
a) produce a correct XML based on some given input, and
b) verify a provided XML document for correctness. 

This would allow us to verify correctness for all parts of the specification, including those parts that cannot be covered by the XML schema itself. 

I am convinced that this provides much, much more value!

> 
>> 
>> Working on different specification I later thought that the problem is
>> with the readability and extensibility of the XML schema and then (as you
>> may recall) we switched to Relax NG. That turned to be a mistake as well.
>> When it comes to extensibility a Relax NG schema is equally bad.
> 
> [AJW] I don't know that I agree with this either. My main issue with specifying schemas in RelaxNG is that there are simply not enough tools and parser libraries available to just take the schema and use it. In cases where only a RelaxNG schema is provided we have had to go and write the equivalent schema in xsd first. For this reason alone I think agreeing on a single standard is best, and I would prefer that this was xsd.
> 
> I certainly don't agree that the schema definition language is the problem when it comes to specifying extension points, this is simply a matter of good design and deciding how a schema ought to be extended ahead of time and perhaps documenting the rationale for this decision.
> 
> 

I don't believe that a real developer actually uses the XML schema. Of course they will be using XML parsers but that's an independent of the actual schema description. 

>> 
>> So, I believe we are doing fine without XML schema but with lots of
>> examples. Implementers just look at examples. Nobody generates codes
>> directly from an XML schema.
>> 
>> This may sound a bit revolutionary but what do you think? What this work
>> for us?
> 
> [AJW] I don't agree and I would like to see a formal set of schemas. I would like to a base schema with the common object definitions, and then a schema for each of the 3 provider types, owner, access and voice.
> 
> 
>> 
>>> 
>>> 2) Section 3.1.2 in the Note says that this field must be the NENA
>> company ID in the US. I think that this text needs to be revised to say
>> something along the lines of "for example in the US this could be the NENA
>> company ID", since this document hasn't been finalized it is not
>> appropriate for the IETF to dictate what NENA must do.
>> 
>> Certainly correct. A mistake when we copied the text from the original
>> NENA spec.
>> 
>>> 
>>> 3) I have argued against the inclusion of vCard into this data structure
>> countless times in multiple forums, and I know that Brian and I are
>> unlikely to agree on its applicability here. Having said that, if we are
>> going to include vCard, then the need for the separate elements in
>> sections 3.1.3 and 3.1.4 is not apparent to me when they can be captured
>> in 3.1.5 and hence keep all of the operator data together.
>> 
>> Given that we have made the mistake already to blindly copy the CAP
>> structure for the data only emergency calls I think we need to double-
>> check very carefully what we need from the vCard structure.
>> 
>> Additionally, we have to consider that the additional data is an XML
>> structure at the moment and the vCard encoding is not XML-based, if I
>> understood that correctly. I don't believe we want to mash different
>> encodings together in a single structure, right?
>> Only if we use http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml-1
>> we get the XML encoding of a vCard and I am not sure about the
>> availability of existing libraries. So, it seems that one really starts
>> from zero (implementation-wise).
> 
> [AJW] My suggestion would be that you simply import the vcardxml schema (yes, it is RelaxNG and that is unfortunate), but the defined XML object coming out the other end should then at least be correct. 
> 
Do you know the status of that work? The referenced document is a draft and I am not sure about the expected completion date (if it will be completed at all). 

Mixing a Relax NG schema and an XML schema isn't that easy....
 
>> 
>> Currently, we use the vCard in two places:
>> - 3.1.5.  vCARD of Data Provider
>> - 3.5.1.  vCARD for Subscriber's Data
>> 
>> 
>>> 
>>> 4) The description in 3.1.3 says "If a telephone number is the contact
>> address it should be provided in the form of
>> sip:telephonenumber@serviceprovider:user=phone". It seems to me that this
>> would more sensibly be provided as a teluri.
>> Sounds OK for me.
>> 
> [AJW] Okay
> 
>>> 
>>> 5) Operators may provide more than one means for providing 24x7 support.
>> Is this allowed here, because it isn't described in section 3.1.3?
>> I believe we have to support more than one means to contact a data
>> provider.
>> 
> [AJW] Okay
> 
> 
>>> 
>>> 6) I think that a lot more rigor needs to go into the description and
>> definitions for <SvcDelByProvider>. It seems to conflate the issues of the
>> type of access medium and the notional service-type being provided. It
>> would be much cleaner to have two separate fields as this will make the
>> intent clearer. For example the first registry item listed and the last
>> registry item listed may be mutually inclusive, for this field to have any
>> real value then it needs to be unambiguous. Instead this could be broken
>> up into <AccessType> (WiMAX, LTE, CDMA-2000, GERAN, UTRAN, POTS, ADSL,
>> Cable ..) and <Service> (VoIP, One way outbound, Pay Phone, MLTS ...)
>>> 
>> I agree with you
>> 
>>> 7) <DeviceClassification> suffers from the same problem that
>> <SvcDelByProvider> does in that the fields are not mutually exclusive, and
>> so this will cause confusion. For example, what is the difference between
>> "Tablet computing device", and "Internet Tablet", or "mobile handset" and
>> "Smart phone"?  My recommendation here would be to reduce the number of
>> things in this list substantially so that the general "type" of thing is
>> known (you can provided examples as to what falls in what category). If
>> more information is required in some circumstances then have a
>> "description" field in the data type that allows for anything extra to be
>> provided.
>> 
>> Also agree. I don't have an good suggestion for a categorization either
>> nor do I fully understand what call takers could use that data for. I will
>> ask within NENA & EENA.
>> 
> [AJW] Okay this looks like it is an area for further research and investigation then.

This is my view; others may have different opinion. 

In my discussions I encountered the following problems. If I ask call takers then they claim that they do not know these new technologies and have not being using any of them so they cannot provide any feedback whether information about the different classes would make sense for them. If we ask those working with the technology I receive the answer that they do not know what the call takers would want to see.


> 
> 
>>> 
>>> 8) 3.5 the use of the term subscriber is problematic and has particular
>> service model connotations that may not be applicable. I would like to see
>> this changed to owner, and for "addCallSub" to be changed to
>> "addOwnerData" or "addCallerData" or something like that.
>> 
>> The term "subscriber" fits the text. The term "owner" is a bit funny in
>> the context of a VoIP services without an actual hardware device.
>> 
> [AJW] My concern with the use of the word "subscriber" is its connotations with voice subscription services, and a voice subscription service is not required in this calling environment, it is only one option. I guess if we include subscription to include Internet access subscription then it is okay, but I would prefer a different term if possible.

I believe we could clarify this specific aspect. 

> 
> 
>>> 
>>> I have one nit, and that is to do with the version in the document still
>> being shown as -00 when it should be -01.
>> Another bug.
>> 
>> A question that I had raised recently was whether we should use XML as an
>> encoding or rather switch to JSON. Of course with all the other XML stuff
>> we already have the benefits may not entirely be there but I still want to
>> raise that issue.
>> I wonder whether you have an opinion about this.
> 
> [AJW] I don't really have an opinion either way, if JSON lets us define schemas with adequate constraint mechanisms then I am okay with it. What I would like to see some a consistent approach across future IETF documents though, with one schema definition being the preferred one, and use of an alternative requiring demonstration that the preferred mechanism doesn't fit.
> 
Well. We will not be able to define that "policy" in the ECRIT working group.

Ciao
Hannes

> 
>> 
>> Ciao
>> Hannes
>> 
>>> 
>>> Cheers
>>> James
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Ecrit mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ecrit
>