Folks, I have a question on EXT_CENC specified in draft-ietf-rmt-flute-revised. As per the draft, the header extension is "ALC PI Specific." The question I have is whether the extension can be used for any ALC object. If not, how is content encoding of an ALC object signaled? thanks, Lakshminath
Hello Lakshminath,
> I have a question on EXT_CENC specified in
> draft-ietf-rmt-flute-revised. As per the draft, the header extension
> is "ALC PI Specific." The question I have is whether the extension
> can be used for any ALC object. If not, how is content encoding of an
> ALC object signaled?
In the FLUTE context, EXT_CENC is only meant to specify
the (optional) encoding of an FDT Instance. If an object (that is not
an FDT Instance) carried in a FLUTE session is to be content
encoded, then it's signaled in the "Content-Encoded" attribute of
the associated file element in the FDT Instance. You'll find an
example in Appendix B.
If ALC is used by an application that is not FLUTE, then it's
unclear to me whether EXT_CENC can be used or not for any
ALC object or not... I don't see any good reason to prevent it, though.
Maybe it would be good to move it's definition to the ALC I-D and
make clear in the FLUTE I-D that in this context it is restricted
to an FDT Instance. Opinion?
Cheers,
Vincent
** Apologies if you receive multiple copies of this call for papers **
===============================================================================
Call for Papers
NetCri 07
The First International Workshop on
Research Challenges in Next Generation Networks for
First Responders and Critical Infrastructures
http://www.cs.umd.edu/~sharno/NetCri
In Conjunction with
IEEE IPCCC 2007, New Orleans, Louisiana, April 11-13
===============================================================================
As advances in pervasive computing, wireless communication and sensor networks
continue, more opportunities are open to first responders and critical infra-
structures to benefit from these technologies. Providing first responders with
the best possible technology, infrastructure and services help save the lives
of the general public and the first responders as well. One of the main
challenges to the operations of first responders and critical infrastructures
is to deploy a communication network that is dependable, secure, and rapidly
deployable. In order to operate effectively, the deployed network supports
services such as location determination, audio and video communication, and in
site and remote sensing. Another key feature for first responders and critical
infrastructures networks is to support interactions among multiple heterogen-
eous networks.
(Continue reading)
Hi, I have selected Brian Adamson (adamson <at> itd.nrl.navy.mil) to be WG co-chair together with Lorenzo. So congratulations and good luck in the work. I would also like to thank all that volunteered for the position. Best Regards Magnus Westerlund TSV AD
The RMT WG meeting at the 67th IETF is currently scheduled for Tuesday, 7 November 2006 from 1:00 - 3:00 PM. If you have items to add to the agenda please contact Lorenzo <lorenzo <at> vicisano.net> and/or Brian <adamson <at> itd.nrl.navy.mil>. The draft agenda is due by 25 October and a final revision by 30 October, so please provide any input ASAP. We plan to start last calls for some documents that have been pending action soon. It is expected that the security issues raised during the last meeting will be discussed. Vincent Roca and Brian Adamson have submitted an initial draft (non-working group document) attempting to summarize issues related to security for the RMT protocol suite. It is hoped this draft will be announced and made available by the IETF Secretariat soon. Additional discussions in this area are encouraged. best regards, -- -- Brian __________________________________ Brian Adamson <mailto:adamson <at> itd.nrl.navy.mil>
At 03:57 AM 10/9/2006, Vincent Roca wrote: >Hello Lakshminath, > >>I have a question on EXT_CENC specified in >>draft-ietf-rmt-flute-revised. As per the draft, the header >>extension is "ALC PI Specific." The question I have is whether the >>extension can be used for any ALC object. If not, how is content >>encoding of an ALC object signaled? > >In the FLUTE context, EXT_CENC is only meant to specify >the (optional) encoding of an FDT Instance. If an object (that is not >an FDT Instance) carried in a FLUTE session is to be content >encoded, then it's signaled in the "Content-Encoded" attribute of >the associated file element in the FDT Instance. You'll find an >example in Appendix B. > >If ALC is used by an application that is not FLUTE, then it's >unclear to me whether EXT_CENC can be used or not for any >ALC object or not... I don't see any good reason to prevent it, though. >Maybe it would be good to move it's definition to the ALC I-D and >make clear in the FLUTE I-D that in this context it is restricted >to an FDT Instance. Opinion? Thanks Vincent. I think so too. Let's move it into the ALC i-d and make the appropriate references and clarifications in the FLUTE i-d. Perhaps the editors of those i-ds can incorporate this change in the next revisions? Are the drafts being revised for the coming IETF meeting? Thanks in advance to the editors for their work on this.(Continue reading)
CALL FOR PAPERS The Second International Multi-Conference on Computing in the Global Information Technology ICCGI 2007 Date: March 4-9, 2007 Place: Guadeloupe, French Caribbean Site: http://www.iaria.org/conferences2007/ICCGI07.html Submit: http://www.iaria.org/conferences2007/SubmitICCGI07.html includes: - IPv6TD 2007 : The Second International Workshop on IPv6 Today - Technology and Deployment http://www.iaria.org/conferences2007/IPV6TD.html - MOC 2007 : The Second International Workshop on Modeling, Optimization, and Complexity http://www.iaria.org/conferences2007/MOC.html Important deadlines: Full paper submission, October 29, 2006 Author notification, November 29, 2006(Continue reading)
Hi All
Interesting question and worth a little thought.
I guess no one has implemented this for generic ALC objects, so it's
rather less mature a feature than a standards track FLUTE would merit
(experimental FLUTE already had 4 genetically different implementations
ran against each other prior to the experimental RFC - maybe more like
DS than EXP, but it certainly improved the spec enormously). Considering
what is ALC and what is FLUTE, it seems that generic ALC CENC wouldn't
be trivial in practice - now the long winded ("first Rod RMT email in
ages") bit...
With only a cursory look, ALC CENC seems harmless, though it lacks a
driving use case. (Pretty much what Vincent emailed).
For files (the interesting transport objects :), FDT description of
field CENC was the right level of flexibility without too much
complexity or else too much overhead. This was discussed in the early
days of FLUTE (initially FDALC) and probably there will be some email
references to this in the 2002/3/4 time frame. The FDT encoding CENC was
added later as a compromise to avoid the less desirable alternative of a
hierarchy of FDT descriptions. Specifically for reliable multicast
_file_ delivery, FLUTE is the right tool and CENC data is available in
FDTs for that. (As a side note, 3GPP-MBMS specifies not to use the CENC
header at all - i.e. no CENC for FDTs).
OTOH, ALC provides general "object" transfer with no particular bounds,
making it as applicable to "stream objects" as it is to
"bounded/discrete objects" (the latter being an interchangeable
(Continue reading)
Hello, Vincent Roca and I created a preliminary document to capture security issues related to the RMT protocol suite. Although it wasn't announced by the Secretariat on this list, it is available at: http://www.ietf.org/internet-drafts/draft-adamson-roca-rmtsec-issues-00.txt We would like to discuss this document and the way forward with respect to the RMT security issues, etc raised at the last RMT WG meeting. best regards, -- -- Brian __________________________________ Brian Adamson <mailto:adamson <at> itd.nrl.navy.mil>
Hello Rod, It seems to me that the main benefit of moving CENC to ALC is to clarify and rationalize things when it's still feasible. Since object encoding can potentially be required by any application built on top of ALC (FLUTE being one of them), no matter whether it is applied to "stream objects" or "bounded/discrete objects", it's not a bad idea to leave the door open. Of course, with "stream objects" a gzip encoding is meaningless as you say, but one can probably find another encoding for these objects (even if I don't have one in mind). An ALC CENC mechanism can be made sufficiently flexible so that we do not restrict its use to bounded objects. Concerning the applications that could benefit from this ALC level CENC: (1) they already exist, our simple and stupid FCAST file transfer application being one of them. Even if there's currently no need to standardize it, there are use cases where it's sufficient. Why should I use a more complex application then? If an ALC CENC exists, then FCAST would be able to (e.g.) gzip big files on the fly. And there are perhaps other similar applications, designed outside of the RMT group, that have the same needs, who knows? (2) there are probably ALC use-cases we can't even imagine today that would need it. Perhaps Lakshminath has one of them in mind... Even if it's not the case, I'd prefer not to close this door today. And I don't think it's a tough work to move the text, even if I(Continue reading)
RSS Feed1 | |
|---|---|
1 | |
3 | |
1 | |
4 | |
4 | |
5 | |
1 | |
5 | |
2 | |
2 | |
8 | |
2 | |
1 | |
1 | |
4 | |
5 | |
2 | |
2 | |
5 | |
5 | |
6 | |
5 | |
16 | |
15 | |
17 | |
6 | |
10 | |
4 | |
11 | |
19 | |
1 | |
6 | |
4 | |
18 | |
10 | |
12 | |
14 | |
21 | |
7 | |
11 | |
10 | |
8 | |
24 | |
16 | |
5 | |
1 | |
9 | |
5 | |
9 | |
6 | |
20 | |
1 | |
2 | |
11 | |
9 | |
9 | |
5 | |
6 | |
10 | |
11 | |
10 | |
1 | |
10 | |
9 | |
5 | |
14 | |
18 | |
7 | |
8 | |
11 | |
13 | |
5 | |
2 | |
6 | |
30 | |
8 | |
9 | |
29 | |
24 | |
16 | |
20 | |
55 | |
30 | |
64 | |
18 | |
31 | |
14 | |
1 | |
1 | |
8 | |
4 | |
1 | |
2 | |
9 | |
9 | |
16 | |
6 | |
11 | |
6 | |
3 | |
2 | |
2 | |
16 | |
2 | |
3 | |
26 | |
30 | |
2 | |
6 | |
7 | |
6 | |
2 | |
19 | |
13 | |
1 | |
9 | |
4 | |
7 | |
6 | |
12 | |
1 | |
2 | |
3 |
