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

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 16 Aug 2011 14:15:38 +0800

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.

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.

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.

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.

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?

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

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.

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.

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.

Cheers

James

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 29 Aug 2011 20:54:44 +0300

Hey James, 

thank you for your timely review. 

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

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…

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 1 Sep 2011 07:43:01 +0800

Hi Hannes,

Thanks for the response. Please see comments inline.

Cheers
James

James Winterbottom
Global Product Manager
CommScope GeoLENs
IP Location Product Portfolio
Email: [email-masked]
Phone: +61-2-42-212938
Mobile: +61-447-773-560
 
> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Tuesday, 30 August 2011 3:55 AM
> To: Winterbottom, James
> Cc: Hannes Tschofenig; [email-masked]
> Subject: Re: [Ecrit] Review of draft-ietf-ecrit-additional-data-01
> 
> Hey James,
> 
> > 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.

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

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

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

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

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

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