Subject: RE: [Rmt] Extended attributes

From: [email-masked]
Date: Wed, 15 Oct 2003 12:56:39 +0300

Hi Roger, Justin

For the basic FLUTE specification, I tend to agree with Justin, in that the spirit of FLUTE is a transport protocol. Thus, only the metadata related to transport the should be manditorily carried in-band.

On the other hand using tar (to provide some file attributes) means that the FLUTE content type field only says tar and leaves it to the client application to extract and determine that the useful file is something else - like gif. Also, tar doesn't give everthing Roger wants, so that means defining "something like tar" - I'm not sure if that's a good idea.

What I'd propose is that you experiment with FLUTE's FDT, it's extensible so that any normal FLUTE recievers shouldn't break if they get 'unknown/experimental' additional XML in the FDT. Try an extended schema that includes file attributes and access attributes (even per OS - the power of XML is breathtaking :). Signalling destination directory structure has also come up in discussion so if that's interesting it could also be piggy-backed onto the same extended schema (personally I'm running on the assumption that the receiver has a 'base' directory preconfigured and drops the files into subdirectories of this according to the FLUTE locator/URL, but it's intentionally left open in the FLUTE ID).

It would be great to review the "Extended FDT Schema for File Archive Exchange over FLUTE" either in email or as ID.

To me it feels right to keep this as a seperate ID rather than an option in the base FLUTE spec - what do you think?

Of course, all the ancillary data could be given "out-of-FDT-band" either over a seperate logical/protocol/physical channel or in a non-FDT object (similar to having a directory of FDTs using more than just TOI 0, which FLUTE allows but does not mandate). This is something being considered for the MUPPET ID (work-in-progress from Luoma, and related to IMG/MMUSIC) for an announcement protocol that sends "in-addition-to-FDT" metadata, like SDP files.

Cheers, Rod.

> -----Original Message-----
> From: ext Justin Chapweske [mailto:[email-masked]]
> Sent: Saturday, October 04, 2003 6:07 PM
> To: Lindholm Roger
> Cc: [email-masked]
> Subject: Re: [Rmt] Extended attributes
> 
> 
> IMO, these types of attributes should be preserved by a file archival 
> format, like tar, and not a transport protocol.
> 
> The transport protocol should aim to provide meta-data that is 
> equivilent to what you would receive via HTTP.
> 
> -Justin
> 
> Lindholm Roger wrote:
> > Hello,
> > I have just read the FLUTE specification and thinks it's a 
> great step 
> > forward. I worked in a project a couple of years ago that 
> developed a 
> > similar thing but propriatary. A couple of things that we 
> needed that I 
> > can't see in the FLUTE or in any discussions on the 
> mailinglist is a 
> > standard way to describe extended file attributes like Read only, 
> > Hidden, System and Archive.
> >  
> > It would also be nice to be able to specify security 
> related things like 
> > ACL/Rights, Owner, Group and Auditing when used in a 
> controlled security 
> > domain even if this is probably harder to express in a OS 
> independent way.
> > I understand that some of these attributes are OS dependent, but it 
> > would still be nice to have a standardized way to describe them for 
> > interoperability instead of letting each implementor chose 
> their own syntax.
> >  
> > Best regards
> > Roger Lindholm
> 
> 
> -- 
> Justin Chapweske, Onion Networks
> http://onionnetworks.com/
> 
> 
> _______________________________________________
> Rmt mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rmt
> 

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