From owner-ietf-medfree@imc.org Wed Jan 5 23:28:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22260 for ; Wed, 5 Jan 2000 23:28:27 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA19869 for ietf-medfree-bks; Wed, 5 Jan 2000 20:11:25 -0800 (PST) Received: from iba.ne.jp (iba.ne.jp [210.143.98.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA19865 for ; Wed, 5 Jan 2000 20:11:21 -0800 (PST) From: 1investmentinfo@4-charity.org Received: from LocalHost (254-216.205.45.sagenetworks.com [216.205.45.254] (may be forged)) by iba.ne.jp (8.8.8/3.6Wbeta7) with SMTP id NAA07858; Thu, 6 Jan 2000 13:06:06 +0900 Message-Id: <200001060406.NAA07858@iba.ne.jp> MessageID: To: X-See-Also: 07916CEDA Date: Wed, 05 Jan 2000 23:03:40 X-Accept-Language: en X-Other-References: 0FEAD4E0F Subject: investment idea dvdt Content-Type: text/html X-Mailer: Internet Mail Service [35.0.3556.33] (Linux; I) Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Press Release

Stockreporter Announces Investment Opinion on Digital Video Display Technology Corp.; Strong Buy Recommendation and Share Price Target of $6.00 in First Year
NEW YORK, Oct 21, 1999 (BUSINESS WIRE) -- Digital Video Display Technology Corp. (OTCBB:DVDT) received a strong buy recommendation today from Stockreporter, a leading European financial Internet publication at http://
Stockreporter specializes in the coverage of micro caps and undervalued OTC and BB companies and is the first international analyst to cover DVDT and publish an investment opinion. Stockreporter very conservatively values DVDT stock at $6.00 per share in Stockreporter has an extraordinary record of successful buy recommendations, with unusual share price appreciation following its coverage. Examples are: FutureLink Distribution (FLNK), Teltran International (TLTG) and Geotele.com Inc.(GEOL).

Dennis C. Hass of Stockreporter commented on the recommendation: "DVDT represents an extraordinary investment opportunity! Buying its stock is not just investing in a business that is ready to experience outstanding success with a product line that will r
For More Information on DVDT Visit:
www.dvdtinvestors.com
www.market-info.com

Copyright (C) 1999 Business Wire. All rights reserved.
Distributed via COMTEX.
CONTACT:
Stockreporter.de, Hamburg, Germany
Mr. Dennis C. Hass, +49-172-4062621
Email:contact@stockreporter.de
Homepage:www.stockreporter.de
WEB PAGE:http://www.businesswire.com
GEOGRAPHY:NEW YORK INTERNATIONAL EUROPE
INDUSTRY CODE: INVESTMENT OPINION
Today's News On The Net - Business Wire's full file on the Internet
with Hyperlinks to your home page.

Disclaimer:
This publication contains forward-looking statements within the meaning of Section 27A of the Securities Act of 1933 and Section 21E of the Securities Exchange Act of 1934. The Company's actual results could differ materially This message is sent in compliance of the new e-mail bill: SECTION 301, Paragraph (a)(2) (C) of S. 1618
Sender: 4-you.com, 2600 N. Central Ave. Suite 720 Phoenix, AZ 85004
To be removed form this mailing list, simply reply with remove in subject line: 4-charity@4-charity.org

Disclosure:
4-you.com, Inc publishes information regarding selected companies involved in many different industries, which those interested in these companies may use as information relating to their interests or investments. Many compan mailto:4-charity@4-charity.org , 4-you.com, Inc. 2600 N. Central Ave. Suite 720 Phoenix, AZ 85004
From owner-ietf-medfree@imc.org Sat Jan 8 06:51:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17797 for ; Sat, 8 Jan 2000 06:51:02 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA09503 for ietf-medfree-bks; Sat, 8 Jan 2000 03:48:53 -0800 (PST) Received: from energy.ogu.edu.tr (root@energy.ogu.edu.tr [193.140.141.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA09483; Sat, 8 Jan 2000 03:48:46 -0800 (PST) From: blilrel16@aol.com Received: from energy.ogu.edu.tr (98C9FD37.ipt.aol.com [152.201.253.55]) by energy.ogu.edu.tr (8.8.8/8.8.4) with SMTP id NAA03404; Sat, 8 Jan 2000 13:42:50 +0200 Date: Sat, 08 Jan 00 01:43:26 EST To: Friend@public.com Subject: A Search Engine Just For You ! Message-ID: <> Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This e-mail is to inform you of a new search engine for adult web sites: http://www.adultfairlinks.com. Fairlinks is being built at this time and will be launched in a few months. We are contacting webmasters now so you can take a look at the site and give us any input you may have. This site will be unique since it will be a TRUE SEARCH ENGINE FOR ADULT SITES. There will be no banner ads, no support from any adult site. All categories will rotate so that each site will be at the top. Two thirds of all money collected will then be used to promote Fairlinks. Most advertising will be done off the web with plans already made to market the site on the Internet. We are going to pool thousands of adult sites together to form a partnership that will make a formidable force and to have funds for national advertising. Please take a look, join in and get your site promoted as it should be! http://www.adultfairlinks.com To be removed, call (888) 341-4786 and Clearly spell your email address and you will be removed. From owner-ietf-medfree@imc.org Mon Jan 10 11:46:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07559 for ; Mon, 10 Jan 2000 11:46:12 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA09730 for ietf-medfree-bks; Mon, 10 Jan 2000 08:35:56 -0800 (PST) Received: from typhoon.mail.pipex.net (typhoon.mail.pipex.net [158.43.128.27]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA09726 for ; Mon, 10 Jan 2000 08:35:53 -0800 (PST) Received: (qmail 25083 invoked from network); 10 Jan 2000 16:36:11 -0000 Received: from userau23.uk.uudial.com (HELO gk-vaio) (62.188.137.225) by smtp.dial.pipex.com with SMTP; 10 Jan 2000 16:36:11 -0000 Message-Id: <4.2.2.20000110145024.00a58120@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 10 Jan 2000 15:57:34 +0000 To: hardie@equinix.com From: Graham Klyne Subject: Re: URI references and aggregation Cc: ietf-medfree@imc.org In-Reply-To: <199912202021.MAA12070@kiwi.equinix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ted, I apologize for taking so long to respond to this. If I understand you correctly, you are proposing that: (1) There is an IANA-allocated URL associated (in a well defined fashion) with every registered (IETF-tree and global-tree) feature tag. The data resource at this URL would be a copy of the feature registration template. (2) [At the definer's discretion] the URI part of an unregistered feature tag can be used in similar fashion as a URL to retrieve information about the feature. (3) Use a URL to name an aggregate, with the aggregate expression being the referenced resource. (4) Allow a defined form of URN (or a URI that is not a URL) to represent a hash-based aggregate name. The motivation for this, I understand, is to have a uniform approach for dealing with unknown features, and unknown aggregates. I see a number of possible problems here: (a) unless a URL can always be resolved to a machine-interpretable definition, I think there there is marginal value in having a uniform resolution machinery. If the expectation is that an aggregate URL resolves to an interpretable expression, it may be better if simple feature tag URIs are not resolvable, since there is generally no corresponding machine interpretable expression. Also, there is a syntactic difference between usage of feature tags and aggregate names (i.e. auxiliary predicate vs comparison forms), though it might be possible to finesse that in some way. (b) the unregistered feature tag form is defined as using URI syntax, not limited to being a URL. So a mechanism for resolution is not necessarily always present. (c) the "" form in the current feature-hash draft was introduced for a potent reason: to dispel any possible ambiguity concerning the order of substitution and hash value calculation. I think there is a need to draw a clear distinction between simple-valued ("primitive") features and composite-valued aggregates, else undesired complexities or even non-determinism may result. However, I do believe there is value in providing a well-defined mapping to URI form, with URL and resolution available where appropriate. I happen to like the idea of using a URN form, as suggested by Larry, as part of the solution. Currently, I perceive there are a two fixed points to be accommodated if the range of proposed capabilities is to be realized: Feature tags (currently the basis of CONNEG expressions) URLs (currently the only proposed form of directly resolvable identifier) As far as I can tell, you are proposing what is, in effect, a direct mapping from feature tag to URL: Tag --> URL and a corresponding: Aggregate --> URL I would suggest allowing an intermediate URN form that can represent the difference between primitive and aggregate values: Tag --> URN:a:xxx Aggregate --> URN:b:xxx The URNs here would use different URN namespaces, with different resolution properties. As I suggest above, I'm not convinced that feature URNs should be further resolvable (for now, at least; it's possible that we'll devise a useful machine-interpretable form for these in future). OTOH, it will sometimes be useful for aggregate URNs to be resolvable, using ad-hoc or (to-be-)standardized URN resolution mechanisms, possibly on a per-application basis. A possible ad-hoc mechanism might be a simple textual subsitution of the 'URN:namespace' prefix for an 'http://host/path/' form of prefix; for aggregate names that contain URLs, the resolution mechanism may be to simply dereference to URL. In summary, if I understand your proposal correctly, I am proposing adding a level of indirection via URNs to allow evolution of a uniform resolution framework while preserving the essential distinctions between tags and aggregates. I'm not yet sure how to address my point (c) above in this framework, but I suspect that admits a reasonable simple solution. One approach would simply be to say that the hash is always calculated without further substitution, and that dereferenced expressions would not (normally) be permitted to contain further references. I trust I've not grasped _completely_ the wrong end of your proposed. #g -- At 12:21 PM 12/20/99 -0800, hardie@equinix.com wrote: >Over the past few months, the group has struggled with the question of >how to reference aggregations of features; we have discussed most >extensively proposals based on MD5 hashes and based on URIs. During >those discussions, it has been clear that there were different use >cases for which different methods were more appropriate. For very >feature and resource rich environments, URIs have some clear >advantages; for feature and resource limited environments, hashes have >advantages. The obvious solution, support both, has been proposed >several times, but I have pushed back as chair to see if we can't come >to resolution on a single system which works across multiple >environments. After discussion with the document authors and IANA, >my current thought is this: > >Work with IANA to change the form of the feature registry so that >registered features are directly referencable by individual URLs. (The >current registry format is a single text page containing all of the >registered features). This will allow us to reference registered >(unfaceted), global, and unregistered features using URLs, which has >not been possible up to this point. > >Use URLs as the pointers for feature aggregates. As a special type of >reference, allow an object identifier URI based on the MD5 hash of the >canonical representation of the feature tag and value; the canonical >representation for the feature tags will be the URL pointer to the tag >(the value representation will continue to be set during >registration). The MD5 hash URI could either be a unique scheme, >registered according to the recently established URI registration >guidelines, or a data URI (possibly requiring a content type >registration through the MIME processes). > >I believe that this approach gives us a reasonable implementation >path for systems with a variety of resource constraints. > >Please consider this carefully in light of your intended use of >the CONNEG systems, and send comments and criticism to the list. > regards, > Ted Hardie ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-medfree@imc.org Mon Jan 10 13:44:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10263 for ; Mon, 10 Jan 2000 13:44:39 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA11730 for ietf-medfree-bks; Mon, 10 Jan 2000 10:39:52 -0800 (PST) Received: from kiwi.equinix.com (kiwi.equinix.com [207.20.85.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11726 for ; Mon, 10 Jan 2000 10:39:51 -0800 (PST) Received: (from hardie@localhost) by kiwi.equinix.com (8.9.3/8.9.3) id KAA19833; Mon, 10 Jan 2000 10:40:13 -0800 (PST) Message-Id: <200001101840.KAA19833@kiwi.equinix.com> Subject: Re: URI references and aggregation To: GK@Dial.pipex.com (Graham Klyne) Date: Mon, 10 Jan 2000 10:40:13 -0800 (PST) Cc: hardie@equinix.com, ietf-medfree@imc.org, lmm@acm.org In-Reply-To: <4.2.2.20000110145024.00a58120@pop.dial.pipex.com> from "Graham Klyne" at Jan 10, 2000 03:57:34 PM From: hardie@equinix.com Reply-to: hardie@equinix.com X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Graham, Thanks for your long and considered reply; I'll make comments in-line. > Ted, > > I apologize for taking so long to respond to this. If I understand you > correctly, you are proposing that: > > (1) There is an IANA-allocated URL associated (in a well defined fashion) > with every registered (IETF-tree and global-tree) feature tag. The data > resource at this URL would be a copy of the feature registration template. Yes. The advantage of this actually relates primarily to content feature references, as it provides a uniform association of URL and Tag for each of the trees (IETF, global, and URL). While I believe many platforms would easily handle the unfaceted, g., and url forms, there are some limited devices which would benefit from using a single association method. This would provide that association method while retaining the different specification levels. The standard forms would, of course, remain valid. > > (2) [At the definer's discretion] the URI part of an unregistered feature > tag can be used in similar fashion as a URL to retrieve information about > the feature. Unregistered feature tag will have the same pointer type as the above-named URL feature pointers. In practice, anyone using an unregistered feature tag will be using a URL, not a URN, because of the URN requirements for long term referencability. > > (3) Use a URL to name an aggregate, with the aggregate expression being the > referenced resource. Use a URL as a pointer to an aggregate, with the pointed-to-resource possibly containing the aggregate expression; I don't presume that resolution is possible. > (4) Allow a defined form of URN (or a URI that is not a URL) to represent a > hash-based aggregate name. I see this as a pointer in the form of a hash-based identifier; think of it as parallel to the way message-ids are used as cids in Multipart-related. It is not a URN. > > The motivation for this, I understand, is to have a uniform approach for > dealing with unknown features, and unknown aggregates. > > I see a number of possible problems here: > > (a) unless a URL can always be resolved to a machine-interpretable > definition, I think there there is marginal value in having a uniform > resolution machinery. If the expectation is that an aggregate URL resolves > to an interpretable expression, it may be better if simple feature tag URIs > are not resolvable, since there is generally no corresponding machine > interpretable expression. Also, there is a syntactic difference between > usage of feature tags and aggregate names (i.e. auxiliary predicate vs > comparison forms), though it might be possible to finesse that in some way. I think we disagree on the marginal utility of having a single pointer type (I don't actually presume that it will always admit of resolution, but more on that later). I believe that there are an increasing number of cases (set-top boxes, low-capacity devices, etc.) where having a single pointer type will help. I don't think that would affect more capable devices and their ability to use multiple pointer types. The syntactic differences between feature tags and feature aggregates are important, and I don't believe they should be finessed. I believe that the current proposal retains that difference (at the moment the potential confusion is between the URL tree and the aggregate). > > (b) the unregistered feature tag form is defined as using URI syntax, not > limited to being a URL. So a mechanism for resolution is not necessarily > always present. In practice, URIs are currently URLs and URNs. My presumption is that the long-term referencability requirements for URNs make them unlikely choices for unregistered feature tags. > > (c) the "" form in the current feature-hash draft was introduced for a > potent reason: to dispel any possible ambiguity concerning the order of > substitution and hash value calculation. > > I think there is a need to draw a clear distinction between simple-valued > ("primitive") features and composite-valued aggregates, else undesired > complexities or even non-determinism may result. > > However, I do believe there is value in providing a well-defined mapping to > URI form, with URL and resolution available where appropriate. I happen to > like the idea of using a URN form, as suggested by Larry, as part of the > solution. I agree on the need to draw a clear distinction between simple-valued features and composite-valued aggregates; I think the form would work for that. I believe Larry argued that a URN form would work for the IANA-registered features; I don't believe that he argued that it could work for the unregistered feature tags. I assume he'll chime in here, but my presumption is that they won't work for those tags. If you agree that a single pointer type is of benefit, that eliminates substituting URNs for URLs. If you don't agree on that, then we need to work out the basic agreement one way or the other first. > > Currently, I perceive there are a two fixed points to be accommodated if > the range of proposed capabilities is to be realized: > > Feature tags (currently the basis of CONNEG expressions) > URLs (currently the only proposed form of directly resolvable identifier) > > As far as I can tell, you are proposing what is, in effect, a direct > mapping from feature tag to URL: > > Tag --> URL > > and a corresponding: > > Aggregate --> URL Yes and no. I would retain the syntactic difference between the URL pointers to Tags and those pointing to aggregates using both position and markers. I don't propose collapsing them into the same syntax. > > I would suggest allowing an intermediate URN form that can represent the > difference between primitive and aggregate values: > > Tag --> URN:a:xxx > Aggregate --> URN:b:xxx > > The URNs here would use different URN namespaces, with different resolution > properties. As I suggest above, I'm not convinced that feature URNs should > be further resolvable (for now, at least; it's possible that we'll devise > a useful machine-interpretable form for these in future). OTOH, it will > sometimes be useful for aggregate URNs to be resolvable, using ad-hoc or > (to-be-)standardized URN resolution mechanisms, possibly on a > per-application basis. A possible ad-hoc mechanism might be a simple > textual subsitution of the 'URN:namespace' prefix for an > 'http://host/path/' form of prefix; for aggregate names that contain URLs, > the resolution mechanism may be to simply dereference to URL. I'm not convinced that all of the tags can be URNs (the unregistered tags seem to fail the permanence test for at least some cases). I'm also not sure what the advantage is of going to a URN form; it's less recognized and the resolution mechanisms are less clear. Certainly ad-hoc methods like substituion of URN:namesapce for http://host/path/ raise the question: why not just start with "http://host/path/" ? There are three related but seperable issues here: (1)is there a benefit to having a method which can be used to point to tags in any tree? (2)is there a benefit to using the same method in a different syntax to point to feature aggregates, which are predicates rather than simple tags? (3)is there a benefit to using a method which implies a resolution mechanism? I believe the answer to 1 is yes. I'm less sure about 2 and 3 . I am currently leaning toward the idea that if we do 1, the effort required to do 2 and 3 is small and there is at least a potential benefit. > > In summary, if I understand your proposal correctly, I am proposing adding > a level of indirection via URNs to allow evolution of a uniform resolution > framework while preserving the essential distinctions between tags and > aggregates. > > I'm not yet sure how to address my point (c) above in this framework, but I > suspect that admits a reasonable simple solution. One approach would > simply be to say that the hash is always calculated without further > substitution, and that dereferenced expressions would not (normally) be > permitted to contain further references. > > I trust I've not grasped _completely_ the wrong end of your proposed. > > #g And I hope that my comments at least begin to elucidate the original argument; sorry if the first message was less than clear. best regards, Ted Hardie > -- > > > At 12:21 PM 12/20/99 -0800, hardie@equinix.com wrote: > >Over the past few months, the group has struggled with the question of > >how to reference aggregations of features; we have discussed most > >extensively proposals based on MD5 hashes and based on URIs. During > >those discussions, it has been clear that there were different use > >cases for which different methods were more appropriate. For very > >feature and resource rich environments, URIs have some clear > >advantages; for feature and resource limited environments, hashes have > >advantages. The obvious solution, support both, has been proposed > >several times, but I have pushed back as chair to see if we can't come > >to resolution on a single system which works across multiple > >environments. After discussion with the document authors and IANA, > >my current thought is this: > > > >Work with IANA to change the form of the feature registry so that > >registered features are directly referencable by individual URLs. (The > >current registry format is a single text page containing all of the > >registered features). This will allow us to reference registered > >(unfaceted), global, and unregistered features using URLs, which has > >not been possible up to this point. > > > >Use URLs as the pointers for feature aggregates. As a special type of > >reference, allow an object identifier URI based on the MD5 hash of the > >canonical representation of the feature tag and value; the canonical > >representation for the feature tags will be the URL pointer to the tag > >(the value representation will continue to be set during > >registration). The MD5 hash URI could either be a unique scheme, > >registered according to the recently established URI registration > >guidelines, or a data URI (possibly requiring a content type > >registration through the MIME processes). > > > >I believe that this approach gives us a reasonable implementation > >path for systems with a variety of resource constraints. > > > >Please consider this carefully in light of your intended use of > >the CONNEG systems, and send comments and criticism to the list. > > regards, > > Ted Hardie > > ------------ > Graham Klyne > (GK@ACM.ORG) > From owner-ietf-medfree@imc.org Mon Jan 10 19:25:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15509 for ; Mon, 10 Jan 2000 19:25:45 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA16017 for ietf-medfree-bks; Mon, 10 Jan 2000 16:23:25 -0800 (PST) Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16013 for ; Mon, 10 Jan 2000 16:23:23 -0800 (PST) Received: from enoshima (ppp0ppp48.sfc.keio.ac.jp [133.27.13.69]) by sh.w3.mag.keio.ac.jp (8.9.3/3.6W-W3C/Keio) with SMTP id JAA27295; Tue, 11 Jan 2000 09:23:32 +0900 (JST) Message-Id: <200001110023.JAA27295@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3-J (32) Date: Tue, 11 Jan 2000 09:05:53 +0900 To: Graham Klyne From: "Martin J. Duerst" Subject: Re: URI references and aggregation Cc: hardie@equinix.com, ietf-medfree@imc.org In-Reply-To: <4.2.2.20000110145024.00a58120@pop.dial.pipex.com> References: <199912202021.MAA12070@kiwi.equinix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 15:57 00/01/10 +0000, Graham Klyne wrote: > I would suggest allowing an intermediate URN form that can represent the > difference between primitive and aggregate values: > > Tag --> URN:a:xxx > Aggregate --> URN:b:xxx > > The URNs here would use different URN namespaces, with different resolution > properties. As I suggest above, I'm not convinced that feature URNs should > be further resolvable (for now, at least; it's possible that we'll devise > a useful machine-interpretable form for these in future). OTOH, it will > sometimes be useful for aggregate URNs to be resolvable, using ad-hoc or > (to-be-)standardized URN resolution mechanisms, possibly on a > per-application basis. A possible ad-hoc mechanism might be a simple > textual subsitution of the 'URN:namespace' prefix for an > 'http://host/path/' form of prefix; for aggregate names that contain URLs, > the resolution mechanism may be to simply dereference to URL. Just some very short points: - Unsing urn namespaces to solve problems of conneg syntax seems not a good idea. - Restricting each class to a single urn namespace seems a bad idea. - Even if resolvability may not always be possible, and indeed not always necessary, artificially making it difficult by betting on the wide use of URNs and the associated resolver infrastructure is also questionable. Sorry for being dry and straight. I guess Ted's comments went into a similar direction. Regards, Martin. #-#-# Martin J. Du"rst, World Wide Web Consortium #-#-# mailto:duerst@w3.org http://www.w3.org From owner-ietf-medfree@imc.org Tue Jan 11 05:28:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03078 for ; Tue, 11 Jan 2000 05:28:09 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA25512 for ietf-medfree-bks; Tue, 11 Jan 2000 02:18:43 -0800 (PST) Received: from typhoon.mail.pipex.net (typhoon.mail.pipex.net [158.43.128.27]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA25508 for ; Tue, 11 Jan 2000 02:18:41 -0800 (PST) Received: (qmail 21852 invoked from network); 11 Jan 2000 10:19:08 -0000 Received: from userbq82.uk.uudial.com (HELO gk-vaio) (62.188.146.176) by smtp.dial.pipex.com with SMTP; 11 Jan 2000 10:19:08 -0000 Message-Id: <4.2.2.20000110214658.00b48240@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 10 Jan 2000 22:26:40 +0000 To: hardie@equinix.com From: Graham Klyne Subject: Re: URI references and aggregation Cc: conneg WG In-Reply-To: <200001101840.KAA19833@kiwi.equinix.com> References: <4.2.2.20000110145024.00a58120@pop.dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ted, I'm still struggling to fully understand your position here. There seem to be a couple of points that need to be more fully explored: At 10:40 AM 1/10/00 -0800, you wrote: >I think we disagree on the marginal utility of having a single pointer >type (I don't actually presume that it will always admit of >resolution, but more on that later). I believe that there are an >increasing number of cases (set-top boxes, low-capacity devices, etc.) >where having a single pointer type will help. I don't think that >would affect more capable devices and their ability to use multiple >pointer types. It seems to me that a URL (potentially) represents such a wide range of possible pointer types that calling it a "single pointer type" is kind-of strange. I find it difficult to appreciate that allowing URNs and URLs really adds much in the way of complexity. At the end of the day, they're all URIs. > > (b) the unregistered feature tag form is defined as using URI syntax, not > > limited to being a URL. So a mechanism for resolution is not necessarily > > always present. > >In practice, URIs are currently URLs and URNs. My presumption is that >the long-term referencability requirements for URNs make them unlikely >choices for unregistered feature tags. [...] >I'm not convinced that all of the tags can be URNs (the unregistered >tags seem to fail the permanence test for at least some cases). I'm >also not sure what the advantage is of going to a URN form; it's less >recognized and the resolution mechanisms are less clear. Certainly >ad-hoc methods like substituion of URN:namesapce for http://host/path/ >raise the question: why not just start with "http://host/path/" ? OK, I've misunderstood the nature of a URN. I was trying to capture the idea of an identifier that was not bound to a specific resolution protocol, like "mid:..." or "cid:..." [RFC2392]. I had not thought of these as URLs, but on closer examination that's just what they are. I agree that my proposals should not have been so URN-centric. But I still fail to see any real advantage in excluding the use of URNs. I think they effectively amount to just another scheme that a limited system may or may not be able to handle. And other minor questions: > > As far as I can tell, you are proposing what is, in effect, a direct > > mapping from feature tag to URL: > > > > Tag --> URL > > > > and a corresponding: > > > > Aggregate --> URL > >Yes and no. I would retain the syntactic difference between the URL >pointers to Tags and those pointing to aggregates using both position >and markers. I don't propose collapsing them into the same syntax. I'm not sure what you mean here (particularly by "using both position and markers"). > > I trust I've not grasped _completely_ the wrong end of your proposed. > >And I hope that my comments at least begin to elucidate the original argument; >sorry if the first message was less than clear. I think my mental fog is clearing a little ... sorry to be so dense. #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-medfree@imc.org Tue Jan 11 11:02:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13749 for ; Tue, 11 Jan 2000 11:02:13 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA01921 for ietf-medfree-bks; Tue, 11 Jan 2000 07:47:51 -0800 (PST) Received: from typhoon.mail.pipex.net (typhoon.mail.pipex.net [158.43.128.27]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA01916 for ; Tue, 11 Jan 2000 07:47:47 -0800 (PST) Received: (qmail 15766 invoked from network); 11 Jan 2000 15:48:13 -0000 Received: from userbk39.uk.uudial.com (HELO gk-vaio) (62.188.144.47) by smtp.dial.pipex.com with SMTP; 11 Jan 2000 15:48:13 -0000 Message-Id: <4.2.2.20000111104851.00aa32b0@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 11 Jan 2000 10:57:12 +0000 To: "Martin J. Duerst" From: Graham Klyne Subject: Re: URI references and aggregation Cc: ietf-medfree@imc.org In-Reply-To: <200001110023.JAA27295@sh.w3.mag.keio.ac.jp> References: <4.2.2.20000110145024.00a58120@pop.dial.pipex.com> <199912202021.MAA12070@kiwi.equinix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Martin, I'm going to respond to your points here, partly in the hope of provoking a response that improves my understanding. But you may notice from my other response that I had slightly mistaken the division between URNs and URLs, so my proposals are somewhat moot. At 09:05 AM 1/11/00 +0900, Martin J. Duerst wrote: >Just some very short points: > >- Unsing urn namespaces to solve problems of conneg syntax seems > not a good idea. OK -- I see URNs are not enough. But should they be excluded from a solution? >- Restricting each class to a single urn namespace seems a bad > idea. I was coming at this from the point of providing a common URI form associated with registered feature tags, rather than *restriction* of the syntax to specific URN forms. Indeed, it was not my intent that there would be any changes to CONNEG syntax; I was trying to run with Ted's idea of having some degree of uniformity in handling, while maintaining the fundamental distinction between features and aggregates. >- Even if resolvability may not always be possible, and indeed > not always necessary, artificially making it difficult by > betting on the wide use of URNs and the associated resolver > infrastructure is also questionable. Well, yes. I was punting a bit with the idea of ad-hoc mechanisms, but I agree URNs are not needed for that. #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-medfree@imc.org Tue Jan 11 13:38:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18253 for ; Tue, 11 Jan 2000 13:38:05 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA04207 for ietf-medfree-bks; Tue, 11 Jan 2000 10:31:09 -0800 (PST) Received: from kiwi.equinix.com (kiwi.equinix.com [207.20.85.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04203 for ; Tue, 11 Jan 2000 10:31:08 -0800 (PST) Received: (from hardie@localhost) by kiwi.equinix.com (8.9.3/8.9.3) id KAA00380; Tue, 11 Jan 2000 10:31:36 -0800 (PST) Message-Id: <200001111831.KAA00380@kiwi.equinix.com> Subject: Re: URI references and aggregation To: GK@Dial.pipex.com (Graham Klyne) Date: Tue, 11 Jan 2000 10:31:36 -0800 (PST) Cc: hardie@equinix.com, ietf-medfree@imc.org (conneg WG) In-Reply-To: <4.2.2.20000110214658.00b48240@pop.dial.pipex.com> from "Graham Klyne" at Jan 10, 2000 10:26:40 PM From: hardie@equinix.com Reply-to: hardie@equinix.com X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Graham, Thanks for your comments; I'll give replies in-line. Ted > It seems to me that a URL (potentially) represents such a wide range of > possible pointer types that calling it a "single pointer type" is kind-of > strange. I find it difficult to appreciate that allowing URNs and URLs > really adds much in the way of complexity. At the end of the day, they're > all URIs. It's hard to argue against the point that they are all URIs at the end of the day; they certainly are. I also agree that the fairly regular syntax of the URN doesn't add that much complexity. What's driving me in this direction, though, is that we lack a single pointer type for referring to the feature tags. The "unregistered" group can't be referenced by URNs, for the reasons given below; that leaves registering names for everything, which we've agreed isn't appropriate for the "unregistered" group, and providing URL pointers for all of them, which seems fairly easy to accomplish. I actually don't object to the idea of also having URNs, but I don't want it to be at the expense of having URL pointers to the registered and global tags. It may well be that the URN pointers would come into wider or dominant use when URNs in general are more widely available. Having selected URLs as the "uniform" pointer type for the feature tags, there seem to be some good reasons to keep on that track for the aggregates (which again can't be URNs). I do think there will be a fair amount of complexity in this system, as multiple URL schemes will be used in the pointers. I don't think that complexity extends into the need to provide resolution mechanisms for all of the possible URL schemes. The ability to dereference these shouldn't be a pre-requisite for this model to succeed. > > > > (b) the unregistered feature tag form is defined as using URI syntax, not > > > limited to being a URL. So a mechanism for resolution is not necessarily > > > always present. > > > >In practice, URIs are currently URLs and URNs. My presumption is that > >the long-term referencability requirements for URNs make them unlikely > >choices for unregistered feature tags. > > [...] > > >I'm not convinced that all of the tags can be URNs (the unregistered > >tags seem to fail the permanence test for at least some cases). I'm > >also not sure what the advantage is of going to a URN form; it's less > >recognized and the resolution mechanisms are less clear. Certainly > >ad-hoc methods like substituion of URN:namesapce for http://host/path/ > >raise the question: why not just start with "http://host/path/" ? > > OK, I've misunderstood the nature of a URN. I was trying to capture the > idea of an identifier that was not bound to a specific resolution protocol, > like "mid:..." or "cid:..." [RFC2392]. I had not thought of these as URLs, > but on closer examination that's just what they are. This is exactly the kind of identifier that I had in mind for the hashes; it's not bound to a particular resolution protocol, but can be used reliably as a unique key into a index of known aggregates. I think these are likely to be used most commonly when there is a fairly limited set of possible values. Some of the fax folk have discussed it as a way of short-cutting the negotiation process, and I believe it would also be useful in some of the limited capacity wireless devices. > > I agree that my proposals should not have been so URN-centric. > > But I still fail to see any real advantage in excluding the use of URNs. I > think they effectively > amount to just another scheme that a limited system may or may not be able > to handle. > > > > And other minor questions: > > > > As far as I can tell, you are proposing what is, in effect, a direct > > > mapping from feature tag to URL: > > > > > > Tag --> URL > > > > > > and a corresponding: > > > > > > Aggregate --> URL > > > >Yes and no. I would retain the syntactic difference between the URL > >pointers to Tags and those pointing to aggregates using both position > >and markers. I don't propose collapsing them into the same syntax. > > I'm not sure what you mean here (particularly by "using both position and > markers"). Probably freshman linguistics haunting me (positional v. inflected grammars); I meant that I would not collapse the URL pointers for aggregates into the u. faceted form for feature tags, either by overloading that facet or by forcing them to be usable in the same places in the grammar. As you have noted several times, they are different--one represents a feature and one represents a predicate. Thanks again for your continued patience with my poor attempts at making this clear, regards, Ted From owner-ietf-medfree@imc.org Tue Jan 11 22:37:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26632 for ; Tue, 11 Jan 2000 22:37:10 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA18564 for ietf-medfree-bks; Tue, 11 Jan 2000 19:34:29 -0800 (PST) Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA18557 for ; Tue, 11 Jan 2000 19:34:27 -0800 (PST) Received: from enoshima (dhcp-100-224.mag.keio.ac.jp [133.27.195.224]) by sh.w3.mag.keio.ac.jp (8.9.3/3.6W-W3C/Keio) with SMTP id MAA04587; Wed, 12 Jan 2000 12:34:42 +0900 (JST) Message-Id: <200001120334.MAA04587@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3-J (32) Date: Wed, 12 Jan 2000 10:10:03 +0900 To: Graham Klyne From: "Martin J. Duerst" Subject: Re: URI references and aggregation Cc: ietf-medfree@imc.org In-Reply-To: <4.2.2.20000111104851.00aa32b0@pop.dial.pipex.com> References: <200001110023.JAA27295@sh.w3.mag.keio.ac.jp> <4.2.2.20000110145024.00a58120@pop.dial.pipex.com> <199912202021.MAA12070@kiwi.equinix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:57 00/01/11 +0000, Graham Klyne wrote: > Martin, > > I'm going to respond to your points here, partly in the hope of provoking a > response that improves my understanding. But you may notice from my other > response that I had slightly mistaken the division between URNs and URLs, > so my proposals are somewhat moot. > > At 09:05 AM 1/11/00 +0900, Martin J. Duerst wrote: > >Just some very short points: > > > >- Unsing urn namespaces to solve problems of conneg syntax seems > > not a good idea. > > OK -- I see URNs are not enough. But should they be excluded from a solution? Not at all. Say URI, reference RFC 2396, and they are included. > >- Restricting each class to a single urn namespace seems a bad > > idea. > > I was coming at this from the point of providing a common URI form > associated with registered feature tags, rather than *restriction* of the > syntax to specific URN forms. Indeed, it was not my intent that there > would be any changes to CONNEG syntax; I was trying to run with Ted's idea > of having some degree of uniformity in handling, while maintaining the > fundamental distinction between features and aggregates. It might be a good idea to use URNs for IANA-registered features at a time we have more experience and implementation of URNs, and in that case, it may even be a good idea to have a single prefix for these and only for these (because they represent something different e.g. from books, for which you would have isbns). But trying to cover user-defined (non-registered) features in the same namespace would involve a rather complicated infrastructure, most probably too much for what you get. Also, as long as the simplest examples of urn namespaces, the ones for rfcs and internet-drafts, don't work out of the box for major browsers, I'm not sure we should bother IANA with more of them. Regards, Martin. #-#-# Martin J. Du"rst, World Wide Web Consortium #-#-# mailto:duerst@w3.org http://www.w3.org From owner-ietf-medfree@imc.org Thu Jan 13 16:16:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25299 for ; Thu, 13 Jan 2000 16:16:09 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA27980 for ietf-medfree-bks; Thu, 13 Jan 2000 12:59:58 -0800 (PST) Received: from kiwi.equinix.com (kiwi.equinix.com [207.20.85.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA27976 for ; Thu, 13 Jan 2000 12:59:57 -0800 (PST) Received: (from hardie@localhost) by kiwi.equinix.com (8.9.3/8.9.3) id NAA24279 for ietf-medfree@imc.org; Thu, 13 Jan 2000 13:00:38 -0800 (PST) Message-Id: <200001132100.NAA24279@kiwi.equinix.com> Subject: Adelaide meeting To: ietf-medfree@imc.org Date: Thu, 13 Jan 2000 13:00:38 -0800 (PST) From: hardie@equinix.com Reply-to: hardie@equinix.com X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Scheduling is now open for the Adelaide meeting, but before scheduling a formal meeting for CONNEG, I want to get a sense of how many active working group members will be attending this meeting. I you plan to attend the 47th IETF in Adelaide from March 26th through 31st of 2000, please send me email, so I can get a sense of the group. thanks, Ted Hardie hardie@equinix.com From owner-ietf-medfree@imc.org Fri Jan 14 10:17:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18239 for ; Fri, 14 Jan 2000 10:17:14 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA29318 for ietf-medfree-bks; Fri, 14 Jan 2000 06:28:31 -0800 (PST) Received: from cybergateway.net ([206.104.28.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA29253; Fri, 14 Jan 2000 06:21:32 -0800 (PST) From: becky2421@aol.com Received: from 206.104.28.14 [152.172.118.203] by cybergateway.net (SMTPD32-5.01) id A4879CD01FE; Fri, 14 Jan 2000 08:55:35 +0100 Received: from jason@gulfcoast.net by jason@gulfcoast.net (8.8.5/8.6.5) with SMTP id GAA07984 for < jason@gulfcoast.net>; Fri, 14 Jan 2000 07:38:29 -0600 (EST) Date: Fri, 14 Jan 00 07:38:29 EST To: jason@gulfcoast.net Subject: New USA and International Merchant Accounts Message-ID: <> Reply-To: jason@gulfcoast.net Comments: Authenticated sender is < jason@gulfcoast.net> Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW U.S.A. and INTERNATIONAL MERCHANT ACCOUNTS FOR THE WORLD. Click below to Apply http://hypermart.com@3462929566/%63ar%64%73%65%72%76%69%63%65/%64%65%66%61u%6C%74%2Eh%74%6D#@3626198025/%63%61%72d%73%65%72%76%69%63%65/d%65fa%75%6C%74%2E%68%74%6D#@3462929566/ca%72d%73%65%72%76%69%63%65%32/%69%6E%64%65%78%2E%68%74%6D@3491382728/%63a%72d%73e%72%76%69%63%65/%64e%66%61%75%6C%74%2E%68t%6D ARE YOU REALLY AN E-COMMERCE MERCHANT? Increase your revenues by up to 1500% by accepting credit cards and electronic checks. Increase your customer base 200- 400% with instant access to the World. ARE YOU PAYING TOO MUCH? Discount rates start at 2.1% Transaction fees start at 25 cents. DO YOU WAIT TOO LONG FOR YOUR MONEY? Funds available in 24-48 hours anywhere in the world DO YOU HAVE DIFFICULTY GETTING MERCHANT ACCOUNTS 99% of all applications are approved. ARE YOU LIMITED BY WHAT YOU CAN ACCEPT? Mastercard, Visa, Discover, Amex and Checks (USA checks only) All cards from ALL COUNTRIES - Including Eastern Europe and Asia - - - - - - - - - - - Click HERE to APPLY. http://hypermart.com@3462929566/%63ar%64%73%65%72%76%69%63%65/%64%65%66%61u%6C%74%2Eh%74%6D#@3626198025/%63%61%72d%73%65%72%76%69%63%65/d%65fa%75%6C%74%2E%68%74%6D#@3462929566/ca%72d%73%65%72%76%69%63%65%32/%69%6E%64%65%78%2E%68%74%6D@3491382728/%63a%72d%73e%72%76%69%63%65/%64e%66%61%75%6C%74%2E%68t%6D - NOTE: THIS IS NOT AN APPLICATION FOR A PERSONAL CREDIT CARD BUT FOR A MERCHANT ACCOUNT. - - - - - - - - - - - To be removed from our mailing list, call (888) 341-4786 Clearly spell your email address and you will be removed. 111 1 111 T From owner-ietf-medfree@imc.org Mon Jan 17 14:54:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07680 for ; Mon, 17 Jan 2000 14:53:59 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA12791 for ietf-medfree-bks; Mon, 17 Jan 2000 11:36:52 -0800 (PST) Received: from brainstem.idcomm.com (root@brainstem.idcomm.com [207.40.196.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA12787 for ; Mon, 17 Jan 2000 11:36:51 -0800 (PST) Received: from ego.idcomm.com (ego.idcomm.com [207.40.196.10]) by brainstem.idcomm.com (8.9.3/8.9.3) with ESMTP id MAA15487 for ; Mon, 17 Jan 2000 12:37:49 -0700 Received: from bmp ([209.60.72.197]) by ego.idcomm.com (post.office MTA v2.0 0813 ID# 0-13674) with SMTP id AAD235 for ; Mon, 17 Jan 2000 12:42:48 -0700 From: Marketing Flash To: Date: Mon, 17 Jan 2000 12:40:54 -0700 Subject: Owner/Manager - National ISP Survey Reply-To: info2@marketingflash.com Organization: Marketing Flash MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001_11288169_45654.72_11333823.71875" Content-Transfer-Encoding: 7bit X-Priority: 3 Message-ID: <20000117194243650.AAD235@bmp> Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a Multipart MIME message. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPart_000_001_11288169_45654.72_11333823.71875 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit National ISP Survey
ISPs in the US generated approximately
$15.1 billion in revenues in 1999.

Did your company grow at least 30% in 1999? Was your Customer Retention at least 90%? Did you know that it takes five times as much money to acquire a new customer as it does to retain one?

Business Marketplace®, LLC, a marketing consulting and design firm in Denver, Colorado, is conducting a brief National ISP survey, regarding how ISPs around the country are finding new customers, what marketing activities are being used for Customer Retention — and how successful they have been. This information is being gathered to determine how our ISP clients compare to the national average. You have been selected to participate in this survey.

Results of this survey will be provided to you to assist you in your marketing efforts. We appreciate your clicking below to the brief survey, which will take approximately one minute to complete. Completed surveys submitted by January 21, 2000 will be analyzed, with the results made available to all respondents by January 25, 2000.

If you have any questions, please do not hesitate to either e-mail us at the address above, or call us at (303) 778-7571 or toll-free at (877) 674-2374, Monday through Friday, 9am to 5pm, mountain standard time. Thank you, in advance, for your participation — now just click here for the survey!

Deb Hastings, President
Business Marketplace®, LLC
888 S. Sherman St.
Denver, CO 80209
www.businessmarketplace.com

If appropriate, we would appreciate your forwarding this to the
Owner, President or General Manager of your organization.


------=_NextPart_000_001_11288169_45654.72_11333823.71875-- From owner-ietf-medfree@imc.org Tue Jan 18 22:49:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11000 for ; Tue, 18 Jan 2000 22:49:51 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA09227 for ietf-medfree-bks; Tue, 18 Jan 2000 19:43:59 -0800 (PST) Received: from oh1 (www.openhere.com [165.254.210.60]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA09221 for ; Tue, 18 Jan 2000 19:43:57 -0800 (PST) From: Sara@openhere.com Received: from CC89180-A.trntn1.nj.home.com ([24.9.93.28]) by oh1 (Mail-Gear 1.1.1) with SMTP id M2000011823185014298 for ; Tue, 18 Jan 2000 23:18:50 -0500 To: ietf-medfree@imc.org Date: Tue, 18 Jan 2000 22:43:52 -0500 Subject: Your site has been included on OpenHere Message-Id: Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, Your site has been included in the OpenHere.com index and search engine. OpenHere is one of the 10 largest index and search sites on the Internet. Your site listing is: Link: http://www.w3.org/Protocols/ Title: HTTP - Hypertext Transfer Protocol Description: You might have already received a message similar to this one, as we send a note when ever we add a link to your site in a different category on OpenHere.com. At OpenHere you can dynamically modify your site's listing at any time. You can also include your site's listing in other categories on OpenHere.com. When you modify your site's listing, it is automatically placed at the top of the category in which it is included, and is placed first in the search engine results for the keywords relating to your site. To modify, add or delete your listing: 1. Go to the page on OpenHere where your site is presently listed or you would like it listed. 2. Select "Suggest a Site". 3. Follow the instructions for changing your listing. All of the modifications you submit to OpenHere.com are processed in real time. As soon as you see the response to your submission, your site listing should be updated. www.OpenHere.com is frequented by both children and families. As a result, www.OpenHere.com does not include links to material which is illegal to display to minors. Sara www.OpenHere.com Your key to the Net! From owner-ietf-medfree@imc.org Wed Jan 19 07:00:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26129 for ; Wed, 19 Jan 2000 07:00:25 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA04266 for ietf-medfree-bks; Wed, 19 Jan 2000 03:56:35 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA04262 for ; Wed, 19 Jan 2000 03:56:33 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26075; Wed, 19 Jan 2000 06:57:42 -0500 (EST) Message-Id: <200001191157.GAA26075@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-medfree@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-klyne-conneg-w3c-ccpp-00.txt Date: Wed, 19 Jan 2000 06:57:41 -0500 Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : W3C Composite Capability/Preference Profiles Author(s) : G. Klyne Filename : draft-klyne-conneg-w3c-ccpp-00.txt Pages : 24 Date : 14-Jan-00 This document suggests some possible areas for extending the IETF 'conneg' working group's capability description framework, described in [2,3,4]. The suggested areas for extension have been motivated by WWW Consortium (W3C) work on Composite Capability/Preference Profiles (CCPP) [5] that parallels some aspects of the IETF 'conneg' work. This is presented as a discussion document, with a view to maybe integrating some of these ideas into ongoing 'conneg' work, and to indicate some areas for ongoing collaboration between the IETF and W3C in the area of content description. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-klyne-conneg-w3c-ccpp-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-klyne-conneg-w3c-ccpp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-klyne-conneg-w3c-ccpp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000114084007.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-klyne-conneg-w3c-ccpp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-klyne-conneg-w3c-ccpp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000114084007.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-medfree@imc.org Fri Jan 21 03:34:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05252 for ; Fri, 21 Jan 2000 03:34:33 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA21165 for ietf-medfree-bks; Fri, 21 Jan 2000 00:29:39 -0800 (PST) Received: from oh1 (www.openhere.com [165.254.210.60]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA21160 for ; Fri, 21 Jan 2000 00:29:37 -0800 (PST) From: Sara@openhere.com Received: from CC89180-A.trntn1.nj.home.com ([24.9.93.28]) by oh1 (Mail-Gear 1.1.1) with SMTP id M2000012104045926470 for ; Fri, 21 Jan 2000 04:04:59 -0500 To: ietf-medfree@imc.org Date: Fri, 21 Jan 2000 03:29:41 -0500 Subject: Your site has been included on OpenHere Message-Id: Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, Your site has been included in the OpenHere.com index and search engine. OpenHere is one of the 10 largest index and search sites on the Internet. Your site listing is: Link: http://www.w3.org/Protocols/ Title: W3C Hypertext Transfer Protocol Overview Description: You might have already received a message similar to this one, as we send a note when ever we add a link to your site in a different category on OpenHere.com. At OpenHere you can dynamically modify your site's listing at any time. You can also include your site's listing in other categories on OpenHere.com. When you modify your site's listing, it is automatically placed at the top of the category in which it is included, and is placed first in the search engine results for the keywords relating to your site. To modify, add or delete your listing: 1. Go to the page on OpenHere where your site is presently listed or you would like it listed. 2. Select "Suggest a Site". 3. Follow the instructions for changing your listing. All of the modifications you submit to OpenHere.com are processed in real time. As soon as you see the response to your submission, your site listing should be updated. www.OpenHere.com is frequented by both children and families. As a result, www.OpenHere.com does not include links to material which is illegal to display to minors. Sara www.OpenHere.com Your key to the Net! From owner-ietf-medfree@imc.org Sat Jan 29 17:32:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23913 for ; Sat, 29 Jan 2000 17:32:03 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA20296 for ietf-medfree-bks; Sat, 29 Jan 2000 14:23:57 -0800 (PST) Received: from Nina (ppp41-mulhouse.libertysurf.fr [213.36.41.41]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA20292 for ; Sat, 29 Jan 2000 14:23:47 -0800 (PST) Date: Sat, 29 Jan 2000 14:23:47 -0800 (PST) From: EZ To: Message-Id: <419.436554.98030301freemp3@altavista.com> Subject: EZ Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Je suis Ez ...(musique libre :-) Mon nouvel album est là: http://www.angelfire.com/music/ez/ et il est gratuit, plein de MP3 à télécharger et de REAL à écouter. Passez me voir ! Ez Ez - makes dreams come true - MUSIC & FREE MP3 http://www.angelfire.com/music/ez/ Enjoy Ez – born on the www - If this message has reached you by mistake please accept our apologies To be removed from our database please return this message with REMOVE in the subject box. ThanX. From owner-ietf-medfree@imc.org Mon Jan 31 08:44:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03151 for ; Mon, 31 Jan 2000 08:44:48 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA11067 for ietf-medfree-bks; Mon, 31 Jan 2000 05:39:57 -0800 (PST) Received: from webserver.gloclub2.net ([206.104.28.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10920; Mon, 31 Jan 2000 05:25:41 -0800 (PST) Received: from 206.104.28.4 [171.211.231.234] by webserver.gloclub2.net (SMTPD32-5.01) id A9C267E01C6; Sun, 30 Jan 2000 23:12:34 CST Received: from qr89503@hotmail.com by qr89503@hotmail.com (8.8.5/8.6.5) with SMTP id GAA04152 for ; Sun, 30 Jan 2000 21:54:09 -0600 (EST) Date: Sun, 30 Jan 00 21:54:09 EST From: qr89503@hotmail.com To: qr89503@hotmail.com Subject: New USA and INTERNATIONAL Merchant Accounts Message-ID: <> Reply-To: qr89503@hotmail.com Comments: Authenticated sender is Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW U.S.A. and INTERNATIONAL MERCHANT ACCOUNTS FOR THE WORLD. Click below to Apply http://angelfire.com@3462929566/%74%68%65%73%65%72%76%69%63%65%34%38/%64%65%66%61%75%6C%74.%68%74m#@3626198025/%74%68%65%73%65%72%76%69c%65%348/de%66a%75l%74.%68%74%6D ARE YOU REALLY AN E-COMMERCE MERCHANT? Increase your revenues by up to 1500% by accepting credit cards and electronic checks. Increase your customer base 200- 400% with instant access to the World. ARE YOU PAYING TOO MUCH? Discount rates start at 2.1% Transaction fees start at 25 cents. DO YOU WAIT TOO LONG FOR YOUR MONEY? Funds available in 24-48 hours anywhere in the world DO YOU HAVE DIFFICULTY GETTING MERCHANT ACCOUNTS 99% of all applications are approved. ARE YOU LIMITED BY WHAT YOU CAN ACCEPT? Mastercard, Visa, Discover, Amex and Checks (USA checks only) All cards from ALL COUNTRIES - Including Eastern Europe and Asia - - - - - - - - - - - Click HERE to APPLY. http://angelfire.com@3462929566/%74%68%65%73%65%72%76%69%63%65%34%38/%64%65%66%61%75%6C%74.%68%74m#@3626198025/%74%68%65%73%65%72%76%69c%65%348/de%66a%75l%74.%68%74%6D NOTE: THIS IS NOT AN APPLICATION FOR A PERSONAL CREDIT CARD BUT FOR A MERCHANT ACCOUNT. - - - - - - - - - - - To be removed from our mailing list, call (888) 341-4786 Clearly spell your email address and you will be removed. *** From owner-ietf-medfree@imc.org Mon Jan 31 08:44:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03162 for ; Mon, 31 Jan 2000 08:44:49 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA11073 for ietf-medfree-bks; Mon, 31 Jan 2000 05:40:07 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA11069 for ; Mon, 31 Jan 2000 05:40:06 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03131; Mon, 31 Jan 2000 08:42:13 -0500 (EST) Message-Id: <200001311342.IAA03131@ietf.org> To: IETF-Announce: ; Cc: ietf-medfree@imc.org From: The IESG SUBJECT: Last Call: Indicating media features for MIME content to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 31 Jan 2000 08:42:13 -0500 Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the Content Negotiation (conneg) Working Group to consider the following Internet-Drafts as Proposed Standards: o Indicating media features for MIME content o MIME content types in media feature expressions The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by February 14, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-conneg-content-features-02.txt http://www.ietf.org/internet-drafts/draft-ietf-conneg-feature-type-02.txt From owner-ietf-medfree@imc.org Mon Jan 31 09:55:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05454 for ; Mon, 31 Jan 2000 09:55:38 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA12604 for ietf-medfree-bks; Mon, 31 Jan 2000 06:51:35 -0800 (PST) Received: from webserver.gloclub2.net ([206.104.28.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA12550; Mon, 31 Jan 2000 06:49:00 -0800 (PST) Date: Mon, 31 Jan 2000 06:49:00 -0800 (PST) From: qr89503@hotmail.com Message-Id: <200001311449.GAA12550@ns.secondary.com> Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: