RE: Comments on ULE extension header....

["William StanisLaus" <williams@calsoft.co.in>]

Well, I agree for Mandatory headers, it MUST not be implemented across
the version. But Version number tracks the supported Mandatory headers
for that release/version. Hence we can always quote the implementation
with the version number.
For any commercial Marketing, Feature sheet says about the MPE, and jst
version number will imply any supported Mandatory header. Otherwise it
should list all the Mandatory headers in the Feature Sheet.

-William.

> -----Original Message-----
> From: owner-ipdvb@erg.abdn.ac.uk 
> [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Gorry Fairhurst
> Sent: Tuesday, June 08, 2004 8:06 PM
> To: ipdvb@erg.abdn.ac.uk
> Cc: 'Bernhard Collini-Nocker'
> Subject: Re: Comments on ULE extension header....
> 
> 
> More on version identification...
> 
> On 8/6/04 12:59 pm, "William StanisLaus" 
> <williams@calsoft.co.in> wrote:
> 
> > Please see the comments inlined...
> > 
> > -William.
> > 
> >> -----Original Message-----
> >> From: owner-ipdvb@erg.abdn.ac.uk
> >> [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Gorry Fairhurst
> >> Sent: Tuesday, June 08, 2004 3:20 PM
> >> To: ipdvb@erg.abdn.ac.uk
> >> Cc: Bernhard Collini-Nocker
> >> Subject: Re: Comments on ULE extension header....
> >> 
> >> 
> >> On 7/6/04 7:30 pm, "williams@calsoft.co.in"
> >> <williams@calsoft.co.in> wrote:
> >> 
> >>> Thanks to Gorry for publishing the draft :)
> >> 
> >> This was a work of many discussions among many people...
> >> 
> >> 
> >>> Few Comments
> >>> Editorial :
> >>> ---------
> >>> In Section 2, Figure 1,2 and 3 D_bit is maked as ZERO. It
> >> should be ONE
> >>> Figure 3, T2 and H2 are interchanged.
> >>> 
> >>> Concept:
> >>> ---------
> >>> When we are talking about backward compatibility, it is
> >> better to have
> >>> version number in the ULE, so across the version it is
> >> identified uniquely.
> >> 
> >> Yes - and this *could* have been in the ULE base header, 
> but there are
> >> significant disadvantages too - additional capacity would consumed.
> >> 
> >> My suggestion is to use one encapsulation method per PID
> >> (MPEG-2 TS logical
> >> channel) - if we do this other signaling protocols can associate a
> >> particular PID with a particular encapsulation method.  The
> >> descriptors
> >> passed by the signaling protocol could also differentiate MPE
> >> from ULE.
> >> If we need a new format for ULE sometime in the future, we
> >> could use this
> >> method to identify this.
> >> 
> >> Are you suggestion a new OPTIONAL extension to give the
> >> version of the ULE
> >> protocol? - How do you see the additional benefits of this?
> >> 
> > 
> > 
> > William> I suggest to have it as a Mandatory header, Since different
> > version of implementation of ULE can be differenciated with 
> a version
> > number. 
> > Say for example, in ULE version 1 I have 4 Mandatory headers. And we
> > decide to add 2 more Mandatory headers and come up with a 
> new version of
> > ULE. In that case, since we have added new mandatory header 
> the older
> > implementation will jst drop the packet/SNDU. BUT if you 
> have an version
> > number, we can make it backward compatibily based on 
> version number and
> > still process the packet/SNDU by avoiding those header 
> processing and
> > dropping the packets.
> > 
>  <snip>
> 
> This is the first time we've discussed the published XULE 
> draft, but if I
> understand correctly, the MANDATORY EXTENSION is one that 
> MUST be processed
> before a PDU is forwarded. It does NOT imply it MUST be implemented.
> 
> In the future, more MANDATORY EXTENSION headers could be 
> added - if there
> was a case for this - by simply allocating entries in the 
> IANA registry
> after publishing an RFC that defines the new extension header 
> syntax.  Older
> systems simply can not process these headers and discard the 
> PDU when they
> find an unrecognised MANDATORY type (and ignore any following 
> parts of this
> SNDU).
> 
> In contrast, unrecognised OPTIONAL extensions can be ignored, 
> and don't
> require the encapsulated PDU to be discarded.
> 
> Given these features, it seems that new extensions could be 
> introduced if
> new optimisations/requirements emerge.
> 
> > 
> >> 
> >>> -William
> >>> 
> >>> 
> >>> 
> --------------------------------------------------------------------
> >>> mail2web - Check your email from the web at
> >>> http://mail2web.com/ .
> >>> 
> >> 
> >> Gorry Fairhurst
> >>> 
> >> 
> > 
> 
> Gorry Fairhurst
>