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

["Winterbottom, James" <[e-mail]>]

Hi Hannes,

I don't I agree with your general sentiments below.
Defining a schema forces you to think about how to structure your data, unstructured data has problems with it, not the least of which is the mass state of confusion it causes. I can speak from experience that this a major problem with the existing additional data document as defined in NENA, and why there are quite a number of very strong objectors to the whole idea of providing additional data.

The more I read the additional-data draft the more I think it is taking the wrong direction. I am reaching the opinion that it should not define the data structures at all, but only provide the mechanisms to acquire and flag the "type" of information being passed. This allows the jurisdictional entities to define the actual data structures required, or the equipment vendors in the case of device information. My rationale for this approach is that I don't think a schema definition is possible because there is no clear model being put forward.

So the proposal would be:
1) Do not define specific MIME types for the data blobs being transferred, instead leave this aspect out of scope.
2) Instead of introducing one new Call-Info header parameter, introduce three, one for each of the data sets of user, voice-provider, access-provider. If You need more providers introduce more parameters.
3) Allow each URI to be either a CID or an HTTPS URI.

Operating in this fashion avoids the problem, and means that the text can be descriptive rather than normative when it comes to examples. This then allows NENA to go away and define the information that it wants from US providers.

My view is still that if you want to provide XML examples then you need a schema.

Cheers
James  



> -----Original Message-----
> From: Hannes Tschofenig [mailto:[e-mail]]
> Sent: Thursday, 8 September 2011 10:37 PM
> To: Winterbottom, James
> Cc: Hannes Tschofenig; [e-mail]
> Subject: Re: [Ecrit] Review of draft-ietf-ecrit-additional-data-01
> 
> 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
> >