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. 

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. 

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? 

>  
> 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). 

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. 

>  
> 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. 

>  
> 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. 

>  
> 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. 

>  
> 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.

Ciao
Hannes

>  
> Cheers
> James
>  
>   
>  
>  
>  
>  
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit