URL attributes

pays@faugeres.inria.fr Tue, 16 November 1993 20:25 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13677; 16 Nov 93 15:25 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13673; 16 Nov 93 15:25 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa19760; 16 Nov 93 15:25 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.07632-0@haig.cs.ucl.ac.uk>; Tue, 16 Nov 1993 19:23:22 +0000
Received: from faugeres.inria.fr by bells.cs.ucl.ac.uk with Internet SMTP id <g.07744-0@bells.cs.ucl.ac.uk>; Tue, 16 Nov 1993 19:23:03 +0000
X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed; 16 Nov 93 20:22:55+0100
Date: 16 Nov 93 20:22:55+0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: pays@faugeres.inria.fr
To: osi-ds@cs.ucl.ac.uk
Subject: URL attributes
cc: Paul-Andre.Pays@faugeres.inria.fr
Message-ID: <753477775.9970.0-faugeres.inria.fr*@MHS>


While refining a bit a very simple WWW gateway to X.500 we have been led to
define new attribute types for URL.

This allows an entry to contain Web "references" to any type of document
that the WEB is able to cope with and in particular to MPEG Video,
G3Fax Photox, sound or plain unspecified URL.

The big win with this approach is that the DSA does no longer 
have to deal with possibly huge amount of data as it just has to handle
the short character string URL. The client (DUI) will, on user request
only, decide to retrieve that type of attributes. It will access
directly the information without any relaying through possibly
several chaining DSAs.
This seems to me the way to really integrate multimedia information
to X.500/WPS entries.

There is of course a disadvantage: the client, in order to get all these
attributes and 'display' them has to be WWW capable.
However, in any case any X.500 client having to display that type of 
information will need a lot of stuff;  thus, why reinvent the wheel and 
not use what exists and is spreading so fast over the internet?

My question is:
 how to proceed to "standardize" these new attribute types for the internet?


regards,

-- PAP


PS1: if you want to have a look at it, use Xmosaic 2.0+
	and open 

	http://perignon.inria.fr:2200/htbin/x500person/C=fr;O=inria;OU=dmi?pays

this is experimental and under development, thus please limit to this single
	entry




PS2: here are what we use now:
(it is just the current state and can be extended or modified
without problems)

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

transpac:                  ccitt network-operator 2080;

inria-sophia-reseau:            transpac 0603020370;

inria-attributeType:               inria-sophia-reseau attributeType (4);



inria-objectClass:         inria-sophia-reseau objectClass (6);



UsefulDefinitions

-- INRIA extension for URL attributes

SelectedAttributTypes

PlainURL:       caseExactStringSyntax, inria-attributeType 101;
PhotoURL:       caseExactStringSyntax, inria-attributeType 102;
SoundURL:       caseExactStringSyntax, inria-attributeType 103;
VideoURL:       caseExactStringSyntax, inria-attributeType 104;

SelectedObjectClasses

inriaPerson: SUBCLASS_OF organizationalPerson,
        MAY_CONTAIN  PlainURL PhotoURL SoundURL VideoURL,
        inria-objectClass 101;