Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #77 - 11 msgs

From: [email-masked]
Date: Thu, 05 Jun 2003 08:14:09 -0700

This is an automatic digest of bugs submitted and changed on the RTSP bug tracker.  To see a list of bugs, visit:

http://sf.net/projects/rtspspec

When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest"

Today's Topics:

   1. [ rtspspec-Bugs-633779 ] SET_PARAMETER responses (SourceForge.net)
   2. [ rtspspec-Bugs-634944 ] Restarting media not allowing seek (SourceForge.net)
   3. [ rtspspec-Bugs-640272 ] Default way of deriving aggregate URL (SourceForge.net)
   4. [ rtspspec-Bugs-662436 ] RTP/AVP/TCP w/o interleaved (SourceForge.net)
   5. [ rtspspec-Bugs-631148 ] Better Info on usage of Proxies (SourceForge.net)
   6. [ rtspspec-Bugs-745191 ] Appendix B - Clarification? (SourceForge.net)
   7. [ rtspspec-Bugs-745191 ] Appendix B - Clarification? (SourceForge.net)
   8. [ rtspspec-Bugs-739845 ] "a=range" is missing IANA registration and clear rules (SourceForge.net)
   9. [ rtspspec-Bugs-739845 ] "a=range" is missing IANA registration and clear rules (SourceForge.net)
  10. [ rtspspec-Bugs-536713 ] ControlURL parsing order must be changed (SourceForge.net)
  11. [ rtspspec-Bugs-507408 ] clarify use of interleaved param (SourceForge.net)

--__--__--

Message: 1
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 28 May 2003 09:28:56 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-633779 ] SET_PARAMETER responses

Bugs item #633779, was opened at 2002-11-05 04:19
Message generated for change (Comment added) made by robla
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=633779&group_id=23194

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Rob Lanphier (robla)
Summary: SET_PARAMETER responses

Initial Comment:
Clarify on the usage of SET_PARAMETER when no body is
present. A correct syntax with unknown headers will
result in a 200 response but also the understanding of
a propreitary or new header will result in 200. Clarify
that a requester should use the Require header with an
option tag to ensure that the responder of the request
really understands the propreitary or new header. 

Also write text recommending on the usage of parameters
in the body with the motivation that they are simpler
than using require and headers. But both case should be
possible to use. 

How to handle a empty parameter list in the body should
also be explained. 

----------------------------------------------------------------------

>Comment By: Rob Lanphier (robla)
Date: 2003-05-28 09:28

Message:
Logged In: YES 
user_id=3796

From 14 May 2003 telecon
(http://rtsp.org/2003/telecon/minutes14May.html):
#  Magnus: how to respond if server doesn't understand parameter
# Anders: maybe a require header to be used if necessary
# Magnus: I can agree with just a clarification
# Anders: for proprietary client request, it can expect
proprietary response
# Magnus: easier if just use body
# Anders: don't need to specify more than that
# Rob: I agree
# Magnus: spec says that SET_PARAMETER can be used for keep
alive
# Magnus: it's possible to have SET_PARAMETER without body
# RESOLUTION: Short explanation of SET_PARAMETER without
body being allowed. No other changes

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=633779&group_id=23194

--__--__--

Message: 2
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 28 May 2003 09:30:03 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-634944 ] Restarting media not allowing seek

Bugs item #634944, was opened at 2002-11-07 04:24
Message generated for change (Comment added) made by robla
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=634944&group_id=23194

Category: None
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Restarting media not allowing seek

Initial Comment:
The current proposal for what happens when a on-demand
stream reaches its end is that a explicit seek to the
begining is required to see the media from the
begining. However how this work for media that does not
allow seek needs to be clarififed. 
- I think a media dissalowing random access will still
allow the media to be seen from the begining.
- Also how the discovery of which time formats that
will be allowed needs to be clarified.

----------------------------------------------------------------------

>Comment By: Rob Lanphier (robla)
Date: 2003-05-28 09:30

Message:
Logged In: YES 
user_id=3796

From 14 May 2003 telecon
(http://rtsp.org/2003/telecon/minutes14May.html):
#  Magnus: we should close the bug, can be solved by
standard RTSP server side support
# Magnus: some of the OMA DRM work may apply
# Anders: maybe something that can be done in SDP. a=type?
# Magnus: on demand media stored, but seeking not allowed.
# Magnus: can be on the server side
# Rob: only complexity is trying to have client interface
before seek is tried
# Rob: DVDs don't accomodate this, though
# Anders: no way to "grey out" the seek buttons on DVD remote
# Joerg: it would be possible to define SDP attribute, but
we may end      up in rathole trying to characterize all of
the possible attributes (for speed, etc). 
# Magnus: I think RTSP will not have problems here. Current
spec is fine
# Rob: Agreed
# RESOLUTION: close the bug as implemented on server

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=634944&group_id=23194

--__--__--

Message: 3
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 28 May 2003 09:34:13 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-640272 ] Default way of deriving aggregate URL

Bugs item #640272, was opened at 2002-11-18 12:19
Message generated for change (Comment added) made by robla
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640272&group_id=23194

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Rob Lanphier (robla)
Summary: Default way of deriving aggregate URL

Initial Comment:
Currently there is very little said on which aggregated
control URL to use. The only given case is the
a=control attribute in SDP at session level. In cases
when one aggregates media stream that have no common
SDP declaration or dependencies in other ways the URL
can't be derived. Examples of such cases is when you
would like to aggregate a session multiplexed
retransmission stream with the original data stream,
without requiring aggregatation between all media types
part of a stream. Another example is aggregation of
streams that are lacking a common SDP description but
still can be intressting to aggregate. 

To fix this a way to derive what a valid aggregate URL
is needs to be specified. 

----------------------------------------------------------------------

>Comment By: Rob Lanphier (robla)
Date: 2003-05-28 09:34

Message:
Logged In: YES 
user_id=3796

From 14 May 2003 telecon
(http://rtsp.org/2003/telecon/minutes14May.html):
# Magnus: this is problem when aggregate control done in not
obvious way
# Magnus: what happens when you try to aggregate things that
aren't designed to be aggregated
# Joerg: I think this would require a lot of work to make
this work correctly
# Magnus: solution is to solve this with non-aggregate control
# Tom: how does client know
# Magnus: reuse session id
# Tom: what happens when you pass the session id with a
different URL
# Rob: it should be undefined
# Magnus: it should return error
# Rob: that's no more backward compatible
# Magnus: do you have proposed wording 11.4 second paragraph
# RESOLUTION: Tom to write up wording for 11.4 second paragraph

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640272&group_id=23194

--__--__--

Message: 4
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 28 May 2003 09:34:56 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-662436 ] RTP/AVP/TCP w/o interleaved

Bugs item #662436, was opened at 2003-01-04 18:01
Message generated for change (Comment added) made by robla
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=662436&group_id=23194

Category: General
Group: Fix DS - Needs clarificiation
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Rob Lanphier (robla)
Summary: RTP/AVP/TCP w/o interleaved

Initial Comment:

If a Transport line specifies RTP/AVP/TCP
and does not also use the interleaved
parameter, the transport setup details
seem undocumented (maybe I'm not looking
in the right place ...).

I'm thinking of the level of detail the
comedia I-D provides for TCP: which
side accept()s and which side connect()s,
how many connections to set up, framing, 
etc.

Are there pre-existing implementations 
that use this transport mode? I happened
to stumble onto this in writing the TCP
appendix for the MWPP "implementation
guidelines" ... which may spawn off a
generic I-D specifying how to use comedia
with RTP (framing, specifying the fmt
tokens after TCP, etc). So, one option
is to add RTP/AVP/TCP w/o interleaving
details to that I-D, if adding it to
to the RTSP I-D isn't desirable for
some reason ...

john lazzaro -- [email-masked]

----------------------------------------------------------------------

>Comment By: Rob Lanphier (robla)
Date: 2003-05-28 09:34

Message:
Logged In: YES 
user_id=3796

From 14 May 2003 telecon
(http://rtsp.org/2003/telecon/minutes14May.html):
#  Magnus: we should leave this until RTP framing is done
# Magnus: this is basically a feature request
# Magnus: this might well be a separate draft
# Rob: agreed
# Aravind: agreed
# Tom: we'll have to deal with this issue when DCCP comes along
# Anders: I saw this in use
# Tom: they might be using interleaving or not
# RESOLUTION: separate draft for non-interleaving; narrow
spec for      interleaving 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=662436&group_id=23194

--__--__--

Message: 5
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 28 May 2003 09:43:41 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-631148 ] Better Info on usage of Proxies

Bugs item #631148, was opened at 2002-10-30 09:23
Message generated for change (Comment added) made by robla
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=631148&group_id=23194

Category: None
Group: Fix for Draft Standard
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Better Info on usage of Proxies

Initial Comment:
The information on how RTSP works when there are
proxies needs to be fleshed out. Suggest that both HTTP
and SIP are studied. 

----------------------------------------------------------------------

>Comment By: Rob Lanphier (robla)
Date: 2003-05-28 09:43

Message:
Logged In: YES 
user_id=3796

From 28 April 2003 telecon
(http://rtsp.org/2003/telecon/minutes14Apr.html):
    * Magnus: Tom, you seem to know the most of the folks
here about RTSP proxies. Do you have some prose we can use?
    * Rob: we've got a whitepaper
(http://docs.real.com/docs/rtsp.pdf)
    * Magnus: I'll look through this

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=631148&group_id=23194

--__--__--

Message: 6
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 28 May 2003 14:33:40 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-745191 ] Appendix B - Clarification?

Bugs item #745191, was opened at 2003-05-28 21:33
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=745191&group_id=23194

Category: General
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve McKenna (stevemck)
Assigned to: Rob Lanphier (robla)
Summary: Appendix B - Clarification?  

Initial Comment:
We are working on serving A/V content (MPEG4 primarily) 
for unicast on-demand clients only (no live feeds, no 
groups).  This is a VOD single-viewer system.

To make our server as scaleable as possible, we want to 
pre-timestamp RTP packets (stamp once, use thousands of 
times).  When supporting PAUSE followed by random 
access repositioning, this gives us an RTP clock timeline 
that jumps at the moment of restart - backwards when 
seeking back, forwards when seeking forward.  The PLAY 
response after repositioning does properly identify the new 
RTP timestamp related to the after-seek NPT in an 'RTP-
info' field.

Multiple Players have no problem with this - one in 
particular balks and points to Appendix B as the 'law' that 
demands we discard our approach.  If we were to do 'just in 
time' stamping, our supported stream counts would drop 
some appreciable percentage, so it has real costs to do 
this.  

I can see why this makes a difference in live-feed models, 
but would be interested in thoughts as to why it is or is not 
of any critical importance in the specific case we are 
working.  Thanks

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=745191&group_id=23194

--__--__--

Message: 7
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 05 Jun 2003 02:10:04 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-745191 ] Appendix B - Clarification?

Bugs item #745191, was opened at 2003-05-28 23:33
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=745191&group_id=23194

Category: General
>Group: Fix - Discussed/Resolved
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Steve McKenna (stevemck)
Assigned to: Rob Lanphier (robla)
Summary: Appendix B - Clarification?  

Initial Comment:
We are working on serving A/V content (MPEG4 primarily) 
for unicast on-demand clients only (no live feeds, no 
groups).  This is a VOD single-viewer system.

To make our server as scaleable as possible, we want to 
pre-timestamp RTP packets (stamp once, use thousands of 
times).  When supporting PAUSE followed by random 
access repositioning, this gives us an RTP clock timeline 
that jumps at the moment of restart - backwards when 
seeking back, forwards when seeking forward.  The PLAY 
response after repositioning does properly identify the new 
RTP timestamp related to the after-seek NPT in an 'RTP-
info' field.

Multiple Players have no problem with this - one in 
particular balks and points to Appendix B as the 'law' that 
demands we discard our approach.  If we were to do 'just in 
time' stamping, our supported stream counts would drop 
some appreciable percentage, so it has real costs to do 
this.  

I can see why this makes a difference in live-feed models, 
but would be interested in thoughts as to why it is or is not 
of any critical importance in the specific case we are 
working.  Thanks

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2003-06-05 11:10

Message:
Logged In: YES 
user_id=302620

This has recently been discussed again. There are several
reasons why the RTP timestamp usage you have is not the
correct one. 

The correct RTP timestamp model is that the sent RTP
timestamp increase continous with wall clock. So if one do a
seek back to back with a playing the RTP timestamp will not
jump. If one pause for 5 seconds the RTP timestamp of the
packet when on continue the playout will be 5 seconds later.
The reason for doing this is:

- If one pause or do seek the RTP timestamp is not inline
with what RTCP report. RTCP needs continous RTP timestamp
against real time. Therefore strange synchronization
problems may occur. Also the RTT measurement in RTCP may be
effected. 

- A common model that works independently of use case gives
minimal implementation effort for all clients. 

- Using a common RTP timestamp without any random offset
between different streams may be a security risks if one
does encryption. 

- The implementation effort of maintaining a correct RTP
timestamp is very small, at least if one implements this
correctly. In my view it costs one extra 32 bit addition per
RTP packet. And at every PLAY request and media jump a
couple of extra instructions to calculate the RTP timestamp
offset for the first packet. 

If you have more questions on this issue please email to
mailing list [email-masked]. See www.ietf.org, wg page,
mmusic for instructions how to subscribe. 

This bug is resolved and another tracker item exist, see bug
507882.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=745191&group_id=23194

--__--__--

Message: 8
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 05 Jun 2003 02:31:38 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-739845 ] "a=range" is missing IANA registration and clear rules

Bugs item #739845, was opened at 2003-05-19 14:13
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=739845&group_id=23194

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Magnus Westerlund (magwes)
Summary: "a=range" is missing IANA registration and clear rules

Initial Comment:
The "a=range" SDP attribute in appendix C.1.5 of the
specification has some issues.

1. The parameter is not registered with IANA. Write
IANA registration request.

2. The parameter is not clearly defined in regards to
ABNF. Write ABNF definition for attribute don't forget
extension for new format types.

3. Is multiple range specifications allowed?

4. Write normative language on usage regarding session
and media level. 

5. Is multiple instances for the different formats allowed?

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2003-06-05 11:31

Message:
Logged In: YES 
user_id=302620

Has been discussed at telecon

1. Write IANA registration
2. Write ABNF 
3. No
4. Yes, will be included.
5. No

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=739845&group_id=23194

--__--__--

Message: 9
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 05 Jun 2003 03:45:18 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-739845 ] "a=range" is missing IANA registration and clear rules

Bugs item #739845, was opened at 2003-05-19 14:13
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=739845&group_id=23194

Category: General
>Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: "a=range" is missing IANA registration and clear rules

Initial Comment:
The "a=range" SDP attribute in appendix C.1.5 of the
specification has some issues.

1. The parameter is not registered with IANA. Write
IANA registration request.

2. The parameter is not clearly defined in regards to
ABNF. Write ABNF definition for attribute don't forget
extension for new format types.

3. Is multiple range specifications allowed?

4. Write normative language on usage regarding session
and media level. 

5. Is multiple instances for the different formats allowed?

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2003-06-05 12:45

Message:
Logged In: YES 
user_id=302620

Changes are now editied in. See IANA.tex and SDP.tex

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2003-06-05 11:31

Message:
Logged In: YES 
user_id=302620

Has been discussed at telecon

1. Write IANA registration
2. Write ABNF 
3. No
4. Yes, will be included.
5. No

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=739845&group_id=23194

--__--__--

Message: 10
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 05 Jun 2003 08:07:28 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-536713 ] ControlURL parsing order must be changed

Bugs item #536713, was opened at 2002-03-29 13:07
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=536713&group_id=23194

Category: None
Group: Fixed in CVS/Need WG Approval
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jaehwan, Kim (kjh1905m)
Assigned to: Magnus Westerlund (magwes)
Summary: ControlURL parsing order must be changed

Initial Comment:

Last winter, magwes suggested using new RTSP spec, RFC 
2616. So we need to change parsing order of Control 
URL which was defined in C.1.1 of draft-ietf-mmusic-
rfc2326bis-00.txt.

------
C.1.1 Control URL

        1.   the RTSP  Content-Base field;

        2.   the RTSP  Content-Location field;

        3.   the RTSP request URL.
------

It is reasonable to remove Content-Base. Because in 
the RFC 2616...

-------
19.6.3 Changes from RFC 2068
skip...

   Content-Base was deleted from the specification: it 
was not
   implemented widely, and there is no simple, safe 
way to introduce it
   without a robust extension mechanism. In addition, 
it is used in a
   similar, but not identical fashion in MHTML [45].

-------
(even I think Content-Base was implemented widely at 
lease in the streaming world )

The usage of Content-Base is identical with Content-
Location. For this reason,we had better use Content-
Location. 

Jaehwan, Kim([email-masked])
Serome Technology, inc.

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2003-06-05 17:07

Message:
Logged In: YES 
user_id=302620

No counter claim made for very long time. The bug is being
closed.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 19:04

Message:
Logged In: YES 
user_id=302620

Actually it seems that Content-base actually is useful for
giving session descriptions there base-URL. Therefore I
believe it should be keept. The Content-base has been moved
to the RTSP spec. 

Content-Location has a slightly different meaning whit some
implications. 

Therefore there is no need to change the parsing order. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=536713&group_id=23194

--__--__--

Message: 11
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 05 Jun 2003 08:13:26 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-507408 ] clarify use of interleaved param

Bugs item #507408, was opened at 2002-01-23 09:27
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507408&group_id=23194

Category: None
Group: Fixed in CVS/Need WG Approval
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tommy (realtommy)
Assigned to: Magnus Westerlund (magwes)
Summary: clarify use of interleaved param

Initial Comment:
As noted in last RTSP telecon, certain implementations
use "interleaved" without a parameter "=n" in the
Transport header.  Please clarify that the parameter is
REQUIRED.

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2003-06-05 17:13

Message:
Logged In: YES 
user_id=302620

This bug is fixed, no comments on solution. Closing item.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 17:45

Message:
Logged In: YES 
user_id=302620

It is evident from the ABNF and also written in the text now. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507408&group_id=23194

End of Rtspspec-bugs Digest

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic