Subject: [AVT] draft-ietf-avt-hdrext-12

From: Michael A Dolan <[email-masked]>
Date: Wed, 20 Jun 2007 07:10:12 -0700

Dave, Tom and all-

I'm not sure where this work stands since Tom's recommendation in 
March, but I notice a few people have commented lately so thought I'd 
speak up....

I discovered a deployed system the other day that did the header 
extensions in a very similar (but not identical) way.  In this other 
system, the "defined by profile" field has several defined values and 
the multi-sub-field technique is present, using an ID and LEN 
fields.  But these fields are a different size (not 4 and 4 
bits).  It was basically the same design, though.

I need to get this other practice documented for use by another 
standards body.  I'd prefer to document it in IETF rather than elsewhere.

Because the design is so similar, I was thinking one approach would 
be to augment this ID?  I realize this is very late in what's been a 
long process for this ID (with my apologies to Dave).  Nevertheless, 
finding a deployed system so similar, it might be worth capturing 
them both in the same document with a clear way to discriminate them 
(which would be more difficult to explain if they were in separate documents).

I'm prepared to promptly contribute a proposed revision to this ID if 
folks are open to the idea.

Comments?

Best regards,

         Mike

-----------------------------------
Michael DOLAN
Television Broadcast Technology, Inc. (TBT)
PO Box 190, Del Mar, CA 92014 USA

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Sun, 24 Jun 2007 19:00:27 +0100

On 20 Jun 2007, at 15:10, Michael A Dolan wrote:
> March, but I notice a few people have commented lately so thought  
> I'd speak up....
>
> extensions in a very similar (but not identical) way.  In this  
> other system, the "defined by profile" field has several defined  
> values and the multi-sub-field technique is present, using an ID  
> and LEN fields.  But these fields are a different size (not 4 and 4  

Are there reasons, other than historical accident, for the  
differences in the two designs? How widely deployed is this system?

> be to augment this ID?  I realize this is very late in what's been  
> a long process for this ID (with my apologies to Dave).   
> Nevertheless, finding a deployed system so similar, it might be  
> worth capturing them both in the same document with a clear way to  
> discriminate them (which would be more difficult to explain if they  
> were in separate documents).
>
> I'm prepared to promptly contribute a proposed revision to this ID  
> if folks are open to the idea.
>
> Comments?

I'd prefer to converge on one mechanism, rather than documenting that  
two similar (but incompatible) variants exist, if possible.

-- 
Colin Perkins
http://csperkins.org/

---

From: Dave Singer <[email-masked]>
Date: Mon, 25 Jun 2007 11:17:00 +0300

At 19:00  +0100 24/06/07, Colin Perkins wrote:
>I'd prefer to converge on one mechanism, rather than documenting 
>that two similar (but incompatible) variants exist, if possible.

I guess I should say at this point that I am also aware of an 
implementation of my drafts;  though, just like Mike's report, this 
is a "hearsay" rather than a statement by the implementors themselves.

Mike, what was the intent of the company you know of?  Did they 
intend to make a public specification?

I find it surprising that they did something independently which is 
so close to what I created!
-- 
David Singer
Apple/QuickTime

---

From: Michael A Dolan <[email-masked]>
Date: Mon, 25 Jun 2007 08:32:17 -0700

Colin, Dave and all-

In review of the actual sub-extensions in use, 
they could theoretically have been implemented 
with the design in the ID. There is evidence that 
their work pre-dated hdrext-00, so it appears purely a historical accident.

FYI, I have been retained by the implementers to 
publicly document their work, and am beginning 
that process.  So, this is not research project or informational report.

I don't have any data on how widely deployed the 
system is - I could inquire. Although I 
understand the rationale for the question, I 
hesitate to enter into a debate over relative 
"deployedness".  Regardless of the measure used 
(# units, #sites, #independent implementations), 
I need to document what they did (at least in a 
compatible way).  I have therefore personally 
leapt to the state of mind of both designs being 
fait à compli, so my intent was to capture the 
two variants in one place as the next best thing 
to a single design.  FYI, it is possible to 
discriminate the two easily and unambiguously without altering Dave's design.

Would it be helpful to see the details?

Regards,

         Mike

At 01:17 AM 6/25/2007, Dave Singer wrote:
>>>I'm not sure where this work stands since 
>>>Tom's recommendation in March, but I notice a 
>>>few people have commented lately so thought I'd speak up....
>>>
>>>I discovered a deployed system the other day 
>>>that did the header extensions in a very 
>>>similar (but not identical) way.  In this 
>>>other system, the "defined by profile" field 
>>>has several defined values and the 
>>>multi-sub-field technique is present, using an 
>>>ID and LEN fields.  But these fields are a 
>>>different size (not 4 and 4 bits).  It was basically the same design, though.
>>
>>Are there reasons, other than historical 
>>accident, for the differences in the two 
>>designs? How widely deployed is this system?
>>
>>>I need to get this other practice documented 
>>>for use by another standards body.  I'd prefer 
>>>to document it in IETF rather than elsewhere.
>>>
>>>Because the design is so similar, I was 
>>>thinking one approach would be to augment this 
>>>ID?  I realize this is very late in what's 
>>>been a long process for this ID (with my apologies to Dave).
>>>Nevertheless, finding a deployed system so 
>>>similar, it might be worth capturing them both 
>>>in the same document with a clear way to 
>>>discriminate them (which would be more 
>>>difficult to explain if they were in separate documents).
>>>
>>>I'm prepared to promptly contribute a proposed 
>>>revision to this ID if folks are open to the idea.
>>>
>>>Comments?
>>
>>I'd prefer to converge on one mechanism, rather 
>>than documenting that two similar (but 
>>incompatible) variants exist, if possible.
>
>I guess I should say at this point that I am 
>also aware of an implementation of my 
>drafts;  though, just like Mike's report, this 
>Mike, what was the intent of the company you 
>know of?  Did they intend to make a public specification?
>
>I find it surprising that they did something 
>independently which is so close to what I created!
>--
>David Singer
>Apple/QuickTime