Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.21] [Mipshop] Re: Architectural Considerations for Handover InformationServices (was: Re: CARD Discussion Query Discussion)



Here are my thoughts...

"Extensibility, flexibility" are nice features, but they should be put into
their proper perspective. XML is certainly convenient for content editing by
human users. But what does extensibility and flexibility mean  for 802.21?
What processes and procedures are involved when certain deployment would
like to adopt and/or modify new contents in the 802.21 (e.g. IS) exchanges?
Are such processes and procedures to benefit from XML? How?

TLV has been a well-established norm for payload encoding for signalling
protocols. One could feel unsatisfied with TLV and propose enhancements.
This is welcome. But I think it is fair to expect any new proposals to prove
concretely the advantages of XML over the conventional TLV in the context of
signalling protocols in 802.21.

I don't believe that there is an essential lack of understanding of XML and
TLV. They are created and used for their targeted purposes. Is there a "one
size fits all"? I don't think so. Personally, it is obvious to me that XML
is not appropriate for signalling protocol with respect to payload size
(over the air), extra processing cycles in encoding and decoding (irrelevant
whether XML is supported in the handset), extra delay to the reactiveness of
signalling protocol (which could be important if 802.21 is to facilitate
handover process), etc. I could be wrong, and I would appreciate anyone
explaining to me otherwise, and how XML could make things better than TLV in
this specific context of 802.21.

Cheers,
Hong-Yon

> From: Yoshihiro Ohba <yohba@TARI.TOSHIBA.COM>
> Reply-To: Yoshihiro Ohba <yohba@TARI.TOSHIBA.COM>
> Date: Fri, 14 Oct 2005 19:08:21 -0400
> To: <STDS-802-21@listserv.ieee.org>
> Subject: Re: [802.21] [Mipshop] Re: Architectural Considerations for Handover
> InformationServices (was: Re: CARD Discussion Query Discussion)
> 
> Several comments:
> 
> - Informaiton encoding is one design factor, but we should think more
> about other factors such as extensibility, flexibility, and actual
> volume of encoded contents (regardless of how it is encoded).
> 
> - In reality, 3GPP2 has XML-based method (e.g., XCAP) in its
> dependency list.
> 
> Yoshihiro Ohba
> 
> 
> 
> On Fri, Oct 14, 2005 at 06:19:26PM -0400, Singh Ajoy-ASINGH1 wrote:
>>      But it does not seem to be true given the current discussion.
>> 
>>  
>> 
>> Ajoy-> In IETF folks are trying to help 802.21 to get the work done
>> better. 
>> 
>> I do not believe there is anything wrong if some folks do not agree with
>> XML query. Honestly I do not believe XML query is  good for low power
>> 
>> mobile devices. Based upon our current experience folks are finding hard
>> to cope up with SIP and SIP compression itself. It looks good on paper,
>> 
>> but somehow when you implement compression you may find that delay
>> introduced by compression out performs the bandwidth saving gained from
>> 
>> compression. I do not believe that adding one more level of compression
>> for XML will be better idea.
>> 
>> As a research topic it may look very attractive, but we have to look at
>> today's reality. I would like to state that in one of my discussions
>> 
>> I suggested that even TLV encoding can be modified to carry XML script
>> to address some use cases where XML may be a good choice.
>> 
>> I am afraid we are trying to push XML without considering reality at
>> hand. 
>> 
>>  
>> 
>> Also, what is wrong about sharing view of 802.21 when MIPSHOP is going
>> to define a protocol that would cater need of
>> 
>> 802.21 itself?  
>> 
>>  
>> 
>> Nothing wrong in sharing the view.  But do we need to  mention the straw
>> poll result to establish our  technical reasoning?
>> 
>>  
>> 
>> Ajoy-> Perhaps you did not like the word straw poll.  I will make note
>> of that.  I think enough reasoning was given to justify that
>> 
>> XML query complex query may not be good for low power mobile devices.
>> 
>>  
>> 
>>  
>> 
>>