[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: CAP 1.1 Standard and ITU-T Recommendation - TC Task 3 (ASN.1)
Thanks Eliot! I will also post this to the list. I have renamed the subject and this will begin the ASN.1 task 3 thread. Please reply to this thread with any comments. Elysa At 10:39 AM 4/26/2007, Eliot Christian wrote: >Hi Elysa > >In the given ASN.1, the values in the enumerated lists are all listed >with initial characters in lower case. The XML version has used upper >case as the initial character. I doubt that ASN.1 really cares about >the capitalization of string values, so I'd suggest these be changed >to match the XML string values. (Note that the ASN.1 usage results in >this peculiar-looking value: "cBRNE"). > >I'm feeling that the comments in the "area" element are not quite >as clear as they need to be. In section 1.5 of the standard, there >is a note about the representation of each point with coordinates >given as a comma separated pair of signed decimal degrees in the >order of latitude followed by longitude. Perhaps this definition >of a geographic point as represented by a "lat,lon" coordinate pair >could be copied into the ASN.1. Then, the ASN.1 could describe a >"circle-list" as: "A space-separated list of circles with each circle >defined by the geographic point at its center point, a comma, and the >circle radius; the radius unit being given in kilometers". (As it >stands now, it is not very clear where the spaces and commas belong.) > >The description of "altitude" also should note that its unit of measure >is "feet above mean sea level". > >I would also mention one other comment about "area", particular to >the polygon. We ought to have stated that the "winding order" of points >around the polygon is counter-clockwise. This is difficult for software >to infer, and the inference procedure would be just plain wrong for any >area that extends more than halfway around the Earth, e.g, the Pacific. > >Eliot > > >At 10:12 AM 4/26/2007, you wrote: > >Dear TC Members, > > > >As we were busy with our face to face meeting last week the ITU > folks were busy working on integrating our CAP 1.1 Standard into > their format and process. They produced two recommendations that > are attached for your review. > > > >The first is to be an exact representation of our existing CAP 1.1 > Standard in the ITU Recommendation format. They were required by > their guidelines and process to make changes to some of the > normative references we used. Other than that it is supposed to be > a match. The second attachment is a recommendation for the > addition of ASN.1 encoding. > > > >The ITU team has requested that we respond by May 1 on these > recommendations. I have been working with OASIS Staff to consider > how to move forward as expeditiously as possible. Different > members of the staff are working to ensure we follow the proper > IPR, process, etc. For example, ASN.1 needs to be "contributed" to > OASIS for this purpose. > > > >If we agree as a TC that this is indeed a complete and correct > description of our Standard and we agree to accept the ASN.1 > encoding that it is technically equivalent to our Standard, and > therefore non-substantive, we could process this document through > the OASIS process as an errata. This appears to be the most > efficient way to proceed given the OASIS process. > > > >The changes to the normative references need to be studied in some > detail. It has also been noted that in ITU recommendation that in > the DOM, Response Type is not specified correctly. It is, however, > correct in their Data Dictionary. They did not have the benefit of > the correction to "assess". As you recall, we listed "assess" in > our data dictionary but it was not listed in the schema and we have > already prepared errata document for that (thanks to Patti and > Rex). This errata has been voted on by the TC but not yet > submitted for 15-day public comment. > > > >Since there is already one noted discrepancy in the ITU > recommendation (between their DOM and data dictionary), I am > hopeful that they will make this minor correction as well as the > one for "assess" and we can move forward without them having to go > through another recommendation cycle. I think we are all in > agreement that it would be best if these Standards can track > directly and do not splinter. > > > >With there only being less than a week for us to meet their > requested response time, I am hopeful that all of you will take a > good hard look at these changes and post any questions/comments to > the list. If we break this task up into pieces, it may help. The > more eyes the better. > > > >Tasks: > >1. Read/compare documents word for word and list any discrepancies > >2. Study the normative references to be sure they are correct > >3. Validate the ASN.1 notation is a correct representation and > technically equivalent to the XML schema > > > >Jamie Clark and I are doing #1, others please join in. Could a > couple of you agree to comb through the references and compare? Is > there one or more of our members who are (or have access to someone > that is) ASN.1 knowledgeable that can verify the ASN schema, > please identify yourself and work this part. > > > >Please respond to this note with your willingness to take on a > task, then we can start a discussion list on each task. Also with > your response, let me know 2 or 3 times when you would be available > for a telecon to discuss over the next few days. I suggest we > schedule one for either Thurs or Fri evening when Renato and Karen > might be available and possibly one for Sunday or Monday > evening. We have a normally scheduled TC meeting on Tues, May 1 > where we can do any final voting that may be necessary. Other > suggestions welcomed. > > > >In the interest of public safety worldwide, let's take this time > to get this work complete! However, let's make sure it is > correct. Thanks to all of you and your hard work and contributions. > > > >Warm regards, > >Elysa Jones, Chair > >OASIS EM-TC > >Program Manager > >Warning Systems, Inc. > >256-880-8702 x102 > >256-694-8702 (cell) > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]