Subject: [AVT] Splitting of RFC 2833bis

From: Tom Taylor <[email-masked]>
Date: Wed, 10 Nov 2004 14:19:53 -0500

At the AVT meeting today, it was agreed that it would be a good idea to split the 
current draft-ietf-avt-rfc2833bis-05.txt.  The idea would be to remove and put 
into a separate draft the codepoints for the less-implemented event types.  This 
proposal was inspired partly by the magnitude of the changes to the trunk 
signalling related events, which raised the suspicion these events have never been 
implemented.

It was generally agreed that the DTMF codepoints should stay with the core 
specification.  Are there any other candidates for this honour, or should all the 
rest go to the new document(s)?

Going further: should there be one new document, or one per class of events (i.e., 
lines, data and FAX, trunks)?

-- 
Tom Taylor
Carrier VoIP Standards Development
Nortel Networks
Phone +1 613 763 1496  (ESN 393-1496)
E-mail: [email-masked]

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

---

From: "Kevin A. Noll" <[email-masked]>
Date: Wed, 10 Nov 2004 15:58:57 -0500

Not sure if this is proper, but would it make sense to have the codepoints
be 
handled as registered numbers with the structures of IANA? 

Either way, I don't see much sense in having separate documents for
different 
classes. It just seems like too much extra work unless there's some
precedent
for it.

--kan--
--
Kevin A. Noll, KD4WOZ
CCIE, CCDP
Perfect Order, Inc.		
[email-masked]
717-796-1936

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom
Taylor
Sent: Wednesday, November 10, 2004 2:20 PM
To: [email-masked]
Subject: [AVT] Splitting of RFC 2833bis

At the AVT meeting today, it was agreed that it would be a good idea to
split the 
current draft-ietf-avt-rfc2833bis-05.txt.  The idea would be to remove and
put 
into a separate draft the codepoints for the less-implemented event types.
This 
proposal was inspired partly by the magnitude of the changes to the trunk 
signalling related events, which raised the suspicion these events have
never been 
implemented.

It was generally agreed that the DTMF codepoints should stay with the core 
specification.  Are there any other candidates for this honour, or should
all the 
rest go to the new document(s)?

Going further: should there be one new document, or one per class of events
(i.e., 
lines, data and FAX, trunks)?

---

From: Tom Taylor <[email-masked]>
Date: Wed, 10 Nov 2004 16:39:16 -0500

We do intend to set up an IANA registry.  Taking your advice, the initial
population of that registry would include the DTMF events and probably some data
events to which current ITU-T documents refer.  The other events would be added
when the second document is approved.

I suspect what you have in mind is a registry anyone can add to.  This probably
won't work because the code space is so small: just 256 events, thanks to the
payload format.  If we find we need more down the road (hope not!), I suppose we
could define an extension to that format.  We could use the "R" bit to double the
code space, for instance.

Barring that, the criterion for adding codepoints should probably be a published
standards-track RFC.