Subject: Re: [AVT] 3 to last-call - RTP header extensions

From: lazzaro <[email-masked]>
Date: Tue, 7 Nov 2006 20:37:23 -0800

Hi David,

	One possible issue with draft-ietf-avt-rtp-hdrext-06.txt ...

>  For extensions defined in RFCs, the URI used MUST be a reference to
> the RFC, and, for clarity, this URI form SHOULD appear within the RFC
> defining the extension.  An example (this is only an example) might  
> be:
>
>    http://www.ietf.org/rfc/rfc1234.txt

	If one wishes to write an RFC that defines 2 extensions,
this breaks ... one could imagine defining a set of header
extensions, and wanting to define the entire set in one RFC.

	Not sure if this is worth a re-design at this late date, but
at least you should note the problem in the I-D along with the
obvious solution (write a new RFC for each header extension).

	Aside from hdrext looks good to me ...

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---

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

---

From: Dave Singer <[email-masked]>
Date: Wed, 8 Nov 2006 09:38:55 +0200

At 20:37  -0800 7/11/06, lazzaro wrote:
>>defining the extension.  An example (this is only an example) might be:
>>

Yes.  I had hoped to allow a fragment identifier, but matters 
conspire:  RFCs are plain text, and there is no defined fragment 
identifier scheme for plain text documents.  It may be that we should 
relax this to a 'should'.

It may be that we want to relax this;  I expect 'tinkering' with this 
may be a subject of the last call.

Thanks for the comments.
-- 
David Singer
Apple Computer/QuickTime

---

From: "Pete Cordell" <[email-masked]>
Date: Wed, 8 Nov 2006 09:46:38 -0000

Just scanned through this...

Since to be of any use the RFC will need to be interpreted by a human, then 
I can't see that having a fragment identifier that doesn't have an real 
anchor is a problem.  In the RFC surely you could just say, "This extension 
is represented by the URI http://www.ietf.org/rfc/rfc3550.txt#h1".

On a separate note, I found the last bit of the following slightly odd:

   Padding bytes have the value of 0 (zero).  They may be placed between
   extension elements, if desired for alignment, or after the last
   extension element, as needed to pad to full 32-bit words.  Note that
   in this special case the length of the following data is not 1 byte,
   but 0 bytes.

Here's my attempt at improving it!

   Padding bytes have the value of 0 (zero).  They may be placed between
   extension elements, if desired for alignment, or after the last
   extension element, as needed to pad to full 32-bit words.  A padding
   byte is not interpreted as an ID/length pair.  When a padding
   byte is found it is ignored and the parser moves on to interpreting the
   next byte.

HTH,

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
for XML to C++ data binding visit
http://www.tech-know-ware.com/lmx
(or http://www.xml2cpp.com)
=============================================

----- Original Message ----- 
From: "Dave Singer" <[email-masked]>
To: "lazzaro" <[email-masked]>; <[email-masked]>
Cc: "lazzaro" <[email-masked]>
Sent: Wednesday, November 08, 2006 7:38 AM
Subject: Re: [AVT] 3 to last-call - RTP header extensions

> Yes.  I had hoped to allow a fragment identifier, but matters conspire: 
> RFCs are plain text, and there is no defined fragment identifier scheme 
> for plain text documents.  It may be that we should relax this to a 
> 'should'.
>
> It may be that we want to relax this;  I expect 'tinkering' with this may 
> be a subject of the last call.
>
> Thanks for the comments.
> -- 
> David Singer
> Apple Computer/QuickTime
>

---

From: "Jonathan Lennox" <[email-masked]>
Date: Wed, 8 Nov 2006 07:26:10 -0800

lazzaro wrote:
> 	If one wishes to write an RFC that defines 2 extensions, this breaks
> ... one could imagine defining a set of header extensions, and
> wanting to define the entire set in one RFC.  

The usual practice for RFC-defined URIs used as protocol identifiers
(e.g. XML DTDs and namespaces) is to use URNs in the urn:ietf:params:
namespace.  See RFC 3553 and <http://www.iana.org/assignments/params>.

-- 
Jonathan Lennox -- Layered Media
[email-masked]

---

From: Dave Singer <[email-masked]>
Date: Wed, 8 Nov 2006 18:24:14 +0200

>namespace.  See RFC 3553 and <http://www.iana.org/assignments/params>.

ah.  so we could register 'RFC' as a param itself? so we could end up 
with the form

urn:ietf:params:rfc:1234:nice_extension

where 1234 is the RFC number defining the extension, and 
nice_extension is the name of one of the extensions in that RFC?

Much cleaner, I agree.  It solves both the question of whether URLs 
to RFCs are ensured to be stable, and also provides a place for the 
extension name.

Or is there already a node for RFCs that is parallel to 'params'?

-- 
David Singer
Apple Computer/QuickTime