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