headers
Martin Stiemerling | 2 Feb 2009 11:40
Picon
Favicon

Re: RTSP From header issue

Hi,

A good question anyhow. I also did wonder about the from header while editing the HTTP parts of the draft. 

I wouldn't removing it, as it does look a bit as legacy which isn't used.

  Martin

stiemerling <at> nw.neclab.eu

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England
2832014 
> -----Original Message-----
> From: mmusic-bounces <at> ietf.org [mailto:mmusic-bounces <at> ietf.org] On
> Behalf Of Rémi Denis-Courmont
> Sent: Thursday, January 08, 2009 9:38 AM
> To: mmusic <at> ietf.org
> Cc: ext Ingemar Johansson S
> Subject: Re: [MMUSIC] RTSP From header issue
> 
> On Thursday 08 January 2009 10:33:25 ext Ingemar Johansson S, you
> wrote:
> > Hi
> >
> > Going through the syntax of the parts that handles URI's I found a
> possible
> > issue with the syntax of the From header. 1) In section 16.23 in RTSP
> 2.0
> > there is only a reference section 14.22 in RFC2616 which contains a
(Continue reading)

Permalink | Reply | 3 comments |
headers
Martin Stiemerling | 2 Feb 2009 11:46
Picon
Favicon

Re: RTSP From header issue

well, it should read

I wouldn't mind removing...

  Martin

stiemerling <at> nw.neclab.eu

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England
2832014 

> -----Original Message-----
> From: Martin Stiemerling
> Sent: Monday, February 02, 2009 11:41 AM
> To: 'Rémi Denis-Courmont'; mmusic <at> ietf.org
> Cc: ext Ingemar Johansson S
> Subject: RE: [MMUSIC] RTSP From header issue
> 
> Hi,
> 
> A good question anyhow. I also did wonder about the from header while
> editing the HTTP parts of the draft.
> 
> I wouldn't removing it, as it does look a bit as legacy which isn't
> used.
> 
>   Martin
> 
> stiemerling <at> nw.neclab.eu
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rémi Denis-Courmont | 2 Feb 2009 11:52
Picon

Re: RTSP From header issue

On Monday 02 February 2009 12:40:38 ext Martin Stiemerling, you wrote:
> A good question anyhow. I also did wonder about the from header while
> editing the HTTP parts of the draft.
>
> I wouldn't removing it, as it does look a bit as legacy which isn't used.
            ^
          mind?

I definitely would remove it. It is not used. There are high-level reasons not 
to use it: privacy/spam. There is a low-level reasons not to use it: media 
player is typically not provisioned with email address.

I would even advocate removing it from httpbis, if I were asked...

--

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
Permalink | Reply | 2 comments |
headers
Ingemar Johansson S | 4 Feb 2009 09:41
Picon
Favicon

Re: RTSP From header issue

Hi

I have no specific opinon about the existence of the From header.
I would however like bring up my second question about the use of DQ around URI's. 

>3) In general. The idea to use DQ around URI's in some cases and in some cases 
> not may cause some headache for the implementor. 
> Sure, one should read the ABNF but I would say that it would be more 
> consistent to always use DQ around URI's in headers regardless if they are needed or not.

Any comments ?

Regards
/Ingemar

> -----Original Message-----
> From: Rémi Denis-Courmont [mailto:remi.denis-courmont <at> nokia.com] 
> Sent: den 2 februari 2009 11:52
> To: ext Martin Stiemerling
> Cc: mmusic <at> ietf.org; Ingemar Johansson S
> Subject: Re: [MMUSIC] RTSP From header issue
> 
> On Monday 02 February 2009 12:40:38 ext Martin Stiemerling, you wrote:
> > A good question anyhow. I also did wonder about the from 
> header while 
> > editing the HTTP parts of the draft.
> >
> > I wouldn't removing it, as it does look a bit as legacy 
> which isn't used.
>             ^
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin Stiemerling | 4 Feb 2009 10:06
Picon
Favicon

Re: RTSP From header issue

Hi Ingemar,

> -----Original Message-----
> From: mmusic-bounces <at> ietf.org [mailto:mmusic-bounces <at> ietf.org] On
> Behalf Of Ingemar Johansson S
> Sent: Wednesday, February 04, 2009 9:41 AM
> To: Rémi Denis-Courmont; Martin Stiemerling
> Cc: mmusic <at> ietf.org
> Subject: Re: [MMUSIC] RTSP From header issue
> 
> Hi
> 
> I have no specific opinon about the existence of the From header.
> I would however like bring up my second question about the use of DQ
> around URI's.
> 
> >3) In general. The idea to use DQ around URI's in some cases and in
> some cases
> > not may cause some headache for the implementor.
> > Sure, one should read the ABNF but I would say that it would be more
> > consistent to always use DQ around URI's in headers regardless if
> they are needed or not.
> 
> Any comments ?

I'm not an implementer (not in general but in the case of RTSP I'm not ;), anyhow:

checking the ABNF, it seems to be not straight forward when the RTSP-URI is set in DQ and when not. I.e., it
would be good to get this streamlined.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 9 Feb 2009 14:30
Picon
Favicon

I-D Action:draft-ietf-mmusic-image-attributes-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title           : Negotiation of Generic Image Attributes in SDP
	Author(s)       : I. Johansson, K. Jung
	Filename        : draft-ietf-mmusic-image-attributes-00.txt
	Pages           : 18
	Date            : 2009-02-06

This document proposes a new generic session setup attribute to make
it possible to negotiate different image attributes such as image
size.  A possible use case is to make it possible for a e.g a low-end
hand-held terminal to display video without the need to rescale the
image, something that may consume large amounts of memory and
processing power.  The draft also helps to maintain an optimal
bitrate for video as only the image size that is desired by the
receiver is transmitted.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-image-attributes-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment (draft-ietf-mmusic-image-attributes-00.txt): message/external-body, 70 bytes
(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Ingemar Johansson S
 | 
9 Feb 2009 16:59






Picon

Favicon





draft-ietf-mmusic-image-attributes-00


Hi

A new version of the image attribute draft has been submitted (now a WG draft)
http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-image-attributes/

The main change is that the syntax has been changed to ABNF, moreover most of the open issues from the
individual -02 version has been sorted out. 

Abstract
   This document proposes a new generic session setup attribute to make
   it possible to negotiate different image attributes such as image
   size.  A possible use case is to make it possible for a e.g a low-end
   hand-held terminal to display video without the need to rescale the
   image, something that may consume large amounts of memory and
   processing power.  The draft also helps to maintain an optimal
   bitrate for video as only the image size that is desired by the
   receiver is transmitted.

Comments are welcome
Regards
Ingemar

******************************************* 
Ingemar Johansson 
Senior Research Engineer, IETF "nethead" 
EAB/TVP - Multimedia Technologies 
Ericsson Research Ericsson AB 
Box 920 S-971 28 Luleå, Sweden 
Tel: +46 (0)10 7143042 
ECN: 852-43042 

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Ingemar Johansson S
 | 
11 Feb 2009 08:17






Picon

Favicon





Setup of Asymmetric Media with SDP


Hi

A new draft that proposes an extension to the SDP Capability Negotiation framework (SDPCapNeg) for the
setup of asymmetric sessions has been submitted
http://tools.ietf.org/id/draft-johansson-mmusic-asymmetric-media-00.txt

Abstract
   This draft proposes an extension to the SDP Capability Negotiation
   framework for the setup of asymmetric sessions.  One example of an
   asymmetric session is a conversational video session between a
   handset with a small screen (high-resolution camera) and a home-
   entertainment set-top box connected to a wide-screen TV.  Another
   example is tightly coupled conferences with different number of in
   and outgoing streams for each client.

Comments are welcome
Regards
Ingemar
******************************************* 
Ingemar Johansson 
Senior Research Engineer, IETF "nethead" 
EAB/TVP - Multimedia Technologies 
Ericsson Research Ericsson AB 
Box 920 S-971 28 Luleå, Sweden 
Tel: +46 (0)10 7143042 
ECN: 852-43042 
ECC: 852-19042
Mobile: +46 (0)730 783289 
Visit http://labs.ericsson.com !
******************************************* 

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Alex Giladi
 | 
11 Feb 2009 19:52






Picon





Non-standard RTSP extensions


Hi

As far as I know, there are several non-normative extensions to RTSP
1.0, used by some VOD vendors.
Are there any specs on these?

Thanks!

Alex.






Permalink
| Reply
| 4 comments  
| 



  

  

  





headers


Rémi Denis-Courmont
 | 
11 Feb 2009 20:00






Favicon





Re: Non-standard RTSP extensions


Le mercredi 11 février 2009 20:52:17 Alex Giladi, vous avez écrit :
> As far as I know, there are several non-normative extensions to RTSP
> 1.0, used by some VOD vendors.
> Are there any specs on these?

Not at IETF. IIRC, Microsoft has published "their" RTSP with the rest of their 
network protocol interoperability specifications. I don't know if 3GPP has 
defined any extensions but you should be able to check easily from their 
website, but it is not a "vendor" anyway.

I am not aware of any specs from Apple, Real and Amino. Other vendors that I 
know follow RFC2326 proper.

--

-- 
Rémi Denis-Courmont
http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary






Permalink
| Reply
| 3 comments  
| 



  

  

  

  


  





    



Gmane