[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FW: SLoP Requirements I-D, Draft 3



Amen!

At 10:13 AM 7/11/2000 -0700, Rohan Mahy wrote:
>Hi,
>
>I'd like to make clear the distinction between the *protocol* requirements
>and the *implementation* requirements.  It is the intent of the design
>team, that the *protocol* MUST support handling multiple formats.  In other
>words, any proposed protocol, must be able to carry new formats.  It is
>also the intent of the design team, that any proposal for the SLoP protocol
>REQUIRE all implementations to support a fairly simple format with at least
>lat,long,alt, time, and accuracy.  Those same proposals will almost
>undoubtedly say that implmentations MAY use other IANA registered formats.
>
>Hope this clears things up.
>
>thanks,
>-rohan
>
>
>
>
>At 04:16 AM 7/11/00 , haitao.tang@nokia.com wrote:
>>Hi Brian and Rohan,
>>
>>On Patrik's comment, I guess we mean one "MUST" (default) and some "MAY"s
>>(options) in the req I-D, concerning location data format. Maybe, he
>>misunderstood it. So, Brian may clarify this to the list.
>>
>>Concerning time, maybe, he was talking about Rohan's simple text format I-D.
>>"this protocol express at what lat and long mr Columbus were in 1492 at a
>>specific date" is a good point, isn't it? Can Rohan comment to the list?
>>
>>BR, Haitao
>>
>> > -----Original Message-----
>> > From: EXT Patrik Fältström [mailto:paf@cisco.com]
>> > Sent: 11 July, 2000 9:45
>> > To: john.loughney@nokia.com; Brian.Rosen@marconi.com;
>> > ext-ip-location@research.nokia.com
>> > Subject: RE: SLoP Requirements I-D, Draft 3
>> >
>> >
>> > At 08.32 +0300 00-07-11, john.loughney@nokia.com wrote:
>> > >comment 4
>> > >=========
>> > >
>> > >    The protocol:
>> > >
>> > >    a. MUST support multiple formats.  Each format must be registered
>> > >       with IANA.
>> > >
>> > >=> I think it MUST support the default format, and MAY support other
>> > >    formats.
>> >
>> > I am still very confused about this wish which people have about
>> > having "multiple formats in the protocol".
>> >
>> > Are we not mixing up user interface issues with what is in
>> > the protocol?
>> >
>> > I suggested a bit earlier that the time specification in the protocol
>> > should be a real number which is:
>> >
>> > >      A time is expressed as a Julian date, a Floating point number
>> > >      of arbitrary accuracy denoting the number of days
>> > before (negative),
>> > >      or after (positive) the 14th of September 1752.
>> >
>> > The reason I define time this way and not as UTC, GMT or such, is
>> > that for example UTC is not defined before around 1970.
>> >
>> > I.e. if you use UTC, GMT or such definitions, it might become
>> > troublesome to express non-present times. For example, it could be
>> > difficult to in this protocol express at what lat and long mr
>> > Columbus were in 1492 at a specific date.
>> >
>> >     Patrik
>> >
>

*************************************
"At the end of the day... the most committed win!"

James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f)  972.813.5280
www.cisco.com