From Unicode Consortium: Proposed changes to Bidi
From the Unicode Consortium: There are some proposed changes to the Unicode Bidi algorithm. The latest proposed update is here: http://www.unicode.org/reports/tr9/tr9-12.html People in IETF concerned with bidi as it relates to IDN, security and other applications may wish to keep up with the status of these proposed changes. Patrik
national security
While parallel issues start being discussed and better understood at WSIS, we have next week a meeting on Internet national security, sovereignty and innovation capacity. The interest is not sites nor network protection layers, but nations protection from what happens on or with the networks. This is in line with the White House document http://whitehouse.gov/pcipb with the addition of the risks created by the US (and every other national) cyber security effort, and from not mastering the root. In most of the cases the identified risks root come from a centralized which has to be made distributed. The target is to analyze if there is an urgent duty of precaution, in considering various scenarios and the way a nation may address them. They range from open conflict with "nsicanntiab" to catastrophic weather situation on the East Coast and black out due to Internet, terrorist attack on the USA, dramatic increase of the spam, war, etc. Next step will be to identify and to work on a catalog of actions and project to reduce the risks and to protect the users and critical usages of the network in periods of emergency. Some propositions have no technical or remote technical impact. They are mostly the ones aiming at preventing human rooted risks in organizing a stable concerted (European meaning) governance.They range from a web information and services providers and a user network support organizations, the creation of an ITU-I to welcome the higher layers issues for the information society, a universal name system (uninames) and its generalization across network technologies [this would impact on the vernacularisation of e-mail names, IDNA, cultural areas in UDRP, etc.), a co-management of the international parts of the IANA and root file by the ccTLDs, etc. Some others have technical implications. I would like to quote some suggestions listed in the preparatory document, to get advices I could quote at the meeting or in its report. Also to list the alternative and additional suggestions some might do. 1. a ".dir" emergency virtual TLD. (Directory of direct accesses). This would be a per country Host.txt file documenting critical sites and services. For example "cnn.dir" would route to the IP address of CNN. This file could be easily retrieved at a known IP. Quoting main commercial sites (while permitting its immediate use) would finance its organization. 2. a menu server system permitting to access sites though their IP address only. This would be a good promotion for IPv6 due to the easiness to support IP virtual hosts addresses. As a security oriented alternative to the NSI network unstabilization. 3. national mirrors of http://ns.internic.net . ISPs and corporations would be advised to load the root from these mirrors. In case of collapse of the US Internet, local authorities could patch an updated root in hours, keeping with the current situation. TTL histeresys is probably to be carefully considered. 4. national IANA files, from TLD Managers direct information collection. With a constant mutual consistency check among national copies and ICANN (to avoid the KP&Quest situation). 5. the possibility of a redundant DNS system. Today the Internet has two root files (the same file but presented on two main systems - DNS and FTP). If one is hacked there is not reference. A redundant system would consist in two or more root masters refereeing to different sets of TLD name servers (all of them carrying the same files, but possibly of different origins for security reasons). 6. an evolution towards an international root matrix supporting proximity root servers and proximity TLDs for abbreviated addressing through local TLDs. The organization and the procedure of the common authoritative root matrix should be internationally approved and subject to the ICP-3 proposed testing rules. A quoted example documents the target as "hart.sos" of pacemakers always resolving to the nearest hospital (as decided by local authorities). Local root servers would support teleurbanism and domotic usage. They could be installed at mobile and wi-fi stations. 7. the development of a GPL resolver for every operating systems. It will support both a private root and private TLDs. Private TLDs would be consistent with the RFC 920 and current consensus on schemes. gTLD use 3 letters and above. ccTLD are national and use 2 letters. Private TLD would local and use 1 letter. This would be consistent with the schemes. One letter schemes describe the private local disk space. One letter TLDs describe, at the other end of the URL, the private net space. This will permit everyone to use a family, a local or a community part of the Host.txt existing solution. Example ".h" could be commonly used for home, ".s" for school, ".c" for church and charity help, ".b" for business, ".d" for defense and protection, ".w" for local web and welfare. 8. an IPv6.010 second numbering plan conf
RE: national security
Sorry for the typo - I miss my glasses :-) - http://rs.internic.net (not ns.internic.net as I typed). jfc
media type?
Dear all, I the context of some research I am conducting at the Los Alamos National Laboratory, I encountered the following ambiguity regarding the meaning of 'media type'. Assume I have a parameter called Y. Y is defined as follows: "Y = a MIME media type value indicating the type of a resource". According to both RFC 2045 and 2046, the exact meaning of Y could be defined as one of both: - According to RFC 2045, a media type is: "The purpose of the Content-Type field is to describe the data contained in the body fully enough that the receiving user agent can pick an appropriate agent or mechanism to present the data to the user, or otherwise deal with the data in an appropriate manner. The value in this field is called a media type." As such, a possible value of Y could be "text/xml; charset=utf-8"? - Based on some illustrative examples in RFC 2046, I could also derive that a media type is a general category of data content, such as: 'application', an 'image', a 'text' message, a 'video' stream, and so forth. Each of these media types can have 'subtypes'. For example, the 'text' media type has four subtypes: 'plain', 'richtext', 'enriched', and 'tab-separated' values. As such, a possible value of Y could be: "text" Am I correct in stating this? Could someone clarify this ambiguity? How should I change the definition of Y in order to exclude one of both meanings? Thanks in advance Kind regards Jeroen Bekaert -- Digital Library Research and Prototyping team Los Alamos National Laboratory PO Box 1663, MS P362 Los Alamos, NM, 87545, USA tel. +1 (505) 664 0580 Department of Electronics and Information Systems Faculty of Engineering, Ghent University Sint-Pietersnieuwstraat 41 B-9000 Ghent, Belgium
Re: media type?
On Thu, 27 Nov 2003 18:32:50 MST, Jeroen Bekaert <[EMAIL PROTECTED]> said: > As such, a possible value of Y could be "text/xml; charset=utf-8"? > As such, a possible value of Y could be: "text" You want media-type to be "text" with a subtype of "xml" and a parameter "charset=utf-8". I don't see any way to use the BNF of RFC2046, section 5.1 to get any other parse. In fact, further down in section 5, it says: type of data. Thus, a media type of "image/xyz" is enough to tell a user agent that the data is an image, even if the user agent has no knowledge of the specific image format "xyz". Such information can be used, for example, to decide whether or not to show a user the raw data from an unrecognized subtype -- such an action might be reasonable for unrecognized subtypes of text, but not for unrecognized subtypes of image or audio. For this reason, registered So the intent is to have the media-type say "this is text" or "this is an image" or "this is a sound" or "this is a composite", and so on, so that an MUA can make a vague guess as to what do with it even if it has no clue at all what to do with the specific subtype or parameters. For instance, an MUA would be within it's rights to refused to deal with *any* flavor of text/* (including even text/plain) if it included a 'charset=' parameter it didn't know how to deal with. As an example, displaying *any* sort of Big5 text on a display that is ascii/8859-* only is basically doomed... pgp0.pgp Description: PGP signature
RE: media type?
Dear Valdis, Thanks for your reply! If I understand this correctly, defining Y as: 1. "a MIME media type value indicating the type of a resource" results in: "text" 2. "a concatenation of MIME media-type, subtype and parameters indicating the type of a resource" results in: "text/xml; charset=utf-8" 3. "a MIME content-type value indicating the type of a resource" results in: "Content-Type: text/xml; charset=utf-8" Regards Jeroen Bekaert > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Thursday, November 27, 2003 8:34 PM > To: Jeroen Bekaert > Cc: [EMAIL PROTECTED] > Subject: Re: media type? > > On Thu, 27 Nov 2003 18:32:50 MST, Jeroen Bekaert > <[EMAIL PROTECTED]> said: > > > As such, a possible value of Y could be "text/xml; charset=utf-8"? > > > As such, a possible value of Y could be: "text" > > You want media-type to be "text" with a subtype of "xml" and > a parameter "charset=utf-8". > > I don't see any way to use the BNF of RFC2046, section 5.1 to get any > other parse. In fact, further down in section 5, it says: > >type of data. Thus, a media type of "image/xyz" is enough to tell > a >user agent that the data is an image, even if the user agent has > no >knowledge of the specific image format "xyz". Such information > can >be used, for example, to decide whether or not to show a user the > raw >data from an unrecognized subtype -- such an action might be >reasonable for unrecognized subtypes of text, but not for >unrecognized subtypes of image or audio. For this reason, > registered > > So the intent is to have the media-type say "this is text" or "this > is an > image" or "this is a sound" or "this is a composite", and so on, so > that an MUA > can make a vague guess as to what do with it even if it has no clue > at all what > to do with the specific subtype or parameters. For instance, an MUA > would be > within it's rights to refused to deal with *any* flavor of text/* > (including > even text/plain) if it included a 'charset=' parameter it didn't know > how to > deal with. As an example, displaying *any* sort of Big5 text on a > display that > is ascii/8859-* only is basically doomed... >
