RE: Re: [Rmt] SDP descriptors for ALC

Hi Magnus, thanks for the response.

3 issues: a=flute-tsi; "*" fmt; ALC/UDP rules.

-----

"*" fmt...

The issue of "*" was already rasied a few times over the last 2 years in
emails and face-to-face. Originally we were considering "null" or "-"
instead of the already de facto "0" which didn't get much of a fan base
in MMUSIC. Put simply, some fmt value needs giving and we generally
don't want or need to list MIME types so either we hope the world is
aware of the de facto "0" or we assign an well known RFC's character
string. "*" just seems the best and most understandable choice. (Note, I
don't mean to exclude application/whatever and other MIME type
specifications, we just need a miscellaneous one which isn't a non
standards hack). Check out the numersous SDP examples in our
DVB+3GPP+OMA+IETF world for "0" usage.

Unless there is some world changing reason to drop "*", let's keep it

-----

ALC/UDP rules...

I'm not sure I fully grip the point. ALC is underspecified. E.g. OMA's
use of ALC is only feasible as they create a fully specified version
(actually by binding it to ESG metadata - a little beyond IETF Transport
Area's mandate), and for some reason they like to still call it ALC
giving a confusing impression that it's underspecified. Check out the
LCT and ALC RFCs or revised I-Ds and you come across a host of options,
most of which FLUTE bangs down to fully specified or leaves for
flute-sdp to fill in the parameters. Use of the checkpoint field is
totally open in ALC and in some fully specified versions it'll make a
sense to give a mapping in the session description (SDP) and in others
not. This is one example of something I simply do not want to touch
since fancy use of this field is not backed up by the same kind of
implementation rigour we have already got for FLUTE. OTOH, much of the
flute-sdp semantics could be used for LCT sessions in general and making
this explicit has its distinct advantages (I won't be picking up the
pieces of OMA-IETF divergence if it occurs, and having fought the for
DVB+3GPP+IETF I'm not sure I would recommend the job for it's fun factor
:)

So allowing underspecified ALC/UDP media means that two or more hosts
can "out-of-band" figure out what the full-spec would be and still use
the session description of underspecified ALC.

And this brings us onto the reason I've taken these 3 points out of
order. ALC vs. LCT. ALC is LCT with a few header extensions. If you were
to question why have separate LCT and ALC specifications and not just
one combined one you wouldn't be the first and certainly not the last as
there is no attempt to combine them and disturb mature specification
text and standards progress (you'd get verbose emails like this all over
the place :). It's LCT which defined the basic session semantics and ALC
and FLUTE add some more expectations of senders and recievers. As such,
I think I made and error in my response to Imed in that I should have
suggested "lct" instead of "alc" in the text string. My mind is mulling
this over during my short commutes so I may have an epiphany before
tomorrow.

Practically, if underspecified ALC or LCT is OK then we can bundle these
basics into flute-sdp, if not then forget it and let's stonewall the
whole discussion until the 3GPP+DVB+IETF aligned flute-sdp has been
published. (I am certainly unwilling to work on two at once and judging
by the number of actual text writters this may be a bit of a problem).

-----

a=flute-tsi vs. a=lct-tsi

Actually this is a good point which I anticipated coming up. First off
let's assume tsi is short and therefore culturally ambiguous even if
fixed in SDP stone; and that actually lct uses all these base properties
- i.e. that "a=lct-tsi" is the sting to use.

This comes down to the fully specified vs. underspecified issues.
Flute-tsi clearly signals that all FLUTE/UDP media of this LCT session
("composite" or "restricted") form exactly one FLUTE session. Whereas
lct-tsi does not in fact limit what protocol ids are used in the lct
session as long as they are lct-based. I don't imagine mixed FLUTE/UDP
and ALC/UDP, but there is no sense in preventing mixed new1/xxx and
new2/xxx if someone has such a session need and the common factor is
LCT. Allowing this case does not pay my salary and I won't religeously
hang onto it, but it's a genuine use of LCT so excluding it makes no
sense.

As for flute-ch, the only reasonable argument why not to change to
lct-ch is that it would not be aligned with FLUTE SDP usage already
frozn in other standards bodies. (Obvioulsy this argument also applies
to flute-tsi but it's not as fundemental as the previous issue). In the
simplest form, flute-ch and lct-ch have exactly the same semantic.

However, if you were to start specifying the complex composite session
cases, you'd need to fix some things. Intentionally a composite (and
restricted) FLUTE session groups all FLUTE/UDP media of that composite
(or restricted) session into one FLUTE session. This is exactly right
and good. It also allows other protocol ID'ed media in the composite and
restircted sessions but those are not part of the FLUTE session (e.g. a
composite session consisting of RTP and FLUTE media which would
obviously be handled as one FLUTE session and multiple RTP media
sessions combined to one composite session). Naturally, I don't want to
get too deep into this as we'll be doing application design before long.
Needless to say, enabling application designers to use our transports is
what we are aiming to achieve.

If you were to have lct-tsi declared and also FLUTE media, how should
that be interpretted? If both lct-tsi and flute-tsi for a composite
session, what's that all about? This is the philosophical and practical
centre of all this: how underspecified can an LCT session really be?

For practical purposes, the declaration of a flute-tsi really has to say
that a FLUTE session of all FLUTE/UDP media (and without other media) is
described. For simplicity's sake, making the declaration of a flute-tsi
manditory when FLUTE/UDP media are described is acceptable; as is
explicitly stating that the use of FLUTE/UDP media with other session
semantics (including that of the parental LCT) is beyond the scope of
this specification.

For harmony reasons, we could include the LCT/UDP (or maybe ALC/UDP)
protocol id as something generic and underspecified, and the lct-tsi as
an indicator of an lct session; and require that the binding of the lct
session to specific protocol ids must be done, but is beyond the scope
of this specification. If we can't agree this, then let's allow the OMA
folk to have a stab and see if we like it after a few months. (In
anycase they'll have out flute-sdp at a reference as soon as it's
published so harmony for FLUTE sessions should be a dead cert).

We might also specify that only one of lct-tsi or flute-tsi is allowed
for one composite or restricted session. I don't see the need either
way, but if it helps consensus, why not?

-----

Cheers, Rod.



>-----Original Message-----
>From: [email protected] [mailto:[email protected]] 
>On Behalf Of ext Magnus Westerlund
>Sent: 06 February, 2006 11:47
>To: Bouazizi Imed (Nokia-NRC/Tampere)
>Cc: [email protected]; [email protected]
>Subject: [MMUSIC] Re: [Rmt] SDP descriptors for ALC
>
>Hi Imed and Rod,
>
>I do have some comments on your proposal.
>
>First of all why have both a=flute-tsi and an a=alc-tsi. 
>Wouldn't a a=tsi attribute be more appropriate. To my 
>understanding there is no difference in TSI between the two. 
>Also if some other fully specified protocol uses TSI they can 
>reuse the TSI attribute. As the protocol will identify if it 
>is flute or ALC, or something else in the future I don't see a 
>risk of misinterpretation. The same comment applies also to 
>the channel attribute. However here something more than a=ch 
>is probably a good thing to indicate that it is the number of 
>transport channels rather than related to media. Maybe a=trn-ch?
>
>I am also concerned by the use of * and no rules for the 
>ALC/UDP protocol. Having something that is underspecified but 
>no defined rules for how fully specified mechanisms are 
>identified seem to be a bad choice. I would recommend that one 
>uses some type of identifier space here. I don't think media 
>types are the correct one, but some space should be set up to 
>identify applications.
>
>cheers
>
>Magnus
>
>-- 
>
>Magnus Westerlund
>
>Multimedia Technologies, Ericsson Research EAB/TVA/A
>----------------------------------------------------------------------
>Ericsson AB                | Phone +46 8 4048287
>Torshamsgatan 23           | Fax   +46 8 7575550
>S-164 80 Stockholm, Sweden | mailto: [email protected]
>
>_______________________________________________
>mmusic mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/mmusic
>