From owner-ietf-medfree Wed Feb 18 12:49:07 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA17160 for ietf-medfree-bks; Wed, 18 Feb 1998 12:49:07 -0800 (PST) Received: from HQ.Cisco.COM (hq.cisco.com [171.71.67.16]) by mail.proper.com (8.8.5/8.7.3) with SMTP id MAA17156 for ; Wed, 18 Feb 1998 12:49:03 -0800 (PST) Received: by HQ.Cisco.COM; Wed, 18 Feb 1998 12:46:31 -0800 Date: Wed, 18 Feb 1998 12:46:31 -0800 From: Dan Wing To: hardie@nic.nasa.gov CC: IETF-CONNEG@imc.org Message-Id: <980218124631.20270456@Cisco.COM> Subject: RE: ietf-medfree mailing list Sender: owner-ietf-medfree@imc.org Precedence: bulk It is unfortunate that the IETF name for the WG has remained CONNEG and the mailing list (and web site) changed its name to MEDFREE, though. -d From owner-ietf-medfree Wed Feb 18 15:12:09 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA18112 for ietf-medfree-bks; Wed, 18 Feb 1998 15:12:09 -0800 (PST) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.5/8.7.3) with SMTP id PAA18105 for ; Wed, 18 Feb 1998 15:12:04 -0800 (PST) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA11183 for ietf-medfree@imc.org; Wed, 18 Feb 1998 15:10:33 -0800 Date: Wed, 18 Feb 1998 15:10:33 -0800 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9802181510.ZM11181@thornhill.arc.nasa.gov> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: ietf-medfree@imc.org Subject: Charter, timeline, and goals Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk Welcome to the ietf-medfree mailing list. If you were previously on the "conneg" mailing list, you have been moved over automatically; if that is not what you want, please send a message to ietf-medfree-request@imc.org with "unsubscribe" in the body of the message. I want to thank everyone for the participation in the "conneg" lists to date, and I encourage those just joining the discussion to read the archives of the exchanges so far. As most of you have seen, the IESG has chartered this working group within the Applications area of the IETF. The official charter is at http://www.ietf.org/html.charters/conneg-charter.html Yes, the working group is named conneg and the mailing lists are medfree. I know it's confusing, but let's not waste any energy on it. The key thing is that the charter has a *very* aggressive timeline, and we are going to have to work very hard to meet it. The first item on our list is the registration document. The current draft of that is draft-ietf-http-feature-reg-03.txt available at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-http-feature-reg-03.txt Among the key elements we need to consider before a last call are: If we are incorporating some features by reference to other registries, (such as the Printer MIB) how are those features referenced and incorporated into the registry? Can we eliminate one or more of these trees? In particular, do we really need both a URL tree and a local tree? Given the horrid problems with transitioning between x- "regular" MIME types, should we also get rid of the x. tree? I strongly suspect we need to simplify here to make the registry easy to use. What can we cut, collapse, or combine? In the current registration draft, we say: "In general, the new registration proposal is circulated and reviewed in a fashion appropriate to the tree involved." I believe we need to be a lot more specific about this. If we expect these to be mailing lists, we need to have names for them, a description of how they are constituted, and how things move from "under consideration" to "decided". We're really going to need to focus on the registry issues for the next few weeks to get drafts edited before the L.A. IETF, so please review those drafts and hold other issues accept as they relate to the registry. I encourage folks who have not read the MIME registration procedures recently (RFC 2048) to do so, and I'd also suggest taking a look at the schema listing drafts as examples of how other groups are tackling similar problems. The URLs for the two main drafts there are: ftp://ftp.ietf.org/internet-drafts/draft-ietf-schema-proc-list-00.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-schema-rqmts-list-00.txt Comments welcome, and draft text greatly appreciated, regards, Ted Hardie NASA NIC From owner-ietf-medfree Thu Feb 19 05:26:20 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id FAA25347 for ietf-medfree-bks; Thu, 19 Feb 1998 05:26:20 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.5/8.7.3) with SMTP id FAA25343 for ; Thu, 19 Feb 1998 05:26:16 -0800 (PST) Received: (qmail 2458 invoked from network); 19 Feb 1998 13:24:42 -0000 Received: from ad073.du.pipex.com (HELO sttnb) (193.130.243.73) by smtp.dial.pipex.com with SMTP; 19 Feb 1998 13:24:42 -0000 Message-Id: <3.0.32.19980218171538.00883100@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 19 Feb 1998 13:23:40 +0000 To: ietf-conneg@imc.org From: Graham Klyne Subject: Now we are (med)free Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk Just a quick test and a question, Now we have an official MedFree working group and mailing list, will signups to the old mailing list be automatically transferred? GK. --- ------------ Graham Klyne From owner-ietf-medfree Thu Feb 19 09:54:36 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA27069 for ietf-medfree-bks; Thu, 19 Feb 1998 09:54:36 -0800 (PST) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.5/8.7.3) with SMTP id JAA27065 for ; Thu, 19 Feb 1998 09:54:30 -0800 (PST) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA12030; Thu, 19 Feb 1998 09:52:56 -0800 Date: Thu, 19 Feb 1998 09:52:56 -0800 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9802190952.ZM12028@thornhill.arc.nasa.gov> In-Reply-To: Graham Klyne "Now we are (med)free" (Feb 19, 1:23pm) References: <3.0.32.19980218171538.00883100@pop.dial.pipex.com> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: Graham Klyne , ietf-conneg@imc.org Subject: Re: Now we are (med)free Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk Yes. If you are on the conneg mailing list, you are on the med-free mailing list. regards, Ted Hardie On Feb 19, 1:23pm, Graham Klyne wrote: > Subject: Now we are (med)free > Just a quick test and a question, > > Now we have an official MedFree working group and mailing list, will > signups to the old mailing list be automatically transferred? > > GK. > --- > > ------------ > Graham Klyne >-- End of excerpt from Graham Klyne From owner-ietf-medfree Thu Feb 26 13:23:48 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA20229 for ietf-medfree-bks; Thu, 26 Feb 1998 13:23:48 -0800 (PST) Received: from wsooti04.win.tue.nl (wsooti04.win.tue.nl [131.155.70.122]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA20224 for ; Thu, 26 Feb 1998 13:23:42 -0800 (PST) Received: from koen@localhost by wsooti04.win.tue.nl (8.8.7) id WAA15409. Thu, 26 Feb 1998 22:22:24 +0100 (MET) From: koen@win.tue.nl (Koen Holtman) Message-Id: <199802262122.WAA15409@wsooti04.win.tue.nl> Subject: Comments on registration draft To: hardie@nic.nasa.gov Date: Thu, 26 Feb 1998 22:22:23 +0100 (MET) Cc: ietf-medfree@imc.org In-Reply-To: <9802181510.ZM11181@thornhill.arc.nasa.gov> from "Ted Hardie" at Feb 18, 98 03:10:33 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ietf-medfree@imc.org Precedence: bulk Ted Hardie: > > >The first item on our list is the registration document. The current >draft of that is draft-ietf-http-feature-reg-03.txt available at: > >ftp://ftp.ietf.org/internet-drafts/draft-ietf-http-feature-reg-03.txt > >Among the key elements we need to consider before a last call are: > >If we are incorporating some features by reference to other >registries, (such as the Printer MIB) how are those features >referenced and incorporated into the registry? Presumably, the filled-in feature tag registration template which sits in the registry would contain a reference to the printer MIB registry. This would work fine if the printer MIB registry is used to register values of the tag. Now, in a scenario where you want to have a feature tag pop up `automatically' in the feature tag registry whenever something gets added to the printer MIB registry, we may have a problem. I don't know if you would actually ever want such a thing: could you give an example? I think that case could be handled by a special `feature tag prefix' registration template, in which one could define the meaning of all tags starting with `w.printer-MIB.' by pointing to an external registry, or something. >Can we eliminate one or more of these trees? In particular, do we >really need both a URL tree and a local tree? I suspect we need both URL and local; not everybody has the ability to allocate short URLs, and in some negotiation situations a short tag may be vital for efficiency reasons, or imagined efficiency reasons which turn into a political reasons. Given the horrid >problems with transitioning between x- "regular" MIME types, should >we also get rid of the x. tree? I think the horrid problems with the x- mime types were mainly caused by the old mime registry rules being too closed. So I won't expect the same problems with the x. tree. However, I would not mind that much if the x. tree is eliminated. > I strongly suspect we need to >simplify here to make the registry easy to use. What can we cut, >collapse, or combine? I think that having 5 trees (ietf, global, local, URL, experimental) is not overly complex, especially because the registry itself would only ever contain ietf, global, and local tags. >In the current registration draft, we say: "In general, the new >registration proposal is circulated and reviewed in a fashion >appropriate to the tree involved." I believe we need to be a lot >more specific about this. I am confused. In revising the draft from 02 to 03, you cut out most of the material (sections 3.2 and 3.3 of the 02 draft) which describes the specifics. Did you change your views after you released the 03 draft? Anyway, I agree that the 03 draft needs to be more specific, and my proposal for specifics is the text in the 02 draft (html version at http://gewis.win.tue.nl/~koen/conneg/draft-ietf-http-feature-reg-02.html). The specific text in 02 is a bit opaque though, and could be re-structured to be more clear. > If we expect these to be mailing lists, we >need to have names for them, a description of how they are >constituted, and how things move from "under consideration" to >"decided". According to the 02 draft (though it does not explicitly state this), tags in the global and local trees move to `decided' when the tag author decides to submit the completed tag template to IANA and IANA decides that the tag is not obviously broken or bogus. The mailing lists are for advisory discussions only and play no formal role in the decision process. This is still my view on how it should work. [...] >ftp://ftp.ietf.org/internet-drafts/draft-ietf-schema-proc-list-00.txt I have yet to do a careful read-through of this draft, but I could not find how the `list moderator' is appointed, and what appeal procedures against decisions of the moderator there are, and this worries me. >From my own inability to answer these questions for feature tags, I have concluded that it is better to have an advisory list only. Some other comments on the 03 registration draft: - I see that the `Basic concepts and definitions' material from the 02 draft was cut. I think this is a bad thing, because it means that what follows is less comprehensible. An introduction into tag values is _definitely_ needed to make the template later on comprehensible. - section 3.1.4 in the index is about the `Special `x.' tree', but the actual text of this section has disappeared. It needs to be added again. - the specification of the URL tree should define a) an unambiguous way of determining that a string used as a feature tag is in the URL tree b) the comparison function for tags in the URL tree (I propose case-insensitive octet-by-octet, without % decoding) Koen. From owner-ietf-medfree Thu Feb 26 22:13:25 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id WAA24536 for ietf-medfree-bks; Thu, 26 Feb 1998 22:13:25 -0800 (PST) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.5/8.7.3) with SMTP id WAA24532 for ; Thu, 26 Feb 1998 22:13:20 -0800 (PST) Received: from casablanca.parc.xerox.com ([13.2.16.111]) by alpha.xerox.com with SMTP id <51936(3)>; Thu, 26 Feb 1998 22:12:18 PST Received: from bronze-208.parc.xerox.com ([13.0.211.227]) by casablanca.parc.xerox.com with SMTP id <71813>; Thu, 26 Feb 1998 22:12:04 PST Message-ID: <006901bd4346$9ce0ecc0$e3d3000d@bronze-208.parc.xerox.com> From: "Larry Masinter" To: "Koen Holtman" , Cc: Subject: Re: Comments on registration draft Date: Thu, 26 Feb 1998 22:11:59 PST MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-medfree@imc.org Precedence: bulk >>If we are incorporating some features by reference to other >>registries, (such as the Printer MIB) how are those features >>referenced and incorporated into the registry? > >Presumably, the filled-in feature tag registration template which sits >in the registry would contain a reference to the printer MIB >registry. This would work fine if the printer MIB registry is used to >register values of the tag. > >Now, in a scenario where you want to have a feature tag pop up >`automatically' in the feature tag registry whenever something gets >added to the printer MIB registry, we may have a problem. I don't >know if you would actually ever want such a thing: could you give an >example? I think that case could be handled by a special `feature tag >prefix' registration template, in which one could define the meaning >of all tags starting with `w.printer-MIB.' by pointing to an external >registry, or something. Unless there's a more compelling reason, let's not. >>Can we eliminate one or more of these trees? In particular, do we >>really need both a URL tree and a local tree?=20 > >I suspect we need both URL and local; not everybody has the ability to >allocate short URLs, and in some negotiation situations a short tag >may be vital for efficiency reasons, or imagined efficiency reasons >which turn into a political reasons. ditto. Unless there's a compelling reason for having a 'local' tree, = let's leave it out. > Given the horrid >>problems with transitioning between x- "regular" MIME types, should >>we also get rid of the x. tree? > >I think the horrid problems with the x- mime types were mainly caused >by the old mime registry rules being too closed. So I won't expect >the same problems with the x. tree. However, I would not mind that >much if the x. tree is eliminated. Given the URL tree, there's no point in an x tree, really. >> I strongly suspect we need to >>simplify here to make the registry easy to use. What can we cut, >>collapse, or combine? > >I think that having 5 trees (ietf, global, local, URL, experimental) >is not overly complex, especially because the registry itself would >only ever contain ietf, global, and local tags. We can get by with ietf, global, URL. >>In the current registration draft, we say: "In general, the new >>registration proposal is circulated and reviewed in a fashion >>appropriate to the tree involved." I believe we need to be a lot >>more specific about this. > >I am confused. In revising the draft from 02 to 03, you cut out most >of the material (sections 3.2 and 3.3 of the 02 draft) which describes >the specifics. Did you change your views after you released the 03 >draft? The review mechanism probably can just copy the MIME registration, and the URL tree requires no review. >Anyway, I agree that the 03 draft needs to be more specific, and my >proposal for specifics is the text in the 02 draft (html version at >http://gewis.win.tue.nl/~koen/conneg/draft-ietf-http-feature-reg-02.html= ). >The specific text in 02 is a bit opaque though, and could be >re-structured to be more clear. > >> If we expect these to be mailing lists, we >>need to have names for them, a description of how they are >>constituted, and how things move from "under consideration" to >>"decided". >According to the 02 draft (though it does not explicitly state this), >tags in the global and local trees move to `decided' when the tag >author decides to submit the completed tag template to IANA and IANA >decides that the tag is not obviously broken or bogus. The mailing >lists are for advisory discussions only and play no formal role in the >decision process. This is still my view on how it should work. This is fine with me. >[...] >>ftp://ftp.ietf.org/internet-drafts/draft-ietf-schema-proc-list-00.txt > >I have yet to do a careful read-through of this draft, but I could not >find how the `list moderator' is appointed, and what appeal procedures >against decisions of the moderator there are, and this worries me. >>From my own inability to answer these questions for feature tags, I >have concluded that it is better to have an advisory list only. > The list is advisory, but if there's a lot of negative advice, it would = be good if it would at least put some time delay on the registration. >Some other comments on the 03 registration draft: > >- section 3.1.4 in the index is about the `Special `x.' tree', but the > actual text of this section has disappeared. It needs to be added > again. unless we drop the x tree. >- the specification of the URL tree should define > a) an unambiguous way of determining that a string used as a > feature tag is in the URL tree > b) the comparison function for tags in the URL tree (I propose > case-insensitive octet-by-octet, without % decoding) case-sensitive character-by-character. Urge people only to use lower case.=20 > >Koen. > From owner-ietf-medfree Fri Feb 27 10:25:50 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA12460 for ietf-medfree-bks; Fri, 27 Feb 1998 10:25:50 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.5/8.7.3) with SMTP id KAA12456 for ; Fri, 27 Feb 1998 10:25:45 -0800 (PST) Received: (qmail 28478 invoked from network); 27 Feb 1998 18:24:43 -0000 Received: from an044.du.pipex.com (HELO sttnb) (193.130.253.44) by smtp.dial.pipex.com with SMTP; 27 Feb 1998 18:24:43 -0000 Message-Id: <3.0.32.19980227154556.0088e6e0@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 27 Feb 1998 18:23:26 +0000 To: Media features and negotiation From: Graham Klyne Subject: Comments on draft-ietf-http-feature-reg-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk A belated review of the feature registration draft -- most of my comments are editorial but I do also wish to make some suggestions regarding the nature of registered feature tags... GK. --- 1 Introduction Recent Internet applications, such as the World Wide Web, tie together a great diversity in data formats, client and server platforms, and communities. This has created a need for various kinds of negotiation mechanisms, which tailor the data which is exchanged, or the exchange process itself, to the capabilities and preferences of the parties involved. Extensible negotiation mechanisms need a vocabulary to identify various things which can be negotiated on. To promote interoperability, a registration process is needed to ensure that that this vocabulary, which can be shared between negotiation mechanisms, is developed in an orderly, well-specified, and public manner. >>> I think this focusses too much on negotiation rather than feature identification. This might be softened by adition of the following text: Use of the vocabulary need not be restricted to negotiation: it might also be used to identify availability of content features that are not subject to negotiation. <<< [...] 2 Feature tag syntax >>> I think some words about what is referenced by a feature tag would be in order. I particularly think that feature tags should be kept (a) simple, and (b) distinct from feature sets. Even if the structure of a value associated with a feature can be arbitrarily complex, I believe we will still need some separate mechanism or framework for combining feature tags into even richer structures of feature sets. Hence, I propose the following: A "feature tag" is an identifying string that labels a "content feature". A content feature is distinct from a "feature set", in that the latter defines a set of allowable content features. The structure of a content feature is a simple Boolean, enumerated or numeric value, where a feature set may combine individual features into a richer description of complex content possibilities. The specification of mechanisms to combine feature descriptions into feature sets describing complete document content possibilities is beyond the scope of this document. The mechanisms for combining content features may be specific to a given protocol (e.g. [TCN] for HTTP). This may be controversial. My reasons for proposing such restrictions on feature tag values are two-fold: (1) the work I did on algebra for defining feature sets convinced me that the feature set description mechanism needs to be able to describe all manner of composite feature combinations. Hence, allowing such composites within individual featyre tags would be a duplication of effort. (2) Viewing content features and feature sets from a programming language data type perspective, the feature tags provide a vocabulary for describing the primitive data types, and feature sets are the structured types. Most programming languages use some of the following for their primitive data types: Boolean enumeration or atom integer real <<< A feature tag is a string consisting of one or more of the following US-ASCII characters: uppercase letters, lowercase letters, digits, colon (":"), slash ("/"), the dot (".") and the dash ("-"). Feature tags are case-insensitive. Dots are understood to potentially imply heirarchy; a feature can be subtyped by describing it as tree.feature.subfeature and by indicating this in the feature registration. 3 Feature tag registration Registration of a new feature tag starts with the submission of a registration proposal. Registration may occur in several different registration trees, which have different requirements as discussed below. In general, the new registration proposal is circulated and reviewed in a fashion appropriate to the tree involved. The feature tag is then registered if the proposal is acceptable. The .................................................<<-------------> >>> I suggest "passes review". following sections describe the requirements and procedures used for each of the different registration trees. 3.1 Registration trees >>> I agree with a comment made elsewhere by Larry that, at this time, there seems little need for anything more than IETF, global and URL trees (subject to later comments about the URL tree). <<< The following subsections define registration "trees", distinguished by the use of faceted names (e.g., names of the form "tree.feature_name"). [...] 3.1.3 Local or specialized tree The local tree is intended for feature tags identifying areas of negotiation which are relevant in a localized, specialized, restricted, or experimental context. The owner of "local" tags and associated specifications is the person or entity making the registration, or one to whom responsibility has been transferred as described below. Tags in the local tree will be distinguished by the leading facet "l.". While public exposure and review of feature tags to be registered in the local tree is not required, using the ietf-feature-tags list for review is strongly encouraged to improve the quality of those specifications. Registrations in the local tree may be submitted directly to the IANA. >>> I really cannot see a distinction between "local" and "global" tree requirements, so why have both? If 'local' were to be allowed, I would expect it to be used within closed communities and hence IANA registration would not seem appropriate. <<< 3.1.4 URL trees A feature tag may be defined as a complete URL. The "owner" of the domain is assumed to be registration authority regarding features defined and described by URLs within the domain. These tags are considered unregistered for the purpose of this document. >>> The choice or "URL" seems rather strange to me -- I would have thought that a feature tag may be a URI, or even a URN, but not a URL. The implication that a feature is a "resource" which can be "located" seems a bit perverse to me. Further, the above description refers to the "owner" of a domain. But not all URLs contain domain names (e.g. <). This leads me to believe that it is necessary to be more specific about the type of URL/URI that can be used. <<< 3.3 IANA procedures for registering feature tags The IANA will only register feature tags in the IETF tree in response to a communication from the IESG stating that a given registration has been approved. Global and local tags will be registered by the IANA automatically and without any formal review as long as the following minimal conditions are met: (1) A feature tag must function as an actual identifier of an area of negotiation. ..........-------------->..........................................<---- >>> I find the term "area of negotiation" is unhelpfully vague. How about "content feature"? This is consistent with the title of the document. <<< (2) All feature tag names must be unique, and must conform to the syntax in section 2. (3) An openly available description of the area of negotiation is .................................................<-------------------> minimally required. The specification of a feature tag must state whether the choice in the indicated area is a simple yes/no choice, or if it is a choice among multiple values. If the choice is among multiple values, and a canonical format for these values is defined, it must be possible to map this format onto octet strings. >>> The last sentence above seems to provide very little added value. I think it is possible to map any value onto octet strings. Bearing in mind my views stated above about the allowable complexity of feature tags, I think it should be possible to say something more precise, like: The specification of a feature tag must state whether the corresponding value is: (a) a simple yes/no choice, (b) a choice from a specified finite set of enumerated values with a textual reference form indicated for each of these values (where the values and textual forms may be indicated by reference to some other document or registry), (c) an integer numeric value (if necessary, stating constraints on the allowable range of values), or (d) a real (rational) numeric value (if necessary, stating constraints on the allowable values in terms of range, magnitude or constraints of representation). Constraints on the value of numeric features are optional and should be stated only when necessary to ensure that the value can be properly represented and interpreted in the context in which it is intended to be used. Specifiying arbitrary value constraints in the feature registry is not helpful. <<< (4) Any security considerations given must not be obviously bogus. (It is neither possible nor necessary for the IANA to conduct a comprehensive security review of feature tag registrations. Nevertheless, the IANA has the authority to identify obviously incompetent material and exclude it.) 3.4 Registration template To: ietf-feature-tags@iana.org (Feature tags mailing list) (or directly to iana@iana.org) Subject: Registration of feature tag XXXX | Instructions are preceded by `|'. Some fields are optional. Feature tag name: Summary of the area of negotiation indicated by this feature tag: .................<-------------------> >>> "Content feature"? | Include a short (no longer than 4 lines) description or summary | Examples: | `Negotiation on whether to use the xyzzy feature of ...' | `Negotiation on the MIME media type of the data which | is transmitted for ...' | `Negotiation on whether to use colors in displaying ...' | `Negotiation on the number of colors to use in displaying ...' >>> And an example which does not begin 'negotiation ...'? Number of alternative results in this area of negotiation: ...<--------------------------------------------------------> >>> I suggest: Possible values for this content feature: <<< [ ] 1. Two alternatives, which can be labeled with `yes' and `no' [ ] 2. More than two alternatives, or two alternatives with no natural `yes/no' labeling For case 1: nature of the `yes' and `no' alternatives: [ ] 1a. A particular feature is used/invoked/enabled, or not [ ] 1b. Other >>> I think the distinction between 1a and 1b is not (always) clear. Why not just ask the registration to describe the difference between the yes/no alternatives? <<< For case 2: How is a single alternative result naturally identified? [ ] 2a. With a name, keyword, label, or tag (e.g. a language tag) [ ] 2b. With an integer value [ ] 2c. With a numeric value of a non-integer type (e.g. float) [ ] 2d. Other [ ] 2e. There is no simple way to identify a single result >>> I think that cases 2d and 2e should be dropped. <<< (Only for case 1a) Description of the feature which is used, invoked, or enabled if the result is `yes': >>> I think this is covered above. <<< | Descriptions may also reference outside material. (Only for case 1b) Description of the effect of the 'yes' result: (Only for case 1b) Description of the effect of the 'no' result: >>> I think these are covered above. <<< (Only for case 2) Detailed description of the area of negotiation, and (in cases 2a-2d) of the format and meaning of the identifiers for the alternative results: >>> Replace "cases 2a-2d" with just "case 2a". <<< | If the number of alternative results is small, the description | could simply enumerate the identifiers of the different results | and describe their meaning. | | The identifiers of the alternative results could also be | described by referring to another IANA registry, for example | the MIME media type registry. Default negotiation result (if applicable to the intended application domain): >>> Define "default" as the value which should generaly be assumed in the absence of any explicit indication? This may be obvious, but it feels to me like something which could be misunderstood. <<< The feature tag is intended for use in the applications, protocols, services, or negotiation mechanisms: [optional] | For applications, also specify the number of the first version | which will use the tag, if applicable. Examples of typical use: [optional] Related standards or documents: [optional] Considerations particular to use in individual applications, protocols, services, or negotiation mechanisms: [optional] Interoperability considerations: [optional] Security considerations: >>> Maybe, to help get meaningful comments in this part of a registration, this could be drawn out into: (a) Privacy concerns (possible exposure of personal or confidential information) (b) Denial of service concerns (service consequences if incorrect values are specified or requested) (c) Other <<< Additional information: [optional] Keywords: [optional] Related feature tags: [optional] Related media types or data formats: [optional] Related HTML markup tags: [optional] Person & email address to contact for further information: Intended usage: | one of COMMON, LIMITED USE or OBSOLETE Author/Change controller: Requested IANA publication delay: [optional] | A delay may only be requested for registration in global or | local trees, with a maximum of two months. Other information: [optional] | Any other information that the author deems interesting may be | added here. Appendix A: IANA and RFC editor to-do list VERY IMPORTANT NOTE: This appendix is intended to communicate various editorial and procedural tasks the IANA and the RFC Editor should undertake prior to publication of this document as an RFC. This appendix should NOT appear in the actual RFC version of this document! This document refers to the feature tags mailing list ietf-feature-tags@iana.org. This list does not exist at the ...<-------------------------> present time and needs to be created. >>> The body of the text, section 3.1.2 last para, references "ietf-feature-tags" without the "@iana.org". <<< ------------ Graham Klyne From owner-ietf-medfree Tue Mar 3 09:43:20 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA04487 for ietf-medfree-bks; Tue, 3 Mar 1998 09:43:20 -0800 (PST) Received: from HQ.Cisco.COM (hq.cisco.com [171.71.67.16]) by mail.proper.com (8.8.5/8.7.3) with SMTP id JAA04481 for ; Tue, 3 Mar 1998 09:43:16 -0800 (PST) Received: from cisco.com ([171.69.109.50]) by HQ.Cisco.COM with ESMTP for ietf-medfree@imc.org; Tue, 3 Mar 1998 9:41:52 -0800 Message-ID: <34FC4129.4323A44E@cisco.com> Date: Tue, 03 Mar 1998 09:43:05 -0800 From: Dan Wing Organization: cisco Systems, Inc. X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: ietf-medfree@imc.org Subject: [Fwd: I-D ACTION:draft-ietf-fax-mdn-features-00.txt] Content-Type: multipart/mixed; boundary="------------C86428DBD85819E450CC3AC7" Sender: owner-ietf-medfree@imc.org Precedence: bulk This is a multi-part message in MIME format. --------------C86428DBD85819E450CC3AC7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------C86428DBD85819E450CC3AC7 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from pita.cisco.com ([171.71.68.13]) by HQ.Cisco.COM with ESMTP; Tue, 3 Mar 1998 6:24:08 -0800 Received: from beasley.cisco.com (mailgate-sj-2.cisco.com [171.69.2.135]) by pita.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA25376; Tue, 3 Mar 1998 06:24:07 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by beasley.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id GAA17934; Tue, 3 Mar 1998 06:24:05 -0800 (PST) Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id GAA16527; Tue, 3 Mar 1998 06:24:05 -0800 (PST) Received: from mail.proper.com(206.86.127.224) by proxy1.cisco.com via smap (V2.0) id xma016511; Tue, 3 Mar 98 14:23:59 GMT Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA03186 for ietf-fax-bks; Tue, 3 Mar 1998 06:00:05 -0800 (PST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id GAA03182 for ; Tue, 3 Mar 1998 06:00:00 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA18724; Tue, 3 Mar 1998 08:59:13 -0500 (EST) Message-Id: <199803031359.IAA18724@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ietf-fax@imc.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-fax-mdn-features-00.txt Date: Tue, 03 Mar 1998 08:59:12 -0500 Sender: owner-ietf-fax@imc.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Fax Working Group of the IETF. Title : Using Message Disposition Notifications to Indicate Supported Features Author(s) : D. Wing Filename : draft-ietf-fax-mdn-features-00.txt Pages : 6 Date : 02-Mar-98 This document describes Message Disposition Notifications [MDN] is used to send the supported features of a user's Mail User Agent. The original sender can use this information to send enhanced messages to the recipient. Features might indicate which formats the Mail User Agent can present to the user as MIME types, or finer gradations of features such as resolution or maximum image size. Features are registered using the framework described in [FEATURES]. Internet-Drafts are 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-ietf-fax-mdn-features-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-fax-mdn-features-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-fax-mdn-features-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: <19980303085030.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-mdn-features-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-mdn-features-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980303085030.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------C86428DBD85819E450CC3AC7-- From owner-ietf-medfree Tue Mar 3 12:39:27 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA05972 for ietf-medfree-bks; Tue, 3 Mar 1998 12:39:27 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.5/8.7.3) with SMTP id MAA05968 for ; Tue, 3 Mar 1998 12:39:23 -0800 (PST) Received: (qmail 17922 invoked from network); 3 Mar 1998 20:38:35 -0000 Received: from ai047.du.pipex.com (HELO sttnb) (193.130.248.47) by smtp.dial.pipex.com with SMTP; 3 Mar 1998 20:38:35 -0000 Message-Id: <3.0.32.19980303172130.0082c420@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 03 Mar 1998 20:37:10 +0000 To: Media features and negotiation From: Graham Klyne Subject: Another comment on draft-ietf-http-feature-reg-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk It has occurred to me that it would be a good idea for feature registration to associate both a textual name *and* an ASN.1 object identifier with each registered media feature. This would, I believe, help to make life easier for feature data to be carried in both text- and binary-message protocols (e.g. HTTP/SMTP and LDAP/SNMP). GK. --- ------------ Graham Klyne From owner-ietf-medfree Tue Mar 3 18:43:44 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA02456 for ietf-medfree-bks; Tue, 3 Mar 1998 18:43:44 -0800 (PST) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.7.3) with SMTP id SAA02452 for ; Tue, 3 Mar 1998 18:43:38 -0800 (PST) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA27565; Tue, 3 Mar 1998 18:41:56 -0800 Date: Tue, 3 Mar 1998 18:41:56 -0800 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9803031841.ZM27563@thornhill.arc.nasa.gov> In-Reply-To: Dan Wing "[Fwd: I-D ACTION:draft-ietf-fax-mdn-features-00.txt]" (Mar 3, 9:43am) References: <34FC4129.4323A44E@cisco.com> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: Dan Wing , ietf-medfree@imc.org Subject: Re: [Fwd: I-D ACTION:draft-ietf-fax-mdn-features-00.txt] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk Dan, Thanks for forwarding this to the group. For those who have not been following the progress of MDN, it's just gone to Proposed. I plan to put it onto the Agenda for the upcoming IETF meetings, so I'd like to encourage all those attending to put it fairly high on their "must-read" piles. regards, Ted Hardie NASA NIC From owner-ietf-medfree Tue Mar 3 19:45:16 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id TAA03168 for ietf-medfree-bks; Tue, 3 Mar 1998 19:45:16 -0800 (PST) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.7.3) with SMTP id TAA03164 for ; Tue, 3 Mar 1998 19:45:13 -0800 (PST) Received: from casablanca.parc.xerox.com ([13.2.16.111]) by alpha.xerox.com with SMTP id <53299(3)>; Tue, 3 Mar 1998 19:43:32 PST Received: from bronze-208.parc.xerox.com ([13.0.211.227]) by casablanca.parc.xerox.com with SMTP id <71814>; Tue, 3 Mar 1998 19:43:12 PST Message-ID: <04ee01bd471f$a7001280$e3d3000d@bronze-208.parc.xerox.com> From: "Larry Masinter" To: "Media features and negotiation" Subject: Re: Another comment on draft-ietf-http-feature-reg-03.txt Date: Tue, 3 Mar 1998 19:43:10 PST MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-medfree@imc.org Precedence: bulk (resend) >It has occurred to me that it would be a good idea for feature registration >to associate both a textual name *and* an ASN.1 object identifier with each >registered media feature. This would, I believe, help to make life easier >for feature data to be carried in both text- and binary-message protocols >(e.g. HTTP/SMTP and LDAP/SNMP). I think this would be a fine idea, except that we probably need some way of mapping media types and languages into the same space, and probably also some of the values of those features that have enumerated values. Are the author(s) planning on revising draft-ietf-http-feature-reg-03.txt (to become draft-ietf-conneg-feature-reg-00.txt) before the next IETF? Larry -- http://www.parc.xerox.com/masinter -----Original Message----- From: Larry Masinter To: Media features and negotiation ; Graham Klyne Date: Tuesday, March 03, 1998 1:32 PM Subject: Re: Another comment on draft-ietf-http-feature-reg-03.txt > >>It has occurred to me that it would be a good idea for feature registration >>to associate both a textual name *and* an ASN.1 object identifier with each >>registered media feature. This would, I believe, help to make life easier >>for feature data to be carried in both text- and binary-message protocols >>(e.g. HTTP/SMTP and LDAP/SNMP). > > >I think this would be a fine idea, except that we probably need some way of >mapping media types and languages into the same space, and probably >also some of the values of those features that have enumerated values. > >Are the author(s) planning on revising draft-ietf-http-feature-reg-03.txt >(to become draft-ietf-conneg-feature-reg-00.txt) before the next IETF? > >Larry >-- >http://www.parc.xerox.com/masinter > > > > > From owner-ietf-medfree Tue Mar 3 22:39:28 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id WAA04621 for ietf-medfree-bks; Tue, 3 Mar 1998 22:39:28 -0800 (PST) Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id WAA04616 for ; Tue, 3 Mar 1998 22:39:26 -0800 (PST) Received: from hplumen.cup.hp.com (hplumen.cup.hp.com [15.0.90.200]) by palrel3.hp.com (8.8.5/8.8.5tis) with ESMTP id WAA01496 for ; Tue, 3 Mar 1998 22:37:29 -0800 (PST) Received: (from mutz@localhost) by hplumen.cup.hp.com (8.7.1/8.7.1) id BAA11607 for ietf-medfree@imc.org; Wed, 4 Mar 1998 01:39:36 -0500 (EST) From: Andy Mutz Message-Id: <199803040639.BAA11607@hplumen.cup.hp.com> Subject: Re: Another comment on draft-ietf-http-feature-reg-03.txt To: ietf-medfree@imc.org Date: Wed, 04 Mar 1998 1:39:30 EST Reply-to: andy_mutz@hp.com Organization: Hewlett-Packard Laboratories, Palo Alto, California X-Mailer: Elm [revision: 212.2] Sender: owner-ietf-medfree@imc.org Precedence: bulk I will submit an edited feature-reg draft by Friday. I don't have a clear idea how to proceed on ASN.1 identifiers (I am not familiar with them right now), so if we think that's important I'd like some more help there. The x. tree was left in the table of contents by mistake in the last draft; experience with x. trees is not positive and URN's (of some flavor) are a better direction I believe. I'd like to see more comment on local vs global trees, but first glance they identical in functionality and not helpful. Those are the substantive points I recall, and I'll comment on editorials later. Andy Mutz (resend) >>It has occurred to me that it would be a good idea for feature registration >>to associate both a textual name *and* an ASN.1 object identifier with each >>registered media feature. This would, I believe, help to make life easier >>for feature data to be carried in both text- and binary-message protocols >>(e.g. HTTP/SMTP and LDAP/SNMP). Larry Masinter wrote: >I think this would be a fine idea, except that we probably need some way of >mapping media types and languages into the same space, and probably >also some of the values of those features that have enumerated values. >Are the author(s) planning on revising draft-ietf-http-feature-reg-03.txt >(to become draft-ietf-conneg-feature-reg-00.txt) before the next IETF? -- --------------------------------------------------------------- Andrew Mutz | email: andy_mutz@hp.com Internet Imaging Operation | Phone: +1 408 447 4439 Imaging Solutions Division | Page: +1 888 502 7333 11000 Wolfe Road 42UO | Cupertino, California, USA. | Radio: KF6FUT --------------------------------------------------------------- From owner-ietf-medfree Wed Mar 4 04:40:04 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id EAA20429 for ietf-medfree-bks; Wed, 4 Mar 1998 04:40:04 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id EAA20424 for ; Wed, 4 Mar 1998 04:40:01 -0800 (PST) Received: (qmail 17903 invoked from network); 4 Mar 1998 12:37:21 -0000 Received: from ad068.du.pipex.com (HELO sttnb) (193.130.243.68) by smtp.dial.pipex.com with SMTP; 4 Mar 1998 12:37:21 -0000 Message-Id: <3.0.32.19980304123344.0087a600@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 04 Mar 1998 12:35:55 +0000 To: conneg WG From: Graham Klyne Subject: draft-masinter-media-features-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk Another delayed review... For the most part, my comments are merely editorial. I do have one big issue, though, and that relates to the nature of media features and feature sets. I am currently convinced that these need to be kept as clearly distinct concepts. The work I posted previously ("Towards an algebra for media selection") established this idea in my mind, and nothing has been said to me which challenges this view. (Mathematical principles also lend credence to this view: the separation of features and feature sets seems very similar to the type theories used to avoid Russell's paradox in mathematical set theory). In order to construct a consistent and flexible framework for describing feature sets, I think we want to keep registered media features as simple as possible. Otherwise we get a muddy area within which it is difficult to distinguish between the vocabulary used to describe specific features, and the algebra used to describe feature capabilities. Given the foregoing viewpoint, I think the descriptions of media feature registrations in this draft are couched in the wrong terms. They are presented as describing feature sets rather than describing features. For example: >pix-x=n >pix-y=m > > These features indicate the maximum display size that the recipient > can conveniently display or print, measured in pixels; they indicate > horizontal (n) and vertical (m) dimensions. By describing pix-x and pix-y as indicating a *maximum* display size, these are describing a set of potential features rather than a specific feature and its asociated value. I would suggest something like: -pix-x (Integer) -pix-y (Integer) - - These features indicate the size of a raster image measured in pixels; - they indicate horizontal (pix-x) and vertical (pix-y) dimensions. The issue of describing the capabilities of a receiver which includes an ability to display images up to a certain size is, in my view, something which should properly be addressed by the feature set algebra. --- And so to the rest of the document... [...] >Introduction > >This work was originally motivated by the requirements from web >browsers to send the browser's display characteristics to the web >server to allow the server to choose an appropriate representation. > >This specification defines media features [5]. These features are the ...........................^ some ? ............................................^ is TCN still an appropriate reference, given that it is HTTP-specific. I would have thought [7] more appropriate. >means by which a recipient may inform a sender as to the >characteristics of its message handling. The sender may then provide >the variant of the message that is most suitable for the recipient. > [...] >res=nXm > > This feature indicates a discrete resolution in horizontal and > vertical inch-based units. The characteristic of a resource or > the capability of a device can be indicated using this feature. > "n" represents the horizontal resolution, and "y" represents the > vertical resolution. Each is measured in integer pixels per inch, > and the value of res is one discrete token describing both resolutions. > For example: res=72x72. Certain resources such as images may have > similar total pixel size but differing data size, quality, or aspect > ratio. Common values of res are: 60x60, 72x72, 100x100, 200x100, > 200x200, 300x300, and 400x400. Other values may be used. > > Note: While English units are not universal, it is preferable to > avoid multiple unit definitions. In keeping with my view that media features whould be as simple as possible, I would try to avoid composite features like this definition of resolution as a cartesian product type. Rather, I would define two separate features 'res-x' and 'res-y' which are simple integer values. I don't believe the feature registration document currently allows (or should allow) such composite types. The problem I have is that by allowing composite media features, the algebra needed to describe feature sets is made very much more complex. >UA-media=token > > This feature indicates the recipients device media, indicated with > an simple token. Basic token values are: screen, stationery, > transparency, envelope, or continuous-long. Other values may be ..............................<---------------> (see below) > defined. Except for "screen" and "Screen-paged", these tokens are > a subset of the Printer MIB MediaType set defined in RFC-1759 [6]. > Other tokens may be registered and used as needed. > > They are defined as: > screen: a refreshable display > screen-paged: a refreshable display which cannot scroll > stationery: separately cut sheets of an opaque material > transparency: separately cut sheets of a transparent material > envelope: envelopes that can be used for conventional > mailing purposes > continuous-short: continuously connected sheets of an opaque .....<----------------> (mismatch with above) > material connected along the short edge > >papersize=token > > For ua-media types such as stationery, it is often useful to have > information about the size of display used. While it is more > precise and predictable to use absolute resolution and pixel sizes, > some applications find it useful to provide paper size in lieu of > or in addition to this information. Paper sizes names and > definitions are taken from the the Printer MIB RFC [6]. > > Examples of paper size tokens, with names from [6], are: > na-letter: 8.5x11.0 inches > iso-A4: 210x297 mm > iso-B4: 250x353 mm > iso-A3: 297x420 mm > na-legal: 8.5x14 inches I haven't read the cited RFC, but I understood MIBs were defines as ASN.1 structures. Hence these would be OIDs. (Also ref. separate debate.) >color=n >grey=n > > The color capabilities of the recipient are indicated with feature > tag and a parameter describing the number of color channel bits > available. Values of n are typically (but not limited to) 2, 8, or > 24. For example: grey=8 indicates a display capable of > representing an image in 256 levels of a single color, while > color=8 indicates a display capable of representing an image with a > palette of 256 colors. Again, the description here is couched in terms of describing a feature set rather than a particular feature. >tiff=p > > The ability to process image/tiff application profiles, defined by [TIFF]. > Image/tiff application profiles are used to indicate subsets of resolution, > size and coding methods supported by a TIFF application. Additional > feature tags describing resolution, media size and so forth may be > required to completely describe a resource or device. GK. --- ------------ Graham Klyne From owner-ietf-medfree Wed Mar 4 04:39:57 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id EAA20418 for ietf-medfree-bks; Wed, 4 Mar 1998 04:39:57 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id EAA20409 for ; Wed, 4 Mar 1998 04:39:55 -0800 (PST) Received: (qmail 18026 invoked from network); 4 Mar 1998 12:37:38 -0000 Received: from ad068.du.pipex.com (HELO sttnb) (193.130.243.68) by smtp.dial.pipex.com with SMTP; 4 Mar 1998 12:37:38 -0000 Message-Id: <3.0.32.19980304104953.0090b520@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 04 Mar 1998 12:36:11 +0000 To: andy_mutz@hp.com From: Graham Klyne Subject: Further comments on feature tags and ASN.1 Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 01:39 04/03/98 EST, Andy Mutz wrote: >I will submit an edited feature-reg draft by Friday. I don't >have a clear idea how to proceed on ASN.1 identifiers (I am not >familiar with them right now), so if we think that's important >I'd like some more help there. I'm no ASN.1 expert either, but... ASN Object Ids (OIDs) form a highly delegated namespace which makes it very easy for every man and his dog to register a value once they have been allocated a root OID. It's a bit like DNS names except that they are built from integer components and they are used to name just about anything one might think of. My concern is that the delagated nature of the naming would mean that it would be very easy for different people to use different OIDs for commonly used features. My suggestion to include OIDs in the feature registration would apply primarily to the 'global' features. I would anticipate that IANA would register, or allocate from IETF-controlled OID-space, a single base OID for registered global features. Then, each registered global feature would be assigned a number -- an arbitrary integer which is unique among all registered global feature tags -- which would be appended to the base OID to give a common, unique OID for that feature. Even if it goes no further than this, I believe that establishing a common OID for each registered feature could save a lot of headaches later. On the IESG front, I would guess that Harald Alvestrand would be a good person to ask about IANA and OIDs. If the group feels it is appropriate, I would be prepared to formulate and send an e-mail requesting more pointers. GK. --- ------------ Graham Klyne From owner-ietf-medfree Wed Mar 4 04:39:57 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id EAA20417 for ietf-medfree-bks; Wed, 4 Mar 1998 04:39:57 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id EAA20410 for ; Wed, 4 Mar 1998 04:39:55 -0800 (PST) Received: (qmail 17930 invoked from network); 4 Mar 1998 12:37:25 -0000 Received: from ad068.du.pipex.com (HELO sttnb) (193.130.243.68) by smtp.dial.pipex.com with SMTP; 4 Mar 1998 12:37:25 -0000 Message-Id: <3.0.32.19980304123354.008795f0@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 04 Mar 1998 12:35:58 +0000 To: conneg WG From: Graham Klyne Subject: draft-ietf-fax-mdn-features-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk What a nice, simple, elegant idea! I have two thoughts regarding this approach, and a number of editorial comments. First the general thoughts: This draft addresses "half" the capability identification issue: allowing a receiver to identify capabilities to a sender for future use. It seems to me that even more useful would be a facility for the sender to similarly identify capabilities to the recipient -- this is likely to be particularly useful for a response message. The thought I have is that if the 'Features' field is allowed to appear as an outermost RFC822 header then the given syntax could be used by sender and recipient. I can think of reasons why this might be a Bad Idea -- lack of security, meddlesome gateways, etc., but is it worth considering? (Larry: do you remember the Fax WG discussion about cover pages, regarding which you had some ideas? Could some of those "distinguished content" ideas be applied to capability announcements?) Another thought: the level of information provided by the 'Features:' field is comparable with HTTP 'accept' headers, which suggests that it might be subject to some of the same failings (long headers to cover all features, etc.). It occurs tpo me that the MDN responder (who sends the MDN message) can select a subset of capability information to send based on the type of message it has just received. For example, if it receives a text file it might indicate by return that it can handle HTML and Word documents. Or if it receives a bitmap image, it might indicate by return the range of image resolutions it can handle, and also that Corel draw would be an acceptable file format (presumably for graphical data). I see nothing in the proposal that excludes this -- I just wonder if there is any value in making explicit mention of the possibility. > Using Message Disposition Notifications to > Indicate Supported Features > > draft-ietf-fax-mdn-features-00.txt > [...] >Abstract > > This document describes Message Disposition Notifications [MDN] is ...........................^ how ? ...................................................................<--> can be? > used to send the supported features of a user's Mail User Agent. The > original sender can use this information to send enhanced messages to ............................................^ subsequently ? > the recipient. > > Features might indicate which formats the Mail User Agent can ...........................<-----> (delete?) > present to the user as MIME types, or finer gradations of features > such as resolution or maximum image size. > > Features are registered using the framework described in [FEATURES]. > >1. Introduction > > In any open email environment, such as the Internet, it is impossible > to know, a priori, if a recipient will be able to process certain > messages. Because of this, only 7-bit text/plain messages is assumed > to be readable by any mail user agents (both MIME-aware and > non-MIME-aware). I found the phrasing of the above to be contentious. I would suggest: - In an open email environment, such as the Internet, it is not generally - possibly to know, a priori, if a recipient will be able to process certain - enhanced forms of message. Because of this, only 7-bit text/plain messages - can be assumed to be readable by unknown Internet mail user agents. [...] >2.1. Including Features in MDNs > > If the receiving user agent decides to send a disposition > notification message per [MDN] it can include the new field described > below in the disposition notification message. > > To indicate capabilities, the receiving user agent includes the > following new extension field > [MDN]. The syntax of this new field, using the Augmented BNF of > [ABNF], is: > > extension-field = "Features" ":" ttl-value ";" > feature > *( ";" [ LWSP ] feature ) > > ttl-value = seconds ; maximum number of seconds from > ; Date: header of this message > ; that receiver can cache the > ; capabilities information > > seconds = 1*DIGIT > > feature = Do we have to be concerned about long lines or long header fields? I.e. is there or should there be a maximum 'feature' length in the context of MDN? This syntax suggests that a 'feature' will not contain ";" characters, or parsing might become more diffcult. I guess that's a fair assumption for now, to be revisited when [FEATURE] is fully defined. [...] >3.2. Unlisted features > > If a sender has cached the features of a certain recipient, and > wishes to send a message which exceeds the previously-cached > list of features for the recipient, sender SHOULD NOT send the > message. > > For example, if the following features are cached: > > web=mozilla4; tiff=f > > and the sender wishes to send application/acrobat (which is > not supported by either of the above features), the sender SHOULD .......................................................<------> originating UA ? (I found the term 'sender' here confusing, as it suggested a different role to that which is required to "inform the user".) > inform the user that the recipient may not be able to process > the message and allow the user to send a message which can be > processed. > >3.3. Unknown capabilities > > If the TTL (section 3.1) has expired, or no capabilites information > for the recipient is available, the sender can make no assumptions > about the recipient's capabilities. In this case, the sender should > send a message that has a reasonable chance of being processed by a > recipient. This minimum will likely be user configurable, as what > is "reasonable" is dependant on the user's experience, knowledge > of the recipient's software or recipient user's expertise, and > other factors. Notwithstanding the prohibition in 3.2, I thought that a useful factor in such a choice might be expired capability information. This suggests that "SHOULD NOT send the message" in section 3.2, 1st para, could be revised to read "SHOULD NOT send the message without warning the user that the previously announced capability has expired". (In the final analysis, I think the system MUST NOT prohibit the user from sending any file format he may choose.) >4. Security Considerations > > In addition to the security considerations discussed in [MDN], > this memo creates other security risks, listed below. > >4.1. Macro Viruses > > Macro Viruses [reference?] are a widespread problem among > applications such as word processors and spreadsheets. Knowing which > featuers a user's Mail User Agent supports can assist in a malicious > attack. However, such viruses can be spread easily without such > knowledge by sending multiple messages, and each message infects a > specific application version. Privacy: disclosure of preferences. Stability: spoofing of incorrect capability information. (thinking of "cause no harm" from the FPIM draft) GK. --- ------------ Graham Klyne From owner-ietf-medfree Wed Mar 4 04:39:58 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id EAA20422 for ietf-medfree-bks; Wed, 4 Mar 1998 04:39:58 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id EAA20408 for ; Wed, 4 Mar 1998 04:39:55 -0800 (PST) Received: (qmail 18012 invoked from network); 4 Mar 1998 12:37:36 -0000 Received: from ad068.du.pipex.com (HELO sttnb) (193.130.243.68) by smtp.dial.pipex.com with SMTP; 4 Mar 1998 12:37:36 -0000 Message-Id: <3.0.32.19980304110207.00886600@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 04 Mar 1998 12:36:09 +0000 To: "Larry Masinter" From: Graham Klyne Subject: Re: Another comment on draft-ietf-http-feature-reg-03.txt Cc: "Media features and negotiation" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 19:43 03/03/98 PST, Larry Masinter wrote: >(resend) > >>It has occurred to me that it would be a good idea for feature registration >>to associate both a textual name *and* an ASN.1 object identifier with each >>registered media feature. This would, I believe, help to make life easier >>for feature data to be carried in both text- and binary-message protocols >>(e.g. HTTP/SMTP and LDAP/SNMP). > > >I think this would be a fine idea, except that we probably need some way of >mapping media types and languages into the same space, and probably >also some of the values of those features that have enumerated values. I hadn't thought of that, but I don't think it presents any insuperable problems. I seem to recall that there was some debate in the Fax WG relating to the use of Group 3 Fax Binary File Transfer (BFT,T.434) with Internet fax which touched on the issue of a mapping between ISO Object Identifiers (OIDs) and MIME content types. Was this something to do with the MIXER work? (See message extract below.) This may not cover the representation of MIME content-type parameters: I would suggest that these would be handled as separate media features (e.g. the language code on Text/* would, I suggest, be a separately registered feature in an ASN.1 representation). For language codes, I would be very surprised if there is not already a list of OIDs defined for these. For enumerated types, ASN.1 provides for definition of enumerated types where each enumerated value is represented as a distinct (named) integer [X.208, sect 15.1]. GK. --- The following is extracted from an Fax WG exchange: >> = Ned Freed > = James Rafferty >>As it happens T.434 is similar to X.400's FTBP, and a mapping for the >latter is >>already defined. There are, however, also quite a few differences, and some >>of them look to be fairly hard to deal with. (In particular, the form of >>application-reference the EMA profile specifies (OID) for FTBP isn't >available >>in T.434 (graphicstring).) >> >The last point is no longer true. We submitted contributions from the US >to add support for the OID for application reference(using the EMA work as >a starting point) and as a result, T.434 version 2 (approved in 1996 and >now available) permits the choice of Graphicstring or OID for the >application reference. In addition, a T.434 implementor's guide has been >developed which strongly encourages use of the Application Reference OID. >Companies such as Brooktrout are already deploying T.434 version 2 and >those of us in the ITU who worked on V2 feel it is much cleaner than V1. We >also believe that the T.434 implementor's guide provides useful guidance on >creating BFT implementations that should interwork with each other. > >So, any BFT/MIME mapping should be based on T.434 V2 as the preferred >starting point >(with V1 only allowing degraded interworking) and take into account the >guidance on the proper use of T.434 provided by the T.434 implementor's >guide. > >>We do need to be clear on one thing, however. Defining such a mapping is >_not_ >>for the faint of heart. It is a technically challenging task and one which >>requires considerable expertise in both FAX and email. It is therefore not >>something to be undertaken without a significant, demonstrable need. >> >With the changes that take T.434 from V1 to V2, T.434 is much closer to the >FTBP, so that technical challenge is not quite as great as it would have >been before, since much of the FTBP/MIME mapping would also apply for a >T.434/MIME mapping. > >However, I agree with Ned that a proper T.434/MIME mapping is still a solid >chunk of work. At some point, I expect there will be a need for it, but >right now its seems to be a lesser priority than various other items such >as the "extended mode" of store and forward Internet fax. ------------ Graham Klyne From owner-ietf-medfree Wed Mar 4 08:42:25 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id IAA22183 for ietf-medfree-bks; Wed, 4 Mar 1998 08:42:25 -0800 (PST) Received: from HQ.Cisco.COM (hq.cisco.com [171.71.67.16]) by mail.proper.com (8.8.8/8.7.3) with SMTP id IAA22178 for ; Wed, 4 Mar 1998 08:42:23 -0800 (PST) Received: by HQ.Cisco.COM; Wed, 4 Mar 1998 8:39:35 -0800 Date: Wed, 4 Mar 1998 8:39:35 -0800 From: Dan Wing To: GK@ACM.ORG CC: IETF-MEDFREE@imc.org Message-Id: <980304083935.20303e96@Cisco.COM> Subject: RE: draft-ietf-fax-mdn-features-00.txt Sender: owner-ietf-medfree@imc.org Precedence: bulk >This draft addresses "half" the capability identification issue: allowing a >receiver to identify capabilities to a sender for future use. It seems to >me that even more useful would be a facility for the sender to similarly >identify capabilities to the recipient -- this is likely to be particularly >useful for a response message. The thought I have is that if the >'Features' field is allowed to appear as an outermost RFC822 header then >the given syntax could be used by sender and recipient. I can think of >reasons why this might be a Bad Idea -- lack of security, meddlesome >gateways, etc., but is it worth considering? An attachment could be used, too, if the features are lengthy. Sortof like how MS Exchange mailers seem to like appending application/ms-tnef, you could have a MIME type which contains your features (sortof like a vCard contains your business card). However, it seems that having one place for features, instead of several, is best. I see a few ways to indicate capabilities 1) RFC822 header; 2) a separate part in a multipart message (similar to a vCard, or perhaps riding along inside of a vCard); 3) returned in an MDN (which requires MDN support on sender and recipient), as described in draft-ietf-fax-mdn-features-00.txt. (1) and (2) seem simple, but the problem is mailing lists, disclosing accessibility features you have (or require) to a user or mailing list that you didn't intend to disclose such information to, etc. I think (2) could contain enough information (such as original-sender:) to prevent some of the problems of RFC822 headers being munged by mailing lists. But with (2) there will be lots of features being sent by mailers that support (2) but will be ignored or annoying or cause problems for mailers that don't support (2), such as gateways that can't deal with multiparts. So far, the application/ms-tnef junk that Microsoft mailers emit is only annoying to me, for example. The nice thing about MDNs is I would expect them only to be requested by MUAs that are sophisticated enough to link an MDN to a message that was sent somewhat automatically. During this process, the MUA could also add information to your local features database. The security concerns are addressed, the mailing list issues are addressed, so a lot of the hard part, integrating with email cleanly, has been finished. >(Larry: do you remember the Fax WG discussion about cover pages, regarding >which you had some ideas? Could some of those "distinguished content" >ideas be applied to capability announcements?) > > >Another thought: the level of information provided by the 'Features:' >field is comparable with HTTP 'accept' headers, which suggests that it >might be subject to some of the same failings (long headers to cover all >features, etc.). Yep, that's why draft-ietf-fax-mdn-features-00.txt punts on the problem and points to [FEATURES], which this working group needs to write. Using MIME types might be 'good enough', but for image/tiff, it isn't detailed enough to indicate color/b&w or resolution (see draft-ietf-fax-tiffplus-xx.txt and imagine all the permutations that could be expressed -- how many do we want to express? Some of this is a problem for ietf-fax, but for conneg/medfree, I think the question is what should the expression of these sub-"features" look like? How can we avoid problems similar to HTTP "Accept: */*"? >It occurs tpo me that the MDN responder (who sends the MDN message) can >select a subset of capability information to send based on the type of >message it has just received. For example, if it receives a text file it >might indicate by return that it can handle HTML and Word documents. Or if >it receives a bitmap image, it might indicate by return the range of image >resolutions it can handle, and also that Corel draw would be an acceptable >file format (presumably for graphical data). I see nothing in the proposal >that excludes this -- I just wonder if there is any value in making >explicit mention of the possibility. That's an interesting idea. My initial concern is anytime you want to send something 'new', or you had a different idea than the recipient's MUA as to what an enhanced type is. For example, your example demonstrated receiving text/plain and in the MDN indicating you can accept application/word and text/html -- but what about other formats that are somewhat common for text, such as application/postscript, Adobe Acrobat?. It seems that without knowing all the features you will have to 'send in the blind' (like everyone does today), because you don't know if a recipient supports application/postscript unless you send it, because you can't be sure that your previous message that was text/plain would elicit a response indicating that application/postscript is supported. [Even though my example continued with using MIME types, I'm not convinced they are the most efficient method we could use. Perhaps we can create relationships between MIME types, using Graham's idea, so that a sender and receiver have the same concept of an 'enhanced' type, thus avoiding the Accept: */* problem and the screen-long Accept: header that lists all MIME types.] [editorial discussion moved offline] Thanks, -Dan Wing From owner-ietf-medfree Wed Mar 4 09:55:24 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id JAA22774 for ietf-medfree-bks; Wed, 4 Mar 1998 09:55:24 -0800 (PST) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.7.3) with SMTP id JAA22770 for ; Wed, 4 Mar 1998 09:55:23 -0800 (PST) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA28355 for ietf-medfree@imc.org; Wed, 4 Mar 1998 09:53:46 -0800 Date: Wed, 4 Mar 1998 09:53:46 -0800 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9803040953.ZM28353@thornhill.arc.nasa.gov> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: ietf-medfree@imc.org Subject: (Fwd) Re: Comments on registration draft Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk Resent due to a majordomo problem - Koen, My apologies for the long delay in replying; I was out of the office because of a family emergency and then slowly digging out of the pile that hit my desk while I was gone. I have made some comments in the text below; I will also send a message related to Larry's reply with comments which apply to both. regards, Ted Hardie On Feb 26, 10:22pm, Koen Holtman wrote: >Ted Hardie wrote: > >If we are incorporating some features by reference to other > >registries, (such as the Printer MIB) how are those features > >referenced and incorporated into the registry? > > Presumably, the filled-in feature tag registration template which sits > in the registry would contain a reference to the printer MIB > registry. This would work fine if the printer MIB registry is used to > register values of the tag. > > Now, in a scenario where you want to have a feature tag pop up > `automatically' in the feature tag registry whenever something gets > added to the printer MIB registry, we may have a problem. I don't > know if you would actually ever want such a thing: could you give an > example? I think that case could be handled by a special `feature tag > prefix' registration template, in which one could define the meaning > of all tags starting with `w.printer-MIB.' by pointing to an external > registry, or something. If the printer MIB has defined paper sizes, for example, you may wish to be able to reference a new paper size without a second registration within the "features" registry. I don't think we can or should create another hoop to jump through; I believe we need to do something that allows new values to appear in the associated registries. > >In the current registration draft, we say: "In general, the new > >registration proposal is circulated and reviewed in a fashion > >appropriate to the tree involved." I believe we need to be a lot > >more specific about this. > > I am confused. In revising the draft from 02 to 03, you cut out most > of the material (sections 3.2 and 3.3 of the 02 draft) which describes > the specifics. Did you change your views after you released the 03 > draft? > > Anyway, I agree that the 03 draft needs to be more specific, and my > proposal for specifics is the text in the 02 draft (html version at > http://gewis.win.tue.nl/~koen/conneg/draft-ietf-http-feature-reg-02.html). > The specific text in 02 is a bit opaque though, and could be > re-structured to be more clear. Actually Andy was the issuer of draft 3, so he may wade in here with his comments on what we need or don't need. In the mean time, if you have specific language to replace the opaque bits of draft 2, please send them to the list. ---End of forwarded mail from hardie@nic.nasa.gov From owner-ietf-medfree Wed Mar 4 10:23:25 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA22983 for ietf-medfree-bks; Wed, 4 Mar 1998 10:23:25 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id KAA22979 for ; Wed, 4 Mar 1998 10:23:23 -0800 (PST) Received: (qmail 23423 invoked from network); 4 Mar 1998 18:21:42 -0000 Received: from af029.du.pipex.com (HELO sttnb) (193.130.245.29) by smtp.dial.pipex.com with SMTP; 4 Mar 1998 18:21:42 -0000 Message-Id: <3.0.32.19980304181835.007a91b0@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 04 Mar 1998 18:20:15 +0000 To: conneg WG From: Graham Klyne Subject: Preview: I-D on media feature algebra Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk All, Attached is some work I have done on an I-D to describe a media feature set algebra based on feature predicates, ultimately intended to document the outcome of the thoughts I posted to this list over the past couple of months. At this stage I have tried to concentrate on what I feel is relevant to the immediate goals of the WG, viz creating a media feature registry. Therefore, the thrust of this document so far is to offer a justification for my view that registered media features should have only very simply values. GK. --- ----Start---- IETF media feature registration WG Graham Klyne Internet draft Integralis Technology Ltd. 3 March 1998 Expires: 3 September 1998 An algebra for describing media feature sets Status of this memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress''. To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Copyright (C) 1997, The Internet Society Abstract A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact [1]. A framework for such negotiation is described in [2]. A part of this framework is a way to describe the range of media features which can be handled by the sender, recipient or document transmission format of a message. Descriptions of media feature capabilities need to be based upon some underlying vocabulary of individual media features. A format for such a vocabulary and procedures for registering media features are presented in [3]. This document defines an algebra which can be used to describe feature sets which are formed from combinations and relations involving individual media features. Such feature sets are used to describe the media handling capabilities of message senders, recipients and file formats. Klyne [Page 1] Internet draft 3 March 1998 An algebra for describing media feature sets Table of contents 1. Introduction.............................................2 1.1 Structure of this document ...........................3 1.2 Discussion of this document ..........................3 1.3 Ammendment history ...................................4 1.4 Unfinished business ..................................4 2. Terminology and definitions..............................4 3. Media feature values.....................................4 3.1 Complexity of feature algebra ........................5 3.2 Sufficiency of simple types ..........................5 3.2.1 Unstructured data types..........................6 3.2.2 Cartesian product................................6 3.2.3 Disciminated union...............................6 3.2.4 Array............................................6 3.2.5 Powerset.........................................7 3.2.6 Sequence.........................................7 4. Feature set predicates...................................7 5. Other issues.............................................7 6. Security considerations..................................8 7. Copyright................................................8 8. Acknowledgements.........................................8 9. References...............................................9 10. Author's address........................................9 1. Introduction A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact [1]. A framework for such negotiation is described in [2]. A part of this framework is a way to describe the range of media features which can be handled by the sender, recipient or document transmission format of a message. Descriptions of media feature capabilities need to be based upon some underlying vocabulary of individual media features. A format for such a vocabulary and procedures for registering media features are presented in [3]. This document defines an algebra which can be used to describe feature sets which are formed from combinations and relations involving individual media features. Such feature sets are used to describe the media handling capabilities of message senders, recipients and file formats. The feature set algebra is built around the principle of using feature set predicates as mathematical relations which define constraints on feature handling capabilities. The idea is that the Klyne [Page 2] Internet draft 3 March 1998 An algebra for describing media feature sets same form of feature set expression can be used to describe sender, receiver and file format capabilities. This has been loosely modelled on the way that the Prolog programming language uses Horn Clauses to describe a set of result values. This document does not attempt to describe a concrete syntax for the algebra. Examples are given using notation drawn from the C and Prolog programming languages. [[This draft is currently incomplete. This early version is being published for the purposes of debate regarding the appropriate form of registered media features.]] 1.1 Structure of this document The main part of this draft addresses four main areas: Section 2 introduces and references some terms which are used with special meaning. Section 3 discusses constraints on the data types allowed for individual media feature values. Section 4 introduces and describes the algebra used to construct feature set descriptions with expressions containing media features. Section 5 XXXX 1.2 Discussion of this document Discussion of this document should take place on the content negotiation and media feature reagistration mailing list hosted by the Internet Mail Consortium (IMC): Please send comments regarding this document to: ietf-medfree@imc.org To subscribe to this list, send a message with the body 'subscribe' to "ietf-medfree-request@imc.org". You should get a reply as follows: The "ietf-medfree" mailing list is to discuss negotiating elements of the presentation of documents that are not naturally captured by the MIME Media Type. Klyne [Page 3] Internet draft 3 March 1998 An algebra for describing media feature sets To see what has gone on before you subscribed, please see the mailing list archive at: http://www.imc.org/ietf-medfree/ To unsubscribe from the ietf-medfree mailing list, send a message to "ietf-medfree-request@imc.org" containing the message 'unsubscribe'. If you need to contact a human about this mailing list, please send a message to: phoffman@imc.org 1.3 Ammendment history 00a 03-Mar-1998 Document initially created. 1.4 Unfinished business . Array values: are they needed? (section 3.2.4) . Feature set predicates: define the feature set algebra . Other issues: are there any? . Security considerations: are there any? 2. Terminology and definitions Feature set predicate A function of an arbitrary feature set value which returns a Boolean result. A TRUE result is taken to mean that the corresponding feature set belongs to some set of media feature handling capabilities defined by the predicate. Other terms used in this draft are defined in [2]. Klyne [Page 4] Internet draft 3 March 1998 An algebra for describing media feature sets 3. Media feature values The remainder of this document assumes that individual media feature values are simple atomic values: . Boolean values . Enumerated values . Numeric values More complex media feature values might be accommodated, but they would (a) be undesirable because they would complicate the algebra, and (b) are not necessary. These statements are justified in the following sub-sections. 3.1 Complexity of feature algebra Statement (a) above is justified as follows: predicates constructed as expressions containing media feature values must ultimately resolve to a logical combination of feature value tests. A full range of simple tests for all of the data types listed above can be performed based on just two fundamental operations: equality and less-than. All other meaningful tests can be constructed as predicates incorporating these two basic tests. For example: ( a != b ) iff !( a == b ) ( a <= b ) iff !( b < a ) ( a > b ) iff ( b < a ) ( a >= b ) iff !( a < b ) If additional (composite) data types are introduced, then additional operators must be introduced to test their component parts: the addition of just one further comparison operator increases the number of such operators by 50%. 3.2 Sufficiency of simple types To justify statement (b), let us first review the range of composite data types that might reasonably be considered. In 1972, a paper "Notes on data structuring" by C. A. R. Hoare was published in the book "Structured Programming" [4]. This was an early formalization of data types used in programming languages, and its content has formed a sufficient basis for describing the data types in almost every programming language which has been developed. Klyne [Page 5] Internet draft 3 March 1998 An algebra for describing media feature sets The data types covered by this paper are: . Unstructured data types: (integer, real, enumeration, ordered enumeration, subranges). . Cartesian product (e.g. C 'struct'). . Discriminated union (e.g. C 'union'). . Array. . Powerset (e.g. Pascal 'SET OF'). . Sequence (e.g. C string, Pascal 'FILE OF'). To demonstrate sufficiency of simple types for media features we must show that the feature-set defining properties of these composite types can be captured using predeicates on the simple simple types described previously. 3.2.1 Unstructured data types Note that the unstructured data types noted correspond closely to, and can be represented by the proposed simple value types for media features. 3.2.2 Cartesian product A cartesian product value (e.g. resolution=[x,y]) is easily captured as a collection of two or more separately named media features (e.g. x-resolution=x, y-resolution=y). 3.2.3 Disciminated union A discriminated union value is an either/or type of choice. For example, a given workstation might be able to display 16K colours at 1024x768 resolution, OR 256 colours at 1280x1024 resolution. These possibilities are captured by a logical-OR of predicates: ( ( x-resolution <= 1024 ) && ( y-resolution <= 768 ) && ( colours <= 16384 ) ) || ( ( x-resolution <= 1280 ) && ( y-resolution <= 1024 ) && ( colours <= 256 ) ) Klyne [Page 6] Internet draft 3 March 1998 An algebra for describing media feature sets 3.2.4 Array An array represents a mapping from one data type to another. For example, the availability of pens in a pen plotter might be represented by an array which maps a pen number to a colour. If the array index which forms the basis for defining a feature set is assumed to be a constant, then each member can be designated by a feature name which incorporates the index value. For example: Pen-1=black, pen-2=red, etc. Another example where an array might describe a media feature is a colour pallette: an array is used to associate a colour value (in terms of RGB or some other colour model) with a colour index value. In this case is is possible to envisage a requirement for a particular colour to be loaded in the pallette without any knowledge of the index which maps to it. In this case, the colour might be treated as a named Boolean attribute: if TRUE then that colour is deemed to be available in the pallette Feature selection based on a variable array index is more difficult, but it is believed that this is not a required capability for media selection. [[I cannot think of any example of feature selection which involves a variable index into an array. If such a feature is presented, an array type could be added to the set of allowable media feature types, and an array selection operator added to the algebra.]] 3.2.5 Powerset A powerset is a collection of zero, one or more values from some base set of values. A colour pallette may be viewed as a powerset of colour values, or the fonts available in a printer as a powerset of all available fonts. A powerset is very easily represented by a separate Boolean-values feature for each member of the base set. The value TRUE indicates that the corresonding value is a member of the powerset value. 3.2.6 Sequence A sequence is a list of values from some base set of values, which are accessed sequentially. A sequence can be modelled by an aray if one assumes integer index values starting at (say) 1 and incrementing by 1 for each Klyne [Page 7] Internet draft 3 March 1998 An algebra for describing media feature sets successive element of the sequence. Other variants of a sequence can be similarly modelled by an array. Thus, the considerations described above relating to array values can be considered as also applying (in part) to sequence values. That is, if arrays are deemed to be adequately handled, then sequence values too can be handled. 4. Feature set predicates [[This section to describe the feature set algebra]] 5. Other issues [[Placeholder for now]] 6. Security considerations [[Does this introduce any security considerations which are not already covered in [1,2,3]? I suspect not.]] 7. Copyright Copyright (C) The Internet Society 1998. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Klyne [Page 8] Internet draft 3 March 1998 An algebra for describing media feature sets The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 8. Acknowledgements My thanks to Larry Masinter for opening my eyes to the breadth of the media feature issue, and encouraging me to air my early ideas. Early discussions of early ideas on the IETF-HTTP and IETF-FAX discussion lists led to useful inputs from Koen Holtman, Larry Masinter, Ted Hardie and Dan Wing. The debate was later moved to the IETF conneg WG mailing list, where Al Gilman was particularly helpful in helping me to develop ideas for a feature set algebra. 9. References [1] "Scenarios for the Delivery of Negotiated Content" T. Hardie, NASA Network Information Center Internet draft: Work in progress, November 1997. [2] "Requirements for protocol-independent content negotiation" G. Klyne, Integralis Ltd. Internet draft: Work in progress, March 1998. [3] "Content feature tag registration procedures" Koen Holtman, TUE Andrew Mutz, Hewlett-Packard Ted Hardie, NASA Internet draft: Work in progress, November 1997. [4] "Notes on data structuring" C. A. R. Hoare, in "Structured Programming" Academic Press, APIC Studies in Data Processing No. 8 ISBN 0-12-200550-3 / 0-12-200556-2 1972. Klyne [Page 9] Internet draft 3 March 1998 An algebra for describing media feature sets 10. Author's address Graham Klyne Integralis Technology Ltd Brewery Court 43-45 High Street Theale Reading, RG7 5AH United Kingdom Telephone: +44 118 930 6060 Facsimile: +44 118 930 2143 E-mail: GK@ACM.ORG Klyne [Page 10] ------------ Graham Klyne From owner-ietf-medfree Wed Mar 4 12:09:32 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA23909 for ietf-medfree-bks; Wed, 4 Mar 1998 12:09:32 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id MAA23905 for ; Wed, 4 Mar 1998 12:09:31 -0800 (PST) Received: (qmail 13189 invoked from network); 4 Mar 1998 20:07:52 -0000 Received: from an243.du.pipex.com (HELO sttnb) (193.130.253.243) by smtp.dial.pipex.com with SMTP; 4 Mar 1998 20:07:52 -0000 Message-Id: <3.0.32.19980304183043.009074c0@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 04 Mar 1998 20:06:25 +0000 To: Dan Wing From: Graham Klyne Subject: RE: draft-ietf-fax-mdn-features-00.txt Cc: IETF-MEDFREE@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 08:39 04/03/98 -0800, Dan Wing wrote: >>This draft addresses "half" the capability identification issue: allowing a >>receiver to identify capabilities to a sender for future use. It seems to >>me that even more useful would be a facility for the sender to similarly >>identify capabilities to the recipient -- this is likely to be particularly >>useful for a response message. The thought I have is that if the >>'Features' field is allowed to appear as an outermost RFC822 header then >>the given syntax could be used by sender and recipient. I can think of >>reasons why this might be a Bad Idea -- lack of security, meddlesome >>gateways, etc., but is it worth considering? > >An attachment could be used, too, if the features are lengthy. Sortof >like how MS Exchange mailers seem to like appending >application/ms-tnef, you could have a MIME type which contains >your features (sortof like a vCard contains your business card). Yes... that was part of what I had in mind when I was alluding to Larry's comments about fax cover pages, but using a header to "distinguish" the meta-content. >However, it seems that having one place for features, instead of >several, is best. Hmmm... I don't argue the goal, just wonder whether it is achievable in a fashion that satisfies all requirements and desiderata. We'll see! >>It occurs tpo me that the MDN responder (who sends the MDN message) can >>select a subset of capability information to send based on the type of >>message it has just received. For example, if it receives a text file it >>might indicate by return that it can handle HTML and Word documents. Or if >>it receives a bitmap image, it might indicate by return the range of image >>resolutions it can handle, and also that Corel draw would be an acceptable >>file format (presumably for graphical data). I see nothing in the proposal >>that excludes this -- I just wonder if there is any value in making >>explicit mention of the possibility. > >That's an interesting idea. My initial concern is anytime you want to >send something 'new', or you had a different idea than the recipient's >MUA as to what an enhanced type is. > >For example, your example demonstrated receiving text/plain and in the >MDN indicating you can accept application/word and text/html -- but >what about other formats that are somewhat common for text, such as >application/postscript, Adobe Acrobat?. Indeed. Maybe an agent would send a few options at a time on the basis that a correspondent could build a database over time? Or not send them capabilities every time because you know they had been sent recently? >[Even though my example continued with using MIME types, I'm not >convinced they are the most efficient method we could use. Perhaps we >can create relationships between MIME types, using Graham's idea, so >that a sender and receiver have the same concept of an 'enhanced' >type, thus avoiding the Accept: */* problem and the screen-long >Accept: header that lists all MIME types.] Er... which idea was that? I think I'm missing something here ;-) GK. --- ------------ Graham Klyne From owner-ietf-medfree Wed Mar 4 12:19:09 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA24014 for ietf-medfree-bks; Wed, 4 Mar 1998 12:19:09 -0800 (PST) Received: from HQ.Cisco.COM (hq.cisco.com [171.71.67.16]) by mail.proper.com (8.8.8/8.7.3) with SMTP id MAA24010 for ; Wed, 4 Mar 1998 12:19:08 -0800 (PST) Received: by HQ.Cisco.COM; Wed, 4 Mar 1998 12:16:23 -0800 Date: Wed, 4 Mar 1998 12:16:23 -0800 From: Dan Wing To: GK@ACM.ORG CC: IETF-MEDFREE@imc.org Message-Id: <980304121623.2030a297@Cisco.COM> Subject: RE: draft-ietf-fax-mdn-features-00.txt Sender: owner-ietf-medfree@imc.org Precedence: bulk >>[Even though my example continued with using MIME types, I'm not >>convinced they are the most efficient method we could use. Perhaps we >>can create relationships between MIME types, using Graham's idea, so >>that a sender and receiver have the same concept of an 'enhanced' >>type, thus avoiding the Accept: */* problem and the screen-long >>Accept: header that lists all MIME types.] > >Er... which idea was that? I think I'm missing something here ;-) Establish a relationship between MIME types; for example, that text/plain is a subset of other types (text/html and text/enriched, obviously, and possibly others like application/msword, application/wordperfect, application/postscript, etc.). At least, that's what I thought one of your ideas was leading towards. Pretend this is set notation, perhaps something like this: text: text/plain < formatted-text formatted-text: text/paragraph < text/enriched < text/html < word-processor word-processor: application/word = application/wordperfect text < ( formatted-text = word-processor ) I don't know if this will scale, but I do already see problems that some things are "equal" nor are some things really "supersets" of other things in all respects. So this might be useless, but it is only a brainstorm (watch out!). -Dan Wing From owner-ietf-medfree Wed Mar 4 12:31:30 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA24185 for ietf-medfree-bks; Wed, 4 Mar 1998 12:31:30 -0800 (PST) Received: from wsooti08.win.tue.nl (wsooti08.win.tue.nl [131.155.70.156]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id MAA24181 for ; Wed, 4 Mar 1998 12:31:27 -0800 (PST) Received: from koen@localhost by wsooti08.win.tue.nl (8.8.7) id VAA06133. Wed, 4 Mar 1998 21:29:33 +0100 (MET) From: koen@win.tue.nl (Koen Holtman) Message-Id: <199803042029.VAA06133@wsooti08.win.tue.nl> Subject: Re: Comments on draft-ietf-http-feature-reg-03.txt To: GK@ACM.ORG (Graham Klyne) Date: Wed, 4 Mar 1998 21:29:33 +0100 (MET) Cc: ietf-medfree@imc.org In-Reply-To: <3.0.32.19980227154556.0088e6e0@pop.dial.pipex.com> from "Graham Klyne" at Feb 27, 98 06:23:26 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ietf-medfree@imc.org Precedence: bulk Graham Klyne: > [....] ><<< > > For case 2: How is a single alternative result naturally identified? > > [ ] 2a. With a name, keyword, label, or tag (e.g. a language tag) > [ ] 2b. With an integer value > [ ] 2c. With a numeric value of a non-integer type (e.g. float) > [ ] 2d. Other > [ ] 2e. There is no simple way to identify a single result > >>>> >I think that cases 2d and 2e should be dropped. ><<< I agree with most of whay you said on treating tags and their values as `primitive', but I think that 2d. should stay, maybe reformulated as 2d. Other (represented as a US-ASCII character string) My reasoning is that I do not want to make it impossible for someone defining a future negotiation protocol to include support for a new class of `primitive values' such as `comma-separated list of language tags' or `version number in notation x.y.z'. Such things may be crucial for some applications. I know that you could take the view that all such more complex new values should always be constructed using whatever `feature set' syntax we come up with later, but that view is too extreme for me. >Graham Klyne Koen. From owner-ietf-medfree Wed Mar 4 12:42:30 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA24276 for ietf-medfree-bks; Wed, 4 Mar 1998 12:42:30 -0800 (PST) Received: from wsooti08.win.tue.nl (wsooti08.win.tue.nl [131.155.70.156]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id MAA24271 for ; Wed, 4 Mar 1998 12:42:23 -0800 (PST) Received: from koen@localhost by wsooti08.win.tue.nl (8.8.7) id VAA06149. Wed, 4 Mar 1998 21:40:17 +0100 (MET) From: koen@win.tue.nl (Koen Holtman) Message-Id: <199803042040.VAA06149@wsooti08.win.tue.nl> Subject: Re: Comments on registration draft To: hardie@nic.nasa.gov Date: Wed, 4 Mar 1998 21:40:16 +0100 (MET) Cc: masinter@parc.xerox.com, koen@win.tue.nl, ietf-medfree@imc.org In-Reply-To: <9803031831.ZM27544@thornhill.arc.nasa.gov> from "Ted Hardie" at Mar 3, 98 06:31:53 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ietf-medfree@imc.org Precedence: bulk Ted Hardie: > [...] >I have a vague memory of a standard for URL matching, but I may be >mixing that up with the UTF8 matching rules. Is case-sensitive >character-by-character the standard for URLs, and if so what reference >should we use to cite it? >From past feedback on an earlier TCN draft which had URLs as feature tags, I remember that there is no general standard for URL comparision, and that different schemes have different canonical comparison functions defined in different documents, some of which are RFCs. I do not believe there is currently any IETF recommendation on what to use as a simple URL comparison function. > > > regards, > Ted Hardie > NASA NIC Koen. From owner-ietf-medfree Wed Mar 4 12:43:04 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA24286 for ietf-medfree-bks; Wed, 4 Mar 1998 12:43:04 -0800 (PST) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.7.3) with SMTP id MAA24281 for ; Wed, 4 Mar 1998 12:42:48 -0800 (PST) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA28735; Wed, 4 Mar 1998 12:40:40 -0800 Date: Wed, 4 Mar 1998 12:40:40 -0800 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9803041240.ZM28733@thornhill.arc.nasa.gov> In-Reply-To: koen@win.tue.nl (Koen Holtman) "Re: Comments on draft-ietf-http-feature-reg-03.txt" (Mar 4, 9:29pm) References: <199803042029.VAA06133@wsooti08.win.tue.nl> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: dwing@Cisco.COM, GK@ACM.ORG (Graham Klyne), koen@win.tue.nl (Koen Holtman) Subject: Re: Comments on draft-ietf-http-feature-reg-03.txt Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk This is sort of the inverse of how I have been thinking of feature sets. If you create a feature set as fibl = (foo bar) kren = (baz gin) zeb = (fibl kren) If a clump of features gets to be common enough, it can have a feature name with the description equal to its component features or the clumps. You end up with a short feature name (zeb) for (foo bar baz gin). You could even make that declaration on the fly for some protocols. For MIME media types, there presumption isn't that features aggregate, but that features can be stripped in case of need (with some loss implied). That is, if you declare something to be text/something a user agent incapable of text/something should treat it like text/plain. That relationship and possibility would have to be understood before we tried to treat them as aggregable features; in particular, it would be problematic to treat application/ms-word in the same feature set text/html because the "default action" for them is different according to the MIME rules. regards, Ted Hardie NASA NIC On Mar 4, 12:16pm, Dan Wing wrote: > Establish a relationship between MIME types; for example, that > text/plain is a subset of other types (text/html and text/enriched, > obviously, and possibly others like application/msword, > application/wordperfect, application/postscript, etc.). At least, > that's what I thought one of your ideas was leading towards. > > Pretend this is set notation, perhaps something like this: > > text: text/plain < formatted-text > formatted-text: text/paragraph < text/enriched < text/html < word-processor > word-processor: application/word = application/wordperfect > > text < ( formatted-text = word-processor ) > > I don't know if this will scale, but I do already see problems that > some things are "equal" nor are some things really "supersets" of > other things in all respects. So this might be useless, but it is > only a brainstorm (watch out!). > > -Dan Wing >-- End of excerpt from Dan Wing From owner-ietf-medfree Wed Mar 4 13:01:03 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA24444 for ietf-medfree-bks; Wed, 4 Mar 1998 13:01:03 -0800 (PST) Received: from wsooti08.win.tue.nl (wsooti08.win.tue.nl [131.155.70.156]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id NAA24440 for ; Wed, 4 Mar 1998 13:01:01 -0800 (PST) Received: from koen@localhost by wsooti08.win.tue.nl (8.8.7) id VAA06177. Wed, 4 Mar 1998 21:59:09 +0100 (MET) From: koen@win.tue.nl (Koen Holtman) Message-Id: <199803042059.VAA06177@wsooti08.win.tue.nl> Subject: Re: Another comment on draft-ietf-http-feature-reg-03.txt To: andy_mutz@hp.com Date: Wed, 4 Mar 1998 21:59:08 +0100 (MET) Cc: ietf-medfree@imc.org In-Reply-To: <199803040639.BAA11607@hplumen.cup.hp.com> from "Andy Mutz" at Mar 4, 98 01:39:30 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ietf-medfree@imc.org Precedence: bulk Andy Mutz: > [...] >I'd like to see more comment on local vs global trees, but first >glance they identical in functionality and not helpful. I believe the original motivation for having the local registry was 1. the mime registration document had something similar 2a. that some localised browsers might have special features, 2b. that the feature tags for these local features could appear in variant lists visible on the internet (e.g. the company homepage has a variant which depends on a feature of the localised browsers) 2c. so there would need to be a global, collision-free registry for such local tags 2d. but if we register them in the `global tags' namespace, the global space becomes harder to search Anyway, I interpret the comments in the last few days as leaning towards removing the local namespace, and I have no objections against removing local if we keep the URL space. Point 2d. above is also addressed to some extent by having a smart namespace search engine make use of the Intended usage: | one of COMMON, LIMITED USE or OBSOLETE part of the feature registration template. >Andy Mutz Koen. From owner-ietf-medfree Wed Mar 4 14:17:21 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA25101 for ietf-medfree-bks; Wed, 4 Mar 1998 14:17:21 -0800 (PST) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.7.3) with SMTP id OAA25097 for ; Wed, 4 Mar 1998 14:17:15 -0800 (PST) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA28848; Wed, 4 Mar 1998 14:14:56 -0800 Date: Wed, 4 Mar 1998 14:14:56 -0800 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9803041414.ZM28846@thornhill.arc.nasa.gov> In-Reply-To: koen@win.tue.nl (Koen Holtman) "Re: Another comment on draft-ietf-http-feature-reg-03.txt" (Mar 4, 9:59pm) References: <199803042059.VAA06177@wsooti08.win.tue.nl> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: koen@win.tue.nl (Koen Holtman), andy_mutz@hp.com Subject: Re: Another comment on draft-ietf-http-feature-reg-03.txt Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk On Mar 4, 9:59pm, Koen Holtman wrote: > 2b. that the feature tags for these local features could appear > in variant lists visible on the internet (e.g. the company > homepage has a variant which depends on a feature of the localised > browsers) Is there a security concern here, or only a potential conflict concern? If the concern is potential conflicts, then the URL tags avoid the conflict because they are unique. If there is a security concern that outside users might detect the use of some feature meants only for internal users, then we might want security consideration language like: "Those creating URL tags to identify features available only to internal users may wish to restrict their release in feature lists made available to the public Internet." ..deleted.. > Anyway, I interpret the comments in the last few days as leaning > towards removing the local namespace, and I have no objections against > removing local if we keep the URL space. > Let's agree then that we are removing local and the x tree and keeping IETF, global, and URL. regards, Ted Hardie NASA NIC From owner-ietf-medfree Thu Mar 5 11:36:40 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA18734 for ietf-medfree-bks; Thu, 5 Mar 1998 11:25:38 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id LAA18730 for ; Thu, 5 Mar 1998 11:25:37 -0800 (PST) Received: (qmail 11919 invoked from network); 5 Mar 1998 19:24:04 -0000 Received: from ad050.du.pipex.com (HELO sttnb) (193.130.243.50) by smtp.dial.pipex.com with SMTP; 5 Mar 1998 19:24:04 -0000 Message-Id: <3.0.32.19980305121711.0093dc30@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 05 Mar 1998 19:22:36 +0000 To: koen@win.tue.nl (Koen Holtman) From: Graham Klyne Subject: Re: Comments on draft-ietf-http-feature-reg-03.txt Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 21:29 04/03/98 +0100, Koen Holtman wrote: >Graham Klyne: >> >[....] >><<< >> >> For case 2: How is a single alternative result naturally identified? >> >> [ ] 2a. With a name, keyword, label, or tag (e.g. a language tag) >> [ ] 2b. With an integer value >> [ ] 2c. With a numeric value of a non-integer type (e.g. float) >> [ ] 2d. Other >> [ ] 2e. There is no simple way to identify a single result >> >>>>> >>I think that cases 2d and 2e should be dropped. >><<< > >I agree with most of whay you said on treating tags and their values >as `primitive', but I think that 2d. should stay, maybe reformulated as > > 2d. Other (represented as a US-ASCII character string) I see 2d. as being isomorphic to 2a (i.e. no different in any significant respect). I don't see the list of enumerated values as having to be closed by the registration, and an arbitrary ASCII string would be allowable... >My reasoning is that I do not want to make it impossible for someone >defining a future negotiation protocol to include support for a new >class of `primitive values' such as `comma-separated list of language >tags' or `version number in notation x.y.z'. Such things may be >crucial for some applications. I know that you could take the view >that all such more complex new values should always be constructed >using whatever `feature set' syntax we come up with later, but that >view is too extreme for me. You give two examples which I think are probably fundamentally different: With the list of language tags I think the individual tags should be accessed as primitive values -- my feature set proposals (elsewhere) allow a feature set to permit or require multiple instances of a particular media feature (e.g. language(English) && language(German) ). With the version number example I think the issue here is that the syntax may define separate parts, but that the value is seen by the negotiation process as an atomic value without internal structure. (Your own TCN proposals would not allow a negotiation participant to do more than compare such a version string for [in]equality with a givem value.) I do not seek to exclude the possibilities you are describing here: it is just that I think that the separation between features and a combining algebra should be clearly made. Indeed, I don't have a fundamental objection to the feature tag registration allowing a string-values feature separately from the others and even indicating a syntax for that string. But at the end of the day, the string syntax should not be seen as implying any structure which can be exploited by content negotiation: any such structure is, in my view, something which should be represented in a feature set algebra. BTW, why limit "other" to being a US-ASCII character string: why not UTF-8? GK. --- ------------ Graham Klyne From owner-ietf-medfree Thu Mar 5 11:43:45 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA18740 for ietf-medfree-bks; Thu, 5 Mar 1998 11:25:40 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id LAA18736 for ; Thu, 5 Mar 1998 11:25:39 -0800 (PST) Received: (qmail 11937 invoked from network); 5 Mar 1998 19:24:06 -0000 Received: from ad050.du.pipex.com (HELO sttnb) (193.130.243.50) by smtp.dial.pipex.com with SMTP; 5 Mar 1998 19:24:06 -0000 Message-Id: <3.0.32.19980305120119.0093db90@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 05 Mar 1998 19:22:38 +0000 To: hardie@nic.nasa.gov From: Graham Klyne Subject: Re: Comments on draft-ietf-http-feature-reg-03.txt Cc: dwing@Cisco.COM, koen@win.tue.nl (Koen Holtman), ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk Ted, I broadly agree with what you say here. I hope you find my response to Dan explains how some of these ideas might be developed. To develop the argument, I think there are two separate issues raised here: (a) A capability for a recipient to handle some set of text file capabilities (b) A possibility for some advanced text file format to be interpretted as plain text. This depends in part on MIME processing rules that unknown text subtypes should be treated as text/plain [RFC 2046, sect 4.1.4]. I think this is an issue which is largely separate from the structure of content negotiation. What this debate does raise is the idea that feature set predicates which are suitable for receivers to announce their capabilities (e.g. a predicate which allows text/plain, text/paragraph, text/enriched or text/html) are not necessarily suitable for senders to announce what they can offer (e.g. application/word, text/html or text/plain). The predicates can still be based on the same algebra; it's just that sender-side predicates are not necessarily useful for describing receiver-side capabilities, and vice versa. Thus, a sender-side plain-text feature set predicate might include any MIME text subtype which displays reasonably well when interpretted as text/plain. GK. --- At 12:40 04/03/98 -0800, Ted Hardie wrote: >This is sort of the inverse of how I have been thinking of >feature sets. If you create a feature set as > >fibl = (foo bar) >kren = (baz gin) >zeb = (fibl kren) > >If a clump of features gets to be common enough, it can >have a feature name with the description equal to its >component features or the clumps. You end up with a short >feature name (zeb) for (foo bar baz gin). You could even >make that declaration on the fly for some protocols. > >For MIME media types, there presumption isn't that >features aggregate, but that features can be stripped in >case of need (with some loss implied). That is, if you >declare something to be text/something a user agent >incapable of text/something should treat it like >text/plain. That relationship and possibility would have >to be understood before we tried to treat them as >aggregable features; in particular, it would be >problematic to treat application/ms-word in the same >feature set text/html because the "default action" for >them is different according to the MIME rules. > > regards, > Ted Hardie > NASA NIC > > > >On Mar 4, 12:16pm, Dan Wing wrote: >> Establish a relationship between MIME types; for example, that >> text/plain is a subset of other types (text/html and text/enriched, >> obviously, and possibly others like application/msword, >> application/wordperfect, application/postscript, etc.). At least, >> that's what I thought one of your ideas was leading towards. >> >> Pretend this is set notation, perhaps something like this: >> >> text: text/plain < formatted-text >> formatted-text: text/paragraph < text/enriched < text/html < >word-processor >> word-processor: application/word = application/wordperfect >> >> text < ( formatted-text = word-processor ) >> >> I don't know if this will scale, but I do already see problems that >> some things are "equal" nor are some things really "supersets" of >> other things in all respects. So this might be useless, but it is >> only a brainstorm (watch out!). >> >> -Dan Wing >>-- End of excerpt from Dan Wing > > > ------------ Graham Klyne From owner-ietf-medfree Thu Mar 5 11:48:11 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA18729 for ietf-medfree-bks; Thu, 5 Mar 1998 11:25:37 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id LAA18724 for ; Thu, 5 Mar 1998 11:25:35 -0800 (PST) Received: (qmail 11910 invoked from network); 5 Mar 1998 19:24:02 -0000 Received: from ad050.du.pipex.com (HELO sttnb) (193.130.243.50) by smtp.dial.pipex.com with SMTP; 5 Mar 1998 19:24:02 -0000 Message-Id: <3.0.32.19980305112841.0093dcd0@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 05 Mar 1998 19:22:33 +0000 To: Dan Wing From: Graham Klyne Subject: Capturing relationships between content types Cc: IETF-MEDFREE@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 12:16 04/03/98 -0800, Dan Wing wrote: >>>[Even though my example continued with using MIME types, I'm not >>>convinced they are the most efficient method we could use. Perhaps we >>>can create relationships between MIME types, using Graham's idea, so >>>that a sender and receiver have the same concept of an 'enhanced' >>>type, thus avoiding the Accept: */* problem and the screen-long >>>Accept: header that lists all MIME types.] >> >>Er... which idea was that? I think I'm missing something here ;-) > >Establish a relationship between MIME types; for example, that >text/plain is a subset of other types (text/html and text/enriched, >obviously, and possibly others like application/msword, >application/wordperfect, application/postscript, etc.). At least, >that's what I thought one of your ideas was leading towards. That wasn't something I explicitly had in mind. I've made several and varied comments recently, so I'm not sure where it develops from. Maybe closest to this in my thinking was a possibility that "feature sets" might be defined which could encompass one or more content types. And the kind of relationship you describe could exist between these feature sets. >Pretend this is set notation, perhaps something like this: > > text: text/plain < formatted-text > formatted-text: text/paragraph < text/enriched < text/html < word-processor > word-processor: application/word = application/wordperfect > > text < ( formatted-text = word-processor ) > >I don't know if this will scale, but I do already see problems that >some things are "equal" nor are some things really "supersets" of >other things in all respects. So this might be useless, but it is >only a brainstorm (watch out!). I think the relationships you describe could be captured using predicates-as-feature-sets. The main difference I see is that the subset comparison (which I assume you mean by "<") would not apply directly to MIME content types (or media feature values). Thus, to capture your subset relationships, a "feature set" predicate would be defined for each of the MIME types; using a Prolog-derived notation: app-winword(X) :- MIME-Content-type(X,"application/word"). app-wordperfect(X) :- MIME-Content-type(X,"application/wordperfect"). text-html(X) :- MIME-Content-type(X,"text/html"). text-enriched(X) :- MIME-Content-type(X,"text/enriched"). text-paragraph(X) :- MIME-Content-type(X,"text/paragraph"). text-plain(X) :- MIME-Content-type(X,"text/plain"). text(X) :- text-plain(X). text(X) :- formatted-text(X). formatted-text(X) :- text-enriched(X). formatted-text(X) :- text-paragraph(X). formatted-text(X) :- text-html(X). formatted-text(X) :- word-processor(X). word-processor(X) :- app-winword(X). word-processor(X) :- app-wordperf(X). (Hint: read ":-" as "if" or "is implied by") (Note: the first 6 clauses could be eliminated by direct substitution of the corresponding MIME-Content-type predicates into the clauses that follow.) One concern I have here is: I am not sure what wou mean by "formatted-text = word-processor". The clauses I have written above indicate that word processor files are a subset of formatted text files, rather than implying an equivalence between them. Re-reading what you have written, it seems where you use "=" that "OR" would be more appropriate. The multiple Prolog-style clauses for a single predicate name capture this idea. In order to redeuce the number of headers that need to be sent, I would aniticipate a feature set registry being created so that (for example) a recipient could indicate acceptance of 'formatted-text' and 'app-winword'. (There is some scope here for interpretation of individual media features, such as content-type, as feature predicates. But I believe any such optimization should come later, after a consistent underlying framework has been agreed.) GK. --- ------------ Graham Klyne From owner-ietf-medfree Thu Mar 5 13:57:29 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA01349 for ietf-medfree-bks; Thu, 5 Mar 1998 13:57:29 -0800 (PST) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.7.3) with SMTP id NAA01345 for ; Thu, 5 Mar 1998 13:57:29 -0800 (PST) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA00271; Thu, 5 Mar 1998 13:55:25 -0800 Date: Thu, 5 Mar 1998 13:55:25 -0800 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9803051355.ZM269@thornhill.arc.nasa.gov> In-Reply-To: Graham Klyne "Re: Comments on draft-ietf-http-feature-reg-03.txt" (Mar 5, 7:22pm) References: <3.0.32.19980305120119.0093db90@pop.dial.pipex.com> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: Graham Klyne , hardie@nic.nasa.gov Subject: Re: Comments on draft-ietf-http-feature-reg-03.txt Cc: dwing@Cisco.COM, koen@win.tue.nl (Koen Holtman), ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk Graham, I agree that there are seperate issues here. I'm just trying to make sure that we don't lose sight of the MIME rules for interpreting things like text/html when we consider feature sets. I see nothing wrong with creating a feature set that contains features which apply to or are derived from more than one MIME type; indeed, I suspect that those clusters will end up being common and useful. Some of the message along the way seemed to say something like text/html = (text/plain formatting) as a parallel to bez = (fipple bar) I just want us to be recognize that they may work in some instances but can't be assumed, especially if you extend it to: rendered-poscript = (text/plain formattting) since postscript is an application. Hopefully this explanation of my concerns has not furthered muddied the waters. regards, Ted Hardie NASA NIC On Mar 5, 7:22pm, Graham Klyne wrote: > Subject: Re: Comments on draft-ietf-http-feature-reg-03.txt > Ted, > > I broadly agree with what you say here. I hope you find my response to Dan > explains how some of these ideas might be developed. > > To develop the argument, I think there are two separate issues raised here: > > (a) A capability for a recipient to handle some set of text file capabilities > > (b) A possibility for some advanced text file format to be interpretted as > plain text. This depends in part on MIME processing rules that unknown > text subtypes should be treated as text/plain [RFC 2046, sect 4.1.4]. I > think this is an issue which is largely separate from the structure of > content negotiation. > > > What this debate does raise is the idea that feature set predicates which > are suitable for receivers to announce their capabilities (e.g. a predicate > which allows text/plain, text/paragraph, text/enriched or text/html) are > not necessarily suitable for senders to announce what they can offer (e.g. > application/word, text/html or text/plain). > > The predicates can still be based on the same algebra; it's just that > sender-side predicates are not necessarily useful for describing > receiver-side capabilities, and vice versa. > > Thus, a sender-side plain-text feature set predicate might include any MIME > text subtype which displays reasonably well when interpretted as text/plain. > > GK. > --- > > > At 12:40 04/03/98 -0800, Ted Hardie wrote: > >This is sort of the inverse of how I have been thinking of > >feature sets. If you create a feature set as > > > >fibl = (foo bar) > >kren = (baz gin) > >zeb = (fibl kren) > > > >If a clump of features gets to be common enough, it can > >have a feature name with the description equal to its > >component features or the clumps. You end up with a short > >feature name (zeb) for (foo bar baz gin). You could even > >make that declaration on the fly for some protocols. > > > >For MIME media types, there presumption isn't that > >features aggregate, but that features can be stripped in > >case of need (with some loss implied). That is, if you > >declare something to be text/something a user agent > >incapable of text/something should treat it like > >text/plain. That relationship and possibility would have > >to be understood before we tried to treat them as > >aggregable features; in particular, it would be > >problematic to treat application/ms-word in the same > >feature set text/html because the "default action" for > >them is different according to the MIME rules. > > > > regards, > > Ted Hardie > > NASA NIC > > > > > > > >On Mar 4, 12:16pm, Dan Wing wrote: > >> Establish a relationship between MIME types; for example, that > >> text/plain is a subset of other types (text/html and text/enriched, > >> obviously, and possibly others like application/msword, > >> application/wordperfect, application/postscript, etc.). At least, > >> that's what I thought one of your ideas was leading towards. > >> > >> Pretend this is set notation, perhaps something like this: > >> > >> text: text/plain < formatted-text > >> formatted-text: text/paragraph < text/enriched < text/html < > >word-processor > >> word-processor: application/word = application/wordperfect > >> > >> text < ( formatted-text = word-processor ) > >> > >> I don't know if this will scale, but I do already see problems that > >> some things are "equal" nor are some things really "supersets" of > >> other things in all respects. So this might be useless, but it is > >> only a brainstorm (watch out!). > >> > >> -Dan Wing > >>-- End of excerpt from Dan Wing > > > > > > > ------------ > Graham Klyne >-- End of excerpt from Graham Klyne From owner-ietf-medfree Thu Mar 5 14:16:53 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA01464 for ietf-medfree-bks; Thu, 5 Mar 1998 14:16:53 -0800 (PST) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.7.3) with SMTP id OAA01460 for ; Thu, 5 Mar 1998 14:16:52 -0800 (PST) Received: from casablanca.parc.xerox.com ([13.2.16.111]) by alpha.xerox.com with SMTP id <61272(1)>; Thu, 5 Mar 1998 14:11:56 PST Received: from bronze.parc.xerox.com ([13.1.103.244]) by casablanca.parc.xerox.com with SMTP id <71816>; Thu, 5 Mar 1998 13:02:10 PST Message-ID: <005601bd4879$f6637dc0$f467010d@bronze.parc.xerox.com> From: "Larry Masinter" To: "Koen Holtman" , "Graham Klyne" Cc: Subject: Re: Comments on draft-ietf-http-feature-reg-03.txt Date: Thu, 5 Mar 1998 13:02:09 PST MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-medfree@imc.org Precedence: bulk >>> [ ] 2a. With a name, keyword, label, or tag (e.g. a language tag) >> 2d. Other (represented as a US-ASCII character string) >I see 2d. as being isomorphic to 2a (i.e. no different in any significant >respect). I don't see the list of enumerated values as having to be closed >by the registration, and an arbitrary ASCII string would be allowable... The difference between an extensible set of enumerated values and a string which is not defined is that the former implies (usually) that "not equal means doesn't match", but arbitrary strings might have a different matching algorithm. Larry From owner-ietf-medfree Fri Mar 6 09:04:13 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id JAA23438 for ietf-medfree-bks; Fri, 6 Mar 1998 09:04:13 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id JAA23432 for ; Fri, 6 Mar 1998 09:04:12 -0800 (PST) Received: (qmail 12200 invoked from network); 6 Mar 1998 17:02:39 -0000 Received: from aj242.du.pipex.com (HELO sttnb) (193.130.249.242) by smtp.dial.pipex.com with SMTP; 6 Mar 1998 17:02:39 -0000 Message-Id: <3.0.32.19980306105914.0090e7b0@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 06 Mar 1998 17:01:09 +0000 To: "Larry Masinter" From: Graham Klyne Subject: Re: Comments on draft-ietf-http-feature-reg-03.txt Cc: "Koen Holtman" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 13:02 05/03/98 PST, Larry Masinter wrote: > >>>> [ ] 2a. With a name, keyword, label, or tag (e.g. a language tag) >>> 2d. Other (represented as a US-ASCII character string) > >>I see 2d. as being isomorphic to 2a (i.e. no different in any significant >>respect). I don't see the list of enumerated values as having to be closed >>by the registration, and an arbitrary ASCII string would be allowable... > > >The difference between an extensible set of enumerated values and a string which >is not defined is that the former implies (usually) that "not equal means doesn't match", >but arbitrary strings might have a different matching algorithm. This is precisely the sort of approach I am trying to steer away from. I am assuming that the "different matching algorithm" to which you refer is something which can exploit the internal structure of the string, and hence will introduce a range of structural elements into the media feature. If, on the other hand, you are referring to a different interpretation of "equality" (e.g. case insensitive matching), then I reassert my original claim of it being isomorphic to (2a), modulo variations of representation. This is similar to saying that '0xFF' is the same as '255' -- I don't thing you would argue for hexadecimal and decimal integers having different feature registration value types. As I said in a previous response, I am not opposed to having string values listed separately in the registration template, just as long as it is clear that we are not allowing a whole new set of semantics to creep in through a syntactical back-door. GK. --- ------------ Graham Klyne From owner-ietf-medfree Fri Mar 6 09:04:15 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id JAA23439 for ietf-medfree-bks; Fri, 6 Mar 1998 09:04:15 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id JAA23427 for ; Fri, 6 Mar 1998 09:04:10 -0800 (PST) Received: (qmail 12166 invoked from network); 6 Mar 1998 17:02:37 -0000 Received: from aj242.du.pipex.com (HELO sttnb) (193.130.249.242) by smtp.dial.pipex.com with SMTP; 6 Mar 1998 17:02:37 -0000 Message-Id: <3.0.32.19980306115353.0090d100@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 06 Mar 1998 17:01:07 +0000 To: hardie@nic.nasa.gov From: Graham Klyne Subject: Re: Comments on draft-ietf-http-feature-reg-03.txt Cc: hardie@nic.nasa.gov, dwing@Cisco.COM, koen@win.tue.nl (Koen Holtman), ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk Ted, I think we're having a violent agreement :-) Particularly, when you say: >I just want us to be recognize that they may work in some instances >but can't be assumed, [...] I interpret this as being similar to saying that a feature set predicate which applies to a sender may not be appropriate for describing a receiver or data file format. This, I think, is where 'bid' and 'offer' logic has to be considered. GK. --- At 13:55 05/03/98 -0800, Ted Hardie wrote: >Graham, > I agree that there are seperate issues here. I'm just >trying to make sure that we don't lose sight of the MIME rules >for interpreting things like text/html when we consider feature >sets. I see nothing wrong with creating a feature set that >contains features which apply to or are derived from more than >one MIME type; indeed, I suspect that those clusters will end >up being common and useful. Some of the message along the >way seemed to say something like > >text/html = (text/plain formatting) > >as a parallel to > >bez = (fipple bar) > >I just want us to be recognize that they may work in some instances >but can't be assumed, especially if you extend it to: > >rendered-poscript = (text/plain formattting) > >since postscript is an application. > >Hopefully this explanation of my concerns has not furthered muddied >the waters. > regards, > Ted Hardie > NASA NIC > > > > >On Mar 5, 7:22pm, Graham Klyne wrote: >> Subject: Re: Comments on draft-ietf-http-feature-reg-03.txt >> Ted, >> >> I broadly agree with what you say here. I hope you find my response to Dan >> explains how some of these ideas might be developed. >> >> To develop the argument, I think there are two separate issues raised here: >> >> (a) A capability for a recipient to handle some set of text file capabilities >> >> (b) A possibility for some advanced text file format to be interpretted as >> plain text. This depends in part on MIME processing rules that unknown >> text subtypes should be treated as text/plain [RFC 2046, sect 4.1.4]. I >> think this is an issue which is largely separate from the structure of >> content negotiation. >> >> >> What this debate does raise is the idea that feature set predicates which >> are suitable for receivers to announce their capabilities (e.g. a predicate >> which allows text/plain, text/paragraph, text/enriched or text/html) are >> not necessarily suitable for senders to announce what they can offer (e.g. >> application/word, text/html or text/plain). >> >> The predicates can still be based on the same algebra; it's just that >> sender-side predicates are not necessarily useful for describing >> receiver-side capabilities, and vice versa. >> >> Thus, a sender-side plain-text feature set predicate might include any MIME >> text subtype which displays reasonably well when interpretted as text/plain. >> >> GK. >> --- >> >> >> At 12:40 04/03/98 -0800, Ted Hardie wrote: >> >This is sort of the inverse of how I have been thinking of >> >feature sets. If you create a feature set as >> > >> >fibl = (foo bar) >> >kren = (baz gin) >> >zeb = (fibl kren) >> > >> >If a clump of features gets to be common enough, it can >> >have a feature name with the description equal to its >> >component features or the clumps. You end up with a short >> >feature name (zeb) for (foo bar baz gin). You could even >> >make that declaration on the fly for some protocols. >> > >> >For MIME media types, there presumption isn't that >> >features aggregate, but that features can be stripped in >> >case of need (with some loss implied). That is, if you >> >declare something to be text/something a user agent >> >incapable of text/something should treat it like >> >text/plain. That relationship and possibility would have >> >to be understood before we tried to treat them as >> >aggregable features; in particular, it would be >> >problematic to treat application/ms-word in the same >> >feature set text/html because the "default action" for >> >them is different according to the MIME rules. >> > >> > regards, >> > Ted Hardie >> > NASA NIC >> > >> > >> > >> >On Mar 4, 12:16pm, Dan Wing wrote: >> >> Establish a relationship between MIME types; for example, that >> >> text/plain is a subset of other types (text/html and text/enriched, >> >> obviously, and possibly others like application/msword, >> >> application/wordperfect, application/postscript, etc.). At least, >> >> that's what I thought one of your ideas was leading towards. >> >> >> >> Pretend this is set notation, perhaps something like this: >> >> >> >> text: text/plain < formatted-text >> >> formatted-text: text/paragraph < text/enriched < text/html < >> >word-processor >> >> word-processor: application/word = application/wordperfect >> >> >> >> text < ( formatted-text = word-processor ) >> >> >> >> I don't know if this will scale, but I do already see problems that >> >> some things are "equal" nor are some things really "supersets" of >> >> other things in all respects. So this might be useless, but it is >> >> only a brainstorm (watch out!). >> >> >> >> -Dan Wing >> >>-- End of excerpt from Dan Wing >> > >> > >> > >> ------------ >> Graham Klyne >>-- End of excerpt from Graham Klyne > > > ------------ Graham Klyne From owner-ietf-medfree Fri Mar 6 11:45:11 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA00199 for ietf-medfree-bks; Fri, 6 Mar 1998 11:45:11 -0800 (PST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA00195 for ; Fri, 6 Mar 1998 11:45:10 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA20308; Fri, 6 Mar 1998 14:43:40 -0500 (EST) Message-Id: <199803061943.OAA20308@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-medfree@imc.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-conneg-requirements-00.txt Date: Fri, 06 Mar 1998 14:43:39 -0500 Sender: owner-ietf-medfree@imc.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Negotiation Working Group of the IETF. Title : Requirements for protocol-independent content negotiation Author(s) : G. Klyne Filename : draft-ietf-conneg-requirements-00.txt Pages : 20 Date : 29-Dec-97 A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact. MIME media types [1, 2] provide a standard method for handling one major axis of variation, but resources also vary in ways which cannot be expressed using currently available MIME headers. The case for a cross-protocol negotiation framework is set out in [4]. This draft sets out terminology, an abstract framework and requirements for protocol-independent content negotiation, and identifies some technical issues which may need to be addressed. The abstract framework does not attempt to specify the content negotiation process, but gives an indication of the anticipated scope and form of any such specification. The requirements set out the desired properties of a content negotiation mechanism. Internet-Drafts are 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-ietf-conneg-requirements-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-conneg-requirements-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-conneg-requirements-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: <19980305135042.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-conneg-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-conneg-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980305135042.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-medfree Fri Mar 6 11:46:24 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA00222 for ietf-medfree-bks; Fri, 6 Mar 1998 11:46:24 -0800 (PST) Received: from wsooti08.win.tue.nl (wsooti08.win.tue.nl [131.155.70.156]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA00217 for ; Fri, 6 Mar 1998 11:46:22 -0800 (PST) Received: from koen@localhost by wsooti08.win.tue.nl (8.8.7) id UAA08914. Fri, 6 Mar 1998 20:44:38 +0100 (MET) From: koen@win.tue.nl (Koen Holtman) Message-Id: <199803061944.UAA08914@wsooti08.win.tue.nl> Subject: Re: Comments on draft-ietf-http-feature-reg-03.txt To: GK@ACM.ORG (Graham Klyne) Date: Fri, 6 Mar 1998 20:44:38 +0100 (MET) Cc: koen@win.tue.nl, ietf-medfree@imc.org In-Reply-To: <3.0.32.19980305121711.0093dc30@pop.dial.pipex.com> from "Graham Klyne" at Mar 5, 98 07:22:36 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ietf-medfree@imc.org Precedence: bulk Graham Klyne: > >At 21:29 04/03/98 +0100, Koen Holtman wrote: [...] >>I agree with most of whay you said on treating tags and their values >>as `primitive', but I think that 2d. should stay, maybe reformulated as >> >> 2d. Other (represented as a US-ASCII character string) > >I see 2d. as being isomorphic to 2a (i.e. no different in any significant >respect). I don't see the list of enumerated values as having to be closed >by the registration, and an arbitrary ASCII string would be allowable... OK, in that case we agree, except for one detail below. [...] >I do not seek to exclude the possibilities you are describing here: it is >just that I think that the separation between features and a combining >algebra should be clearly made. I agree, with out a clear separation we are lost. > >Indeed, I don't have a fundamental objection to the feature tag >registration allowing a string-values feature separately from the others >and even indicating a syntax for that string. But at the end of the day, >the string syntax should not be seen as implying any structure which can be >exploited by content negotiation: Here I disagree. I want to allow the writers if future protocols to add new `primitive types'. Even though TCN, or anything else we may want/need in the near future, does not support the less-than operator on x.y.z version numbers, it should be possible to define a negotiation protocol which does support this in future. You may think of this as a back door to not using the algebra, but I think of it as an escape hatch for cases where use of the algebra is not possible for some reason. >any such structure is, in my view, >something which should be represented in a feature set algebra. > >BTW, why limit "other" to being a US-ASCII character string: why not UTF-8? Hmm, there was no deep thought behind this choice, I just put it there as a reminder that specifying the charset of any string field in a protocol is now required. You can always use % encoding if you want to encode utf-8 into us-ascii of course. > >GK. Koen. From owner-ietf-medfree Fri Mar 6 11:49:44 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA00269 for ietf-medfree-bks; Fri, 6 Mar 1998 11:49:44 -0800 (PST) Received: from wsooti08.win.tue.nl (wsooti08.win.tue.nl [131.155.70.156]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA00265 for ; Fri, 6 Mar 1998 11:49:41 -0800 (PST) Received: from koen@localhost by wsooti08.win.tue.nl (8.8.7) id UAA08923. Fri, 6 Mar 1998 20:47:42 +0100 (MET) From: koen@win.tue.nl (Koen Holtman) Message-Id: <199803061947.UAA08923@wsooti08.win.tue.nl> Subject: Re: Another comment on draft-ietf-http-feature-reg-03.txt To: hardie@nic.nasa.gov Date: Fri, 6 Mar 1998 20:47:42 +0100 (MET) Cc: koen@win.tue.nl, andy_mutz@hp.com, ietf-medfree@imc.org In-Reply-To: <9803041414.ZM28846@thornhill.arc.nasa.gov> from "Ted Hardie" at Mar 4, 98 02:14:56 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ietf-medfree@imc.org Precedence: bulk Ted Hardie: > >On Mar 4, 9:59pm, Koen Holtman wrote: > >> 2b. that the feature tags for these local features could appear >> in variant lists visible on the internet (e.g. the company >> homepage has a variant which depends on a feature of the localised >> browsers) > >Is there a security concern here, or only a potential conflict concern? Mainly a potential conflict concern. >If the concern is potential conflicts, then the URL tags avoid the conflict >because they are unique. If there is a security concern that outside >users might detect the use of some feature meants only for internal >users, then we might want security consideration language like: > >"Those creating URL tags to identify features available only to internal >users may wish to restrict their release in feature lists made available >to the public Internet." I believe this is already covered as a sub-case of the current security considerations section. Koen. From owner-ietf-medfree Fri Mar 6 12:54:27 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA00961 for ietf-medfree-bks; Fri, 6 Mar 1998 12:54:27 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id MAA00957 for ; Fri, 6 Mar 1998 12:54:24 -0800 (PST) Received: (qmail 24113 invoked from network); 6 Mar 1998 20:52:56 -0000 Received: from am099.du.pipex.com (HELO sttnb) (193.130.252.99) by smtp.dial.pipex.com with SMTP; 6 Mar 1998 20:52:56 -0000 Message-Id: <3.0.32.19980306204401.00862750@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 06 Mar 1998 20:51:26 +0000 To: koen@win.tue.nl (Koen Holtman) From: Graham Klyne Subject: Re: Comments on draft-ietf-http-feature-reg-03.txt Cc: koen@win.tue.nl, ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 20:44 06/03/98 +0100, Koen Holtman wrote: >>Indeed, I don't have a fundamental objection to the feature tag >>registration allowing a string-values feature separately from the others >>and even indicating a syntax for that string. But at the end of the day, >>the string syntax should not be seen as implying any structure which can be >>exploited by content negotiation: > >Here I disagree. I want to allow the writers if future protocols to >add new `primitive types'. Even though TCN, or anything else we may >want/need in the near future, does not support the less-than operator >on x.y.z version numbers, it should be possible to define a >negotiation protocol which does support this in future. You may think >of this as a back door to not using the algebra, but I think of it as >an escape hatch for cases where use of the algebra is not possible for >some reason. In this case, I have no problem with what you are suggesting. What I see here is the idea that a text-valued feature may have defined '<' and '==' operators whose interpretation is based on some structural analysis of the text value. This, I see as being algebraically isomorphic (in this context) to a numeric value, and as such does not break any algebraic framework I would anticipate. I agree that, in this case, to try and force this world-view (of isomorphism with enumerations or numbers) onto the registration template would be extreme. Thus, I am persuaded that the possibility of introducing new values (such as multi-facet version numbers) with their own comparison rules would be a useful option in the registration template. Assuming (for the moment) that the idea of also registering ASN.1 formats finds wider approval, I assume text values such as you propose would be represented as ASN.1 OCTET STRING values, or similar, with separately defined comparison rules applied on a per-type basis (as is done for LDAP/X.500). (I note that the S/MIME group are currently discussing how to handle a UTF-8 string in an ASN.1 spec.) My only concern, then, is how one would present the registration template in such a way that the existing algebraic operations on features (equality, less-than and logical derivatives) could be defined, without opening a back-door to new algebraic options which would break the algebraic framework (which we agree should be a separate issue). GK. --- ------------ Graham Klyne From owner-ietf-medfree Fri Mar 6 13:05:31 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA01111 for ietf-medfree-bks; Fri, 6 Mar 1998 13:05:31 -0800 (PST) Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id NAA01107 for ; Fri, 6 Mar 1998 13:05:17 -0800 (PST) Received: from hplumen.cup.hp.com (hplumen.cup.hp.com [15.0.90.200]) by palrel3.hp.com (8.8.5/8.8.5tis) with ESMTP id NAA23209; Fri, 6 Mar 1998 13:03:20 -0800 (PST) Received: (from mutz@localhost) by hplumen.cup.hp.com (8.7.1/8.7.1) id NAA04659; Fri, 6 Mar 1998 13:04:51 -0800 (PST) From: Andy Mutz Message-Id: <199803062104.NAA04659@hplumen.cup.hp.com> Subject: Re: Comments on draft-ietf-http-feature-reg-03.txt To: GK@ACM.ORG (Graham Klyne) Date: Fri, 06 Mar 1998 13:04:46 PST Cc: hardie@nic.nasa.gov, dwing@Cisco.COM, koen@win.tue.nl, ietf-medfree@imc.org In-Reply-To: <3.0.32.19980306115353.0090d100@pop.dial.pipex.com>; from "Graham Klyne" at Mar 06, 98 5:01 pm Reply-to: andy_mutz@hp.com Organization: Hewlett-Packard Laboratories, Palo Alto, California X-Mailer: Elm [revision: 212.2] Sender: owner-ietf-medfree@imc.org Precedence: bulk Schedule demands and lots of recent comments slowed me down - I'll get a new feature-reg draft out Monday. Thanks, Andy Mutz -- --------------------------------------------------------------- Andrew Mutz | email: andy_mutz@hp.com Internet Imaging Operation | Phone: +1 408 447 4439 Imaging Solutions Division | Page: +1 888 502 7333 11000 Wolfe Road 42UO | Cupertino, California, USA. | Radio: KF6FUT --------------------------------------------------------------- From owner-ietf-medfree Wed Mar 11 22:26:17 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id WAA04528 for ietf-medfree-bks; Wed, 11 Mar 1998 22:26:17 -0800 (PST) Received: from mail.olg.com (olg.com [205.177.168.3]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id WAA04524 for ; Wed, 11 Mar 1998 22:26:15 -0800 (PST) Date: Wed, 11 Mar 1998 22:26:15 -0800 (PST) From: cd@caliver-a.org Received: from nai (unverified [208.133.166.23]) by mail.olg.com (Rockliffe SMTPRA 2.1.4) with SMTP id ; Thu, 12 Mar 1998 01:14:25 -0500 Message-ID: Sender: owner-ietf-medfree@imc.org Precedence: bulk DATA To: Date: Thu, 12 Mar 1998 01:12:08 PST Subject: Hackers Secrets 5 CD-Rom X-Mailer: Emailer Platinum 3.1 (tm) by Internet Marketing Inc. Wanna own the #1 selling CD on the Internet today?! HACKERS SECRETS 5 is now available! New 1998 Version The fourth version of our growing collection of Hacking Informational CD's. It is packed with some info that you might not even heard of yet. Features an exclusive HTML browser mode that allows for click & go interface. Go throughfiles as if they were a web page. Includes Netscape 4.0 right on the disk (windows95 and NT version) Here are just some of the subjects covered! Everything you ever wanted to know but were afraid to ask! Anarchists Book Shop Credit Card Numbers Communications Electronics Cracking Files Group 42 Archieves Internet Phreaking Warez Lock Picking Pyrotechnics & Explosives Satalite & TV hacking Underground Magazines Video Games & Consoles Hackers Took Kit Weapons Hackers favorite web sites Software Serial Numbers UFO Stuff And that's just the tip of the iceberg! There are literally 1000's of subjects & categories covered in this brand new CD-ROM.This release is better than all of our previous releases combined. You will find stuff here that you never thought possible. IMPORTANT NOTICE! The acts described in this CD are not condoned by the publishers & should not be attempted. The information itself is legal while the usage of such info. may be illegal. The CD is for information & educational purposes only! Many Hours of Fun Reading is Yours !!! To get your copy today, send $12.95 which includes shipping & handeling , check or money order form to : DATANET 105 Meadow Street Apt#3 Seymour, CT 06483 CD's will be sent out same day for money orders , allow 10 days for checks to clear & your CD-ROM will be sent. From owner-ietf-medfree Thu Mar 12 06:49:38 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id GAA20180 for ietf-medfree-bks; Thu, 12 Mar 1998 06:49:38 -0800 (PST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id GAA20176 for ; Thu, 12 Mar 1998 06:49:37 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA15763; Thu, 12 Mar 1998 09:48:30 -0500 (EST) Message-Id: <199803121448.JAA15763@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-medfree@imc.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-conneg-feature-algebra-00.txt Date: Thu, 12 Mar 1998 09:48:29 -0500 Sender: owner-ietf-medfree@imc.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Negotiation Working Group of the IETF. Title : An algebra for describing media feature sets Author(s) : G. Klyne Filename : draft-ietf-conneg-feature-algebra-00.txt Pages : 16 Date : 11-Mar-98 A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact [1]. A framework for such negotiation is described in [2]. Part of this framework is a way to describe the range of media features which can be handled by the sender, recipient or document transmission format of a message. A format for a vocabulary of individual media features and procedures for registering media features are presented in [3]. This document describes an algebra which can be used to define feature sets which are formed from combinations and relations involving individual media features. Such feature sets are used to describe the media feature handling capabilities of message senders, recipients and file formats. This document does not set out to specify a syntax for defining feature sets. Internet-Drafts are 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-ietf-conneg-feature-algebra-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-conneg-feature-algebra-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-conneg-feature-algebra-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: <19980311152104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-conneg-feature-algebra-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-conneg-feature-algebra-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980311152104.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-medfree Thu Mar 12 12:53:49 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA22871 for ietf-medfree-bks; Thu, 12 Mar 1998 12:53:49 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id MAA22867 for ; Thu, 12 Mar 1998 12:53:48 -0800 (PST) Received: (qmail 13354 invoked from network); 12 Mar 1998 20:52:48 -0000 Received: from ac204.du.pipex.com (HELO sttnb) (193.130.242.204) by smtp.dial.pipex.com with SMTP; 12 Mar 1998 20:52:48 -0000 Message-Id: <3.0.32.19980312183559.0084d100@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 12 Mar 1998 20:51:10 +0000 To: andy_mutz@hp.com From: Graham Klyne Subject: Re: draft-ietf-conneg-feature-reg-00.txt Cc: conneg WG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk Andy, Comments below. They are matters of detail -- I am generally comfortable with the broad framework. I might want to make some more suggestions regarding language later, but I look to see consensus on the framework first. GK. --- At 02:07 12/03/98 -0800, Andrew Mutz wrote: >2 Feature tag definitions > >2.1 Feature tag purpose > > Content feature tags represent individual and simple dimensions of > feature capability. Examples of content features related to media > are: > > * the color depth of the screen on which something is to be displayed > * the support of the `floating 5 dimensional tables' feature > * the type of paper available in a printer > * the fonts which are available to the recipient > * the capability to display graphical content > > A feature tag identifies a single dimension of characteristic. Feature > tag values should be represented as(and must be representable or > isomorphic to) boolean, enumerated values, or numeric values. > Examples of feature tags are defined in detail elsewhere [4]. > > > Many features are not Boolean and require values to qualify them. > Examples of feature tags with values are: > * the width of a display in pixels represented as an integer value. > * the fonts available to a recipient as an enumerated list. > * the version of a protocol composed of integers "i.j.k", defined as > either a value in an enumerated list or isomorphic to the integer > numeric value ijk. ...----------------->...................<--------------------------- I think care is needed here with "isomorphic". I suggest # * the version of a protocol composed of integers "i.j.k", defined as # either a value in an ordered enumerated list, or with a defined mapping # to make the value isomorphic to a subset of integers (e.g. i*100+j*10+k, # assuming j<=9 and k<=9). (I suggest an ordered enumerated list on the assumption that one wants to be able to have an ordering relation on a protocol version as well as an equality test.) >2.2 Feature tag syntax > > A feature tag is a string consisting of one or more of the following > US-ASCII characters: uppercase letters, lowercase letters, digits, > colon (":"), slash ("/"), dot (".") and dash ("-"). Feature tags are > case-insensitive. Dots are understood to potentially imply heirarchy; > a feature can be subtyped by describing it as tree.feature.subfeature > and by indicating this in the feature registration. A small point: I assume that colon and slash are included to allow URIs as feature tag names? Is there a potential conflict, or confusion, between hierarchical faceted names and URIs? I am thinking that it might be clearer to allow faceted names with components containing letters, digits and '-', OR a name in URI syntax. The latter is distinguished by the leading 'scheme:'. It's just a thought. > A feature tag value is a string consisting of one or more of the > following US-ASCII characters: uppercase letters, lowercase letters, > digits, colon (":"), slash("/"), dot("."), and dash ("-"). Values are > case-insensitive. Feature tag values should be simple atomic values > of either enumerated or numeric form and must be isomorphic with > either enumerated or numeric values. The form of feature tag values > is indicated upon feature registration. I think we may wish to be able to enumerate arbitrary text values, so a form which allows an arbitrary quoted string maybe should be allowed. For example, using a manufacturer name to identify a class of equipment. I am suggesting something like: feature-value = token | integer | rational | quoted-string I would then suggest that if the registration allows quoted-string values then an ordering relation is provided only iff the registration states how it is defined. The only other system I can think of offhand which faces this kind of problem is X.500/LDAP directories, and they have comparison rules associated with attribute types which are separately defined and registered. But, at the end of the day, the algebra is limited to logical combinations of: equality, ordering, approximate-equality and limited pattern-matching operations QUESTION: should we allow the registration to indicate different representations for numeric values (e.g. decimal, hex, C-language, etc. for integers, or fixed-point, scientific, x/y ratio for rationals)? ------------ Graham Klyne From owner-ietf-medfree Fri Mar 13 02:53:00 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id CAA11173 for ietf-medfree-bks; Fri, 13 Mar 1998 02:53:00 -0800 (PST) Received: from salmon.heicomm.net (addr-51.heicomm.net [206.251.81.51] (may be forged)) by mail.proper.com (8.8.8/8.7.3) with ESMTP id CAA11169 for ; Fri, 13 Mar 1998 02:52:55 -0800 (PST) Received: from t.tt (hdn86-012.hil.compuserve.com [206.175.97.12]) by salmon.heicomm.net (8.8.5/8.8.3) with SMTP id CAA23020; Fri, 13 Mar 1998 02:43:45 -0800 (PST) Date: Fri, 13 Mar 1998 02:43:45 -0800 (PST) From: 8u77y6tg <8u77y6tg@worldnet.att.net> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Thursday, March 12th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Tuesday, March 10th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Sunday, March 8th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Saturday, March 7th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Friday, March 13th, 1998 Reply-To: 8u77y6tg@worldnet.att.net Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <8u77y6tg@worldnet.att.net> Subject: S Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Fri Mar 13 05:24:59 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id FAA13547 for ietf-medfree-bks; Fri, 13 Mar 1998 05:24:59 -0800 (PST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id FAA13543 for ; Fri, 13 Mar 1998 05:24:58 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA25585; Fri, 13 Mar 1998 08:24:02 -0500 (EST) Message-Id: <199803131324.IAA25585@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-medfree@imc.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-conneg-feature-reg-00.txt Date: Fri, 13 Mar 1998 08:24:01 -0500 Sender: owner-ietf-medfree@imc.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Negotiation Working Group of the IETF. Title : Content Feature Tag Registration Procedure Author(s) : E. Hardie, K. Holtman, A. Mutz Filename : draft-ietf-conneg-feature-reg-00.txt Pages : 7 Date : 12-Mar-98 Recent Internet applications, such as the World Wide Web, tie together a great diversity in data formats, client and server platforms, and communities. This has created a need for content feature descriptions and negotiation mechanisms in order to identify and reconcile the form of information to the capabilities and preferences of the parties involved. Extensible content feature identification and negotiation mechanisms require a common vocabulary in order to positively identify content features. A registration process and authority for content features is defined with the intent of sharing this vocabulary between communicating parties. In addition, a URI tree is defined to enable sharing of content feature definitions without registration. This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the content feature vocabulary. Internet-Drafts are 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-ietf-conneg-feature-reg-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-conneg-feature-reg-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-conneg-feature-reg-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: <19980312131738.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-conneg-feature-reg-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-conneg-feature-reg-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980312131738.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-medfree Fri Mar 13 05:24:26 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id FAA13538 for ietf-medfree-bks; Fri, 13 Mar 1998 05:24:26 -0800 (PST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id FAA13534 for ; Fri, 13 Mar 1998 05:24:25 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA25342; Fri, 13 Mar 1998 08:23:28 -0500 (EST) Message-Id: <199803131323.IAA25342@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-medfree@imc.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-conneg-media-features-00.txt Date: Fri, 13 Mar 1998 08:23:28 -0500 Sender: owner-ietf-medfree@imc.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Negotiation Working Group of the IETF. Title : Media Features for Display, Print, and Fax Author(s) : L. Masinter, K. Holtman, A. Mutz, D. Wing Filename : draft-ietf-conneg-media-features-00.txt Pages : 4 Date : 12-Mar-98 This specification defines some common media features for describing image resolution, size, color, and image representation methods that are common to web browsing, printing, and facsimile applications. These features are registered for use within the framework of [REG]. Internet-Drafts are 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-ietf-conneg-media-features-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-conneg-media-features-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-conneg-media-features-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: <19980312121518.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-conneg-media-features-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-conneg-media-features-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980312121518.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-medfree Sat Mar 14 02:14:06 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id CAA11928 for ietf-medfree-bks; Sat, 14 Mar 1998 02:14:06 -0800 (PST) Received: from dynacom.net (2425.dynacom.net [208.8.143.254]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id CAA11924 for ; Sat, 14 Mar 1998 02:14:05 -0800 (PST) Received: by dynacom.net from localhost (router,SLMail V2.6); Sat, 14 Mar 1998 02:14:02 +0800 Received: by dynacom.net from t.tt (206.175.107.10::mail daemon; unverified,SLMail V2.6); Sat, 14 Mar 1998 02:13:55 +0800 From: 93442d <93442d@ix.netcom.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Friday, March 13th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Wednesday, March 11th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Monday, March 9th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Sunday, March 8th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Saturday, March 14th, 1998 Reply-To: 93442d@ix.netcom.com Date: Sat, 14 Mar 1998 02:14:02 +0800 Subject: None Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <93442d@ix.netcom.com> Subject: Saturday Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: 7 Email address lists export in many different formats (HTML, Comma delimited, text file) 7 Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom 7 Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Mon Mar 16 13:07:11 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA22208 for ietf-medfree-bks; Mon, 16 Mar 1998 13:07:11 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id NAA22204 for ; Mon, 16 Mar 1998 13:07:10 -0800 (PST) Received: (qmail 21922 invoked from network); 16 Mar 1998 21:06:31 -0000 Received: from al160.du.pipex.com (HELO sttnb) (193.130.251.160) by smtp.dial.pipex.com with SMTP; 16 Mar 1998 21:06:31 -0000 Message-Id: <3.0.32.19980316210332.009d4bc0@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 16 Mar 1998 21:04:46 +0000 To: conneg WG From: Graham Klyne Subject: Where are we now? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk All, In an attempt to gain some understanding of what we have achieved and what needs to be done next, this is my perception of where we stand... (a) there is broad agreement with the framework for media feature registration (draft-ietf-conneg-feature-reg-00.txt). One issue which, in my mind, is unresolved is whether the registration should cover ASN.1 encodings as well as textual representations for features. (b) there seems to be no fundamental disagreement, and some agreement, with the idea that feature sets can be described by predicates (per draft-ietf-conneg-feature-algebra-00.txt). (c) there has been very little feedback concerning the content negotiation requirements and framework document (draft-ietf-conneg-requirements-00.txt). Substantial portions of this are terminology lifted from other documents. Verbal discussions seem to suggest no major disagreement with the framework approach suggested. I did expect a few of the stated requirements to be controversial, but many were lifted from other sources of comments to the list, so I am tempted to assume that the broad thrust of this is OK even though I expect some details to be challenged yet. To my mind there are four main areas which need to be developed next: (1) Discussion on whether we wish to restrict consideration to textual representations, or to also encompass ASN.1. (2) concrete representations for feature sets (based upon the predicate algebra approach). (3) registration of feature sets. (4) expression of preferences. My views: (1) Given the cross-protocol nature of this effort, and the fact that many Internet protocols are ASN.1 based, I think the ASN.1 representation of media features and feature sets SHOULD be addressed. (2) (a) the registration draft gives us a basic vocabulary, (b) LDAP search filters provide one possible syntax for basing the representation of feature sets (which is also consistent with the proposed properties of "primitive" media features) (c) Larry et. al. have suggested, in the examples in the "media features" draft (draft-ietf-conneg-media-features-00.txt), some additional syntax elements which would likely prove convenient for expressing some common feature sets. (3) It has been suggested by someone else (I forget who) that registration of feature sets for use as media features might be helpful. I support this approach -- I think it will prove a useful way to capture more complex media feature combinations in a convenient fashion, given the simple nature of individual media features. To my mind, this raises a number of questions: (a) should feature sets occupy the same namespace as media features? I think "yes". (A thought I had in respect of this was the possibility that a URI-name for a feature set might actually resolve to a URL containing the feature predicate. I'm not convinced that this is a Good Idea, but it's a thought.) (b) should feature sets be parameterized? To pick a trivial example: res(R) ::= ( res-x <= R ) & ( res-y <= R ) This starts to look quite powerful, but does it get too complex to implement? Because the predicates are essentially functional in nature, hence referentially transparent, I think a simple implementation based on macro substitution could work, so the implementation doesn't need to be too difficult. (c) If we parameterize feature sets, should multiple parameters be allowed? E.G. res(X,Y) ::= ( res-x <= X ) & ( res-y <= Y ) (4) Preferences is one area where I have not had many ideas that I feel I could develop into some kind of solution. I still think that "simplifying assumptions" are needed, as there are too many possible ways to rank an arbitrary pair of feature collections, but I'm not clear what those assumptions should be. Any ideas? GK. --- ------------ Graham Klyne From owner-ietf-medfree Mon Mar 16 13:59:53 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA22808 for ietf-medfree-bks; Mon, 16 Mar 1998 13:59:53 -0800 (PST) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.7.3) with SMTP id NAA22804 for ; Mon, 16 Mar 1998 13:59:52 -0800 (PST) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA05548 for ietf-medfree@imc.org; Mon, 16 Mar 1998 13:59:15 -0800 Date: Mon, 16 Mar 1998 13:59:15 -0800 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9803161359.ZM5546@thornhill.arc.nasa.gov> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: ietf-medfree@imc.org Subject: Agenda for L.A. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk We are currently scheduled for one two-hour slot from 3:30 to 5:30 on Thursday, April 2,1998. We have four drafts currently in process within the group: ftp://ds.internic.net/internet-drafts/draft-ietf-conneg-feature-algebra-00.txt ftp://ds.internic.net/internet-drafts/draft-ietf-conneg-feature-reg-00.txt ftp://ds.internic.net/internet-drafts/draft-ietf-conneg-media-features-00.txt ftp://ds.internic.net/internet-drafts/draft-ietf-conneg-requirements-00.txt and ftp://ds.internic.net/internet-drafts/draft-ietf-fax-mdn-features-01.txt from the ietf-fax working group. I currently would like to split up the time as: 5 minutes agenda bashing 25 minutes feature registration draft 20 minutes media features draft 20 minutes mdn-features draft 20 minutes requirements draft 20 minutes Algebra draft 10 minutes update of charter Please let me know as soon as possible if there are other drafts which we need to discuss at this meeting. This ordering of discussion is, by the way, meant to move from the concrete to the abstract, as I believe we can do that more swiftly and appropriately than moving from the abstract to the concrete. I believe, however, we will need to keep all of the drafts in mind as we go through each of them, so please read them all carefully before the meeting. regards, Ted Hardie NASA NIC From owner-ietf-medfree Mon Mar 16 15:03:45 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA23364 for ietf-medfree-bks; Mon, 16 Mar 1998 15:03:45 -0800 (PST) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.7.3) with SMTP id PAA23360 for ; Mon, 16 Mar 1998 15:03:44 -0800 (PST) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA05686; Mon, 16 Mar 1998 15:02:39 -0800 Date: Mon, 16 Mar 1998 15:02:39 -0800 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9803161502.ZM5684@thornhill.arc.nasa.gov> In-Reply-To: Graham Klyne "Where are we now?" (Mar 16, 9:04pm) References: <3.0.32.19980316210332.009d4bc0@pop.dial.pipex.com> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: Graham Klyne , conneg WG Subject: Re: Where are we now? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk Graham, Thanks for your summary below. I agree with you that we need to resolve the ASN.1 issue, but I think we differ on how to do so. Your concern, as I understand it, is that the same feature might be assigned different ASN.1 OIDs by different organizations, and that this might lead to problems when these are used in a feature exchange. Given the highly delegated nature of ASN.1 OIDs, it does seem possible that different organizations would assign OIDs to the same feature, but it does not seem likely to me that feature negotiation on differing OIDs will occur if there is a registered feature name for them. I would expect that allowing the registering organization to give its ASN.1 designation for the feature as it registered it would be enough to avoid conflict. If a registered feature had an ASN.1 OID associated with it, that could be used in the negotiation; otherwise, negotiation would have to proceed with the name. I don't think it is necessary for IANA to assign the OIDs, and I don't really want to require others to assign them, as many registrants may not want to go through the hassle of managing a delegated portion of the ASN.1 namespace. In addition to further discussion of the ASN.1 issue, I think we need a close review of whether the registration document does what it needs to to meet the requirements in ftp://ds.internic.net/internet-drafts/draft-iesg-iana-considerations-01.txt Like you, I believe that we need to make the registration of feature sets possible; I think, though, that we want to get feature registration right first and then allow feature set registration. If we can keep the definition of "feature" loose enough to allow feature sets within "feature", that's great, but I'm not greatly opposed to having feature sets be identifiably different from features in registration procedure and reference. It's not my preference, but if that is the way it needs to work to get features out the door, I'm okay with it. I have not yet given enough thought to conneg-requirements and feature-algebra to be very useful in a discussion of them. I will give them that focus in the next week, and I hope others will as well (that's kind of what the IETF meetings are for, in my opinion; to provide a deadline for the drafts to get written and read!). best regards, Ted Hardie NASA NIC On Mar 16, 9:04pm, Graham Klyne wrote: > Subject: Where are we now? > All, > > In an attempt to gain some understanding of what we have achieved and what > needs to be done next, this is my perception of where we stand... > > (a) there is broad agreement with the framework for media feature > registration (draft-ietf-conneg-feature-reg-00.txt). One issue which, in > my mind, is unresolved is whether the registration should cover ASN.1 > encodings as well as textual representations for features. > > (b) there seems to be no fundamental disagreement, and some agreement, with > the idea that feature sets can be described by predicates (per > draft-ietf-conneg-feature-algebra-00.txt). > > (c) there has been very little feedback concerning the content negotiation > requirements and framework document > (draft-ietf-conneg-requirements-00.txt). Substantial portions of this are > terminology lifted from other documents. Verbal discussions seem to > suggest no major disagreement with the framework approach suggested. I did > expect a few of the stated requirements to be controversial, but many were > lifted from other sources of comments to the list, so I am tempted to > assume that the broad thrust of this is OK even though I expect some > details to be challenged yet. > > > To my mind there are four main areas which need to be developed next: > > (1) Discussion on whether we wish to restrict consideration to textual > representations, or to also encompass ASN.1. > > (2) concrete representations for feature sets (based upon the predicate > algebra approach). > > (3) registration of feature sets. > > (4) expression of preferences. > > > My views: > > (1) Given the cross-protocol nature of this effort, and the fact that many > Internet protocols are ASN.1 based, I think the ASN.1 representation of > media features and feature sets SHOULD be addressed. > > (2) (a) the registration draft gives us a basic vocabulary, > (b) LDAP search filters provide one possible syntax for basing the > representation of feature sets (which is also consistent with the proposed > properties of "primitive" media features) > (c) Larry et. al. have suggested, in the examples in the "media features" > draft (draft-ietf-conneg-media-features-00.txt), some additional syntax > elements which would likely prove convenient for expressing some common > feature sets. > > (3) It has been suggested by someone else (I forget who) that registration > of feature sets for use as media features might be helpful. > I support this approach -- I think it will prove a useful way to capture > more complex media feature combinations in a convenient fashion, given the > simple nature of individual media features. To my mind, this raises a > number of questions: > (a) should feature sets occupy the same namespace as media features? I > think "yes". > (A thought I had in respect of this was the possibility that a URI-name for > a feature set might actually resolve to a URL containing the feature > predicate. I'm not convinced that this is a Good Idea, but it's a thought.) > (b) should feature sets be parameterized? To pick a trivial example: > res(R) ::= ( res-x <= R ) & ( res-y <= R ) > This starts to look quite powerful, but does it get too complex to > implement? Because the predicates are essentially functional in nature, > hence referentially transparent, I think a simple implementation based on > macro substitution could work, so the implementation doesn't need to be too > difficult. > (c) If we parameterize feature sets, should multiple parameters be allowed? > E.G. > res(X,Y) ::= ( res-x <= X ) & ( res-y <= Y ) > > (4) Preferences is one area where I have not had many ideas that I feel I > could develop into some kind of solution. I still think that "simplifying > assumptions" are needed, as there are too many possible ways to rank an > arbitrary pair of feature collections, but I'm not clear what those > assumptions should be. Any ideas? > > GK. > --- > > ------------ > Graham Klyne >-- End of excerpt from Graham Klyne From owner-ietf-medfree Tue Mar 17 11:38:10 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA15878 for ietf-medfree-bks; Tue, 17 Mar 1998 11:38:10 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id LAA15873 for ; Tue, 17 Mar 1998 11:38:09 -0800 (PST) Received: (qmail 4194 invoked from network); 17 Mar 1998 19:37:35 -0000 Received: from ao081.du.pipex.com (HELO sttnb) (193.130.254.81) by smtp.dial.pipex.com with SMTP; 17 Mar 1998 19:37:35 -0000 Message-Id: <3.0.32.19980317102728.007af590@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 17 Mar 1998 19:35:46 +0000 To: hardie@nic.nasa.gov From: Graham Klyne Subject: Re: Where are we now? Cc: conneg WG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk Ted, At 15:02 16/03/98 -0800, Ted Hardie wrote: > In addition to further discussion of the ASN.1 issue, >I think we need a close review of whether the registration document >does what it needs to to meet the requirements in > >ftp://ds.internic.net/internet-drafts/draft-iesg-iana-considerations-01.txt New one posted today. A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-iesg-iana-considerations-03.txt I'll plan to read it before the meeting! > Like you, I believe that we need to make the registration of >feature sets possible; I think, though, that we want to get feature >registration right first and then allow feature set registration. I am happy with this. >... If >we can keep the definition of "feature" loose enough to allow feature >sets within "feature", that's great, but I'm not greatly opposed to >having feature sets be identifiably different from features in >registration procedure and reference. It's not my preference, but if >that is the way it needs to work to get features out the door, I'm >okay with it. One reason I posed the question of parameterization of features was to raise awareness of possible implications for the feature registry *if* we wanted it to also cover feature sets. A single parameter associated with a feature set would have the same general form as a media feature. Multiple parameters would extend the semantic framework. If feature set registration were covered by a document separate from feature registration, could they still share a namespace? That sounds as if it could be tricky from an IANA perspective. > I have not yet given enough thought to conneg-requirements >and feature-algebra to be very useful in a discussion of them. I >will give them that focus in the next week, and I hope others will >as well (that's kind of what the IETF meetings are for, in my opinion; >to provide a deadline for the drafts to get written and read!). In my view, these documents are more means to an end than ends in themselves. The requirements/framework document to provide some common view of what we are trying to achieve mid- to long- term, and the algebra document to provide a consistent foundation for describing complex capabilities. One thing which I think really does need developing is the idea of expressing preferences -- that is one area regarding which little has been proposed in this forum. I haven't yet found a "handle" to give me a good purchase on this particular problem. GK. --- ------------ Graham Klyne From owner-ietf-medfree Tue Mar 17 11:38:08 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA15868 for ietf-medfree-bks; Tue, 17 Mar 1998 11:38:08 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id LAA15864 for ; Tue, 17 Mar 1998 11:38:07 -0800 (PST) Received: (qmail 4187 invoked from network); 17 Mar 1998 19:37:33 -0000 Received: from ao081.du.pipex.com (HELO sttnb) (193.130.254.81) by smtp.dial.pipex.com with SMTP; 17 Mar 1998 19:37:33 -0000 Message-Id: <3.0.32.19980317100448.007a8100@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 17 Mar 1998 19:35:44 +0000 To: hardie@nic.nasa.gov From: Graham Klyne Subject: ASN.1 (was: Where are we now?) Cc: conneg WG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk Ted, Taking the ASN.1 issue from your response. I don't yet have a strong view -- still exploring the options... At 15:02 16/03/98 -0800, Ted Hardie wrote: >Graham, > Thanks for your summary below. I agree with you that we need >to resolve the ASN.1 issue, but I think we differ on how to do so. >Your concern, as I understand it, is that the same feature might be >assigned different ASN.1 OIDs by different organizations, and that >this might lead to problems when these are used in a feature exchange. [...] >I would expect that allowing the registering organization to >give its ASN.1 designation for the feature as it registered it would >be enough to avoid conflict. If a registered feature had an ASN.1 OID >associated with it, that could be used in the negotiation; otherwise, >negotiation would have to proceed with the name. I don't think it is >necessary for IANA to assign the OIDs, and I don't really want to >require others to assign them, as many registrants may not want to go >through the hassle of managing a delegated portion of the ASN.1 >namespace. OK... Given that we are talking about assigning meanings to tokens, the important thing from a cross-protocol PoV seems to be agreement on the "meaning", and as long as participants in a given protocol use the same refering "token". There's little harm if different protocols use different tokens. (I see there is practical value in having a common textual syntax, because the descriptions tend to be longer and a common reference saves design effort.) So I can agree that ASN.1 OID designations do not need to be mandatory. (I don't really feel that your suggestion to use the textual form wthin ASN.1 protocols is a Good Idea -- it seems to me to be a "worst of all worlds" type of approach. But not being an expert here I am prepared to bow to better-informed opinion.) QUESTION: should the registration provide for an *optional* ASN.1 assignment in a standard IANA sub-tree? This would not involve the registering party in "the hassle of managing a delegated portion of the ASN.1 namespace", but if the registration *were* made then it could save others from precisely this hassle in the futire if they wish to use the feature with ASN.1-based protocols. As I see it, the IANA responsibility here would be (1) to assign a sub-tree of IANA-managed OID-space (a one-off activity), and (2) assign a unique integer identifier for each feature which is registered with an OID. Something which I can imagine might prove problematic is allowing organizations to define their own OIDs in a registration -- what are the guarantees that the corresponding OID sub-namespace will be appropriately managed in the future? ANOTHER QUESTION: if we do not address the OID issue now, how difficult would it be to retrospectively add OIDs to feature registrations in the future? I suspect that the answer is "not too difficult" (e.g. an update to the registration document and a simple separate OID/feature-name register might do the trick). GK. --- ------------ Graham Klyne From owner-ietf-medfree Tue Mar 17 11:37:47 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA15845 for ietf-medfree-bks; Tue, 17 Mar 1998 11:37:47 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id LAA15841 for ; Tue, 17 Mar 1998 11:37:46 -0800 (PST) Received: (qmail 4098 invoked from network); 17 Mar 1998 19:37:12 -0000 Received: from ao081.du.pipex.com (HELO sttnb) (193.130.254.81) by smtp.dial.pipex.com with SMTP; 17 Mar 1998 19:37:12 -0000 Message-Id: <3.0.32.19980317151453.00914b10@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 17 Mar 1998 19:35:23 +0000 To: conneg WG From: Graham Klyne Subject: draft-ietf-conneg-feature-reg-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk This document contains: >2.2 Feature tag syntax > > A feature tag is a string consisting of one or more of the following > US-ASCII characters: uppercase letters, lowercase letters, digits, > colon (":"), slash ("/"), dot (".") and dash ("-"). Feature tags are > case-insensitive. Dots are understood to potentially imply heirarchy; > a feature can be subtyped by describing it as tree.feature.subfeature > and by indicating this in the feature registration. Do we want to require also that the first character is a letter? Would some ABNF be helpful? Referencing RFC 2234, the following might be offered: Feature-tag = ALPHA *( ALPHA / DIGIT / ":" / "/" / "." / "-" ) Personally, I'd prefer something like: Feature-tag = Feature-name / Fearure-URI Feature-name = ALPHA *( ALPHA / DIGIT / "." / "-" ) Feature-URI = generic-URI Where generic-URI is as defined in appendix A of . (Maybe 'generic-URI' isn't the right choice -- I suspect there are subtleties here of which I am unaware.) There's then the question of what characters should be allowed in non-URI feature tags. GK. --- ------------ Graham Klyne From owner-ietf-medfree Tue Mar 17 11:37:49 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA15851 for ietf-medfree-bks; Tue, 17 Mar 1998 11:37:49 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id LAA15847 for ; Tue, 17 Mar 1998 11:37:48 -0800 (PST) Received: (qmail 4105 invoked from network); 17 Mar 1998 19:37:14 -0000 Received: from ao081.du.pipex.com (HELO sttnb) (193.130.254.81) by smtp.dial.pipex.com with SMTP; 17 Mar 1998 19:37:14 -0000 Message-Id: <3.0.32.19980317151509.00915100@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 17 Mar 1998 19:35:25 +0000 To: conneg WG From: Graham Klyne Subject: TCN and draft-ietf-conneg-feature-reg-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk Another issue I've just spotted: The proposed syntax which allows URIs as feature tags is incompatible with what I understand to be the format for "feature-list" in TCN for HTTP -- or has the TCN draft been updated to use characters other than ":" and "/" to denote 'true-factor' and 'false-factor' values? GK. --- ------------ Graham Klyne From owner-ietf-medfree Tue Mar 17 12:56:44 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA16432 for ietf-medfree-bks; Tue, 17 Mar 1998 12:56:44 -0800 (PST) Received: from webserv.microbyte.net (webserv.microbyte.net [207.201.197.5]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id MAA16428 for ; Tue, 17 Mar 1998 12:56:43 -0800 (PST) Received: by webserv.microbyte.net from localhost (router,SLMail V2.6); Tue, 17 Mar 1998 06:18:17 -0500 Received: by webserv.microbyte.net from default (206.175.110.23::mail daemon; unverified,SLMail V2.6); Tue, 17 Mar 1998 06:18:11 -0500 From: 33sq7j <33sqj7@mci.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Tuesday, March 17th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Sunday, March 15th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Friday, March 13th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Thursday, March 12th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Wednesday, March 18th, 1998 Reply-To: 33sqj7@mci.com Date: Tue, 17 Mar 1998 06:18:17 -0500 Subject: None Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <33sqj7@mci.com> Subject: Tuesday Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: 7 Email address lists export in many different formats (HTML, Comma delimited, text file) 7 Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom 7 Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Tue Mar 17 16:51:11 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA18118 for ietf-medfree-bks; Tue, 17 Mar 1998 16:51:11 -0800 (PST) Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA18114 for ; Tue, 17 Mar 1998 16:51:10 -0800 (PST) Received: from hplumen.cup.hp.com (hplumen.cup.hp.com [15.0.90.200]) by palrel3.hp.com (8.8.5/8.8.5tis) with ESMTP id QAA28343; Tue, 17 Mar 1998 16:50:22 -0800 (PST) Received: (from mutz@localhost) by hplumen.cup.hp.com (8.7.1/8.7.1) id QAA13645; Tue, 17 Mar 1998 16:52:49 -0800 (PST) From: Andy Mutz Message-Id: <199803180052.QAA13645@hplumen.cup.hp.com> Subject: Re: TCN and draft-ietf-conneg-feature-reg-00.txt To: GK@ACM.ORG (Graham Klyne) Date: Tue, 17 Mar 1998 16:52:43 PST Cc: ietf-medfree@imc.org In-Reply-To: <3.0.32.19980317151509.00915100@pop.dial.pipex.com>; from "Graham Klyne" at Mar 17, 98 7:35 pm Reply-to: andy_mutz@hp.com Organization: Hewlett-Packard Laboratories, Palo Alto, California X-Mailer: Elm [revision: 212.2] Sender: owner-ietf-medfree@imc.org Precedence: bulk My recollection is that Koen would modify TCN as needed to accomodate URI features tags.... Koen? Andy > Another issue I've just spotted: > > The proposed syntax which allows URIs as feature tags is incompatible with > what I understand to be the format for "feature-list" in TCN for HTTP -- or > has the TCN draft been updated to use characters other than ":" and "/" to > denote 'true-factor' and 'false-factor' values? > > GK. > --- > > ------------ > Graham Klyne > > -- --------------------------------------------------------------- Andrew Mutz | email: andy_mutz@hp.com Internet Imaging Operation | Phone: +1 408 447 4439 Imaging Solutions Division | Page: +1 888 502 7333 11000 Wolfe Road 42UO | Cupertino, California, USA. | Radio: KF6FUT --------------------------------------------------------------- From owner-ietf-medfree Tue Mar 17 17:03:11 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA18229 for ietf-medfree-bks; Tue, 17 Mar 1998 17:03:11 -0800 (PST) Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id RAA18225 for ; Tue, 17 Mar 1998 17:03:10 -0800 (PST) Received: from hplumen.cup.hp.com (hplumen.cup.hp.com [15.0.90.200]) by palrel3.hp.com (8.8.5/8.8.5tis) with ESMTP id RAA03698; Tue, 17 Mar 1998 17:02:31 -0800 (PST) Received: (from mutz@localhost) by hplumen.cup.hp.com (8.7.1/8.7.1) id RAA13676; Tue, 17 Mar 1998 17:04:58 -0800 (PST) From: Andy Mutz Message-Id: <199803180104.RAA13676@hplumen.cup.hp.com> Subject: Re: draft-ietf-conneg-feature-reg-00.txt To: GK@ACM.ORG (Graham Klyne) Date: Tue, 17 Mar 1998 17:04:52 PST Cc: ietf-medfree@imc.org In-Reply-To: <3.0.32.19980317151453.00914b10@pop.dial.pipex.com>; from "Graham Klyne" at Mar 17, 98 7:35 pm Reply-to: andy_mutz@hp.com Organization: Hewlett-Packard Laboratories, Palo Alto, California X-Mailer: Elm [revision: 212.2] Sender: owner-ietf-medfree@imc.org Precedence: bulk Graham Klyne wrote: > This document contains: > > >2.2 Feature tag syntax > > > > A feature tag is a string consisting of one or more of the following > > US-ASCII characters: uppercase letters, lowercase letters, digits, > > colon (":"), slash ("/"), dot (".") and dash ("-"). Feature tags are > > case-insensitive. Dots are understood to potentially imply heirarchy; > > a feature can be subtyped by describing it as tree.feature.subfeature > > and by indicating this in the feature registration. > > Do we want to require also that the first character is a letter? > > Would some ABNF be helpful? > > Referencing RFC 2234, the following might be offered: > > Feature-tag = ALPHA *( ALPHA / DIGIT / ":" / "/" / "." / "-" ) > > > Personally, I'd prefer something like: > > Feature-tag = Feature-name / Fearure-URI > Feature-name = ALPHA *( ALPHA / DIGIT / "." / "-" ) > Feature-URI = generic-URI > > Where generic-URI is as defined in appendix A of > . (Maybe 'generic-URI' isn't the right > choice -- I suspect there are subtleties here of which I am unaware.) > > There's then the question of what characters should be allowed in non-URI > feature tags. Requiring an ALPHA for first character of the Feature-tag is (I think) a good idea. The ABNF is also nicer. Generic URI's can include "=" | "+" | "," and etc. I'm concerned about the impact on TCN if we include ALL the pchar in http://ds.internic.net/internet-drafts/draft-fielding-uri-syntax-02.txt. The definition of URI's for feature-tags in the registration draft are deliberately more restrictive at the moment. Andy Mutz -- --------------------------------------------------------------- Andrew Mutz | email: andy_mutz@hp.com Internet Imaging Operation | Phone: +1 408 447 4439 Imaging Solutions Division | Page: +1 888 502 7333 11000 Wolfe Road 42UO | Cupertino, California, USA. | Radio: KF6FUT --------------------------------------------------------------- From owner-ietf-medfree Tue Mar 17 17:08:08 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA18266 for ietf-medfree-bks; Tue, 17 Mar 1998 17:08:08 -0800 (PST) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.7.3) with SMTP id RAA18262 for ; Tue, 17 Mar 1998 17:08:08 -0800 (PST) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA07461; Tue, 17 Mar 1998 17:07:28 -0800 Date: Tue, 17 Mar 1998 17:07:28 -0800 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9803171707.ZM7459@thornhill.arc.nasa.gov> In-Reply-To: Graham Klyne "ASN.1 (was: Where are we now?)" (Mar 17, 7:35pm) References: <3.0.32.19980317100448.007a8100@pop.dial.pipex.com> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: Graham Klyne , hardie@nic.nasa.gov Subject: Re: ASN.1 (was: Where are we now?) Cc: conneg WG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk Graham, I hope I did not indicate in what I wrote that I was not interested in discussing the issue further; I certainly am, and I appreciate your comments on the subject below. In particular, I think we need further discussion on how using a textual form within an ASN.1 protocol would work, as I am also not an expert in that area. It sounds like we are agreed that it is a good idea to provide for an ASN.1 OID to be associated with the text form of a feature if the registering organization has already assigned an OID. We still need to hammer out whether IANA can assign an OID if one is not provided, and we also need to decide if that IANA assignment takes place only on request. I hope that our update procedures are sufficiently open that adding an OID later would be possible. The real issue to me is whether negotiation would work when only one side recognized the "new" OID. regards, Ted Hardie NASA NIC > Given that we are talking about assigning meanings to tokens, the important > thing from a cross-protocol PoV seems to be agreement on the "meaning", and > as long as participants in a given protocol use the same refering "token". > There's little harm if different protocols use different tokens. (I see > there is practical value in having a common textual syntax, because the > descriptions tend to be longer and a common reference saves design effort.) > > So I can agree that ASN.1 OID designations do not need to be mandatory. > > (I don't really feel that your suggestion to use the textual form wthin > ASN.1 protocols is a Good Idea -- it seems to me to be a "worst of all > worlds" type of approach. But not being an expert here I am prepared to > bow to better-informed opinion.) > > QUESTION: should the registration provide for an *optional* ASN.1 > assignment in a standard IANA sub-tree? This would not involve the > registering party in "the hassle of managing a delegated portion of the > ASN.1 namespace", but if the registration *were* made then it could save > others from precisely this hassle in the futire if they wish to use the > feature with ASN.1-based protocols. > > As I see it, the IANA responsibility here would be (1) to assign a sub-tree > of IANA-managed OID-space (a one-off activity), and (2) assign a unique > integer identifier for each feature which is registered with an OID. > > Something which I can imagine might prove problematic is allowing > organizations to define their own OIDs in a registration -- what are the > guarantees that the corresponding OID sub-namespace will be appropriately > managed in the future? > > ANOTHER QUESTION: if we do not address the OID issue now, how difficult > would it be to retrospectively add OIDs to feature registrations in the > future? I suspect that the answer is "not too difficult" (e.g. an update > to the registration document and a simple separate OID/feature-name > register might do the trick). > > GK. > --- > > > ------------ > Graham Klyne >-- End of excerpt from Graham Klyne From owner-ietf-medfree Tue Mar 17 17:17:04 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA18327 for ietf-medfree-bks; Tue, 17 Mar 1998 17:17:04 -0800 (PST) Received: from server.visi-net.com ([206.231.146.2]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id RAA18323 for ; Tue, 17 Mar 1998 17:17:03 -0800 (PST) Date: Tue, 17 Mar 1998 17:17:03 -0800 (PST) From: 508115@zZwzfx.com Message-Id: <199803180117.RAA18323@mail.proper.com> Received: from backup (ptp99.sopris.NET [209.38.22.109]) by server.visi-net.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id H1R5YA8G; Tue, 17 Mar 1998 20:19:13 -0500 To: ietf-medfree@imc.org Subject: Affordable High Performance Web Hosting Sender: owner-ietf-medfree@imc.org Precedence: bulk Now when you sign up for web hosting with http://www.PerformanceServices.net you get free site submission to over 620 search engines.* http://www.PerformanceServices.net provides high speed virtual websitehosting services for $40.00 per month including the following: - Microsoft Front Page Server extensions - Support for Active Server Pages & Microsoft Visual InterDev - Free site submission to over 620 search engines* - Comprehensive monthly web site statistics - Choice of primary server country - 5 inbound E-Mail boxes with E-Mail forwarding & autoresponders - FTP access with one username and password - Microsoft Access 97 - Microsoft SQL Server 6.5 - Microsoft Index Server - Microsoft Transaction Server - Microsoft Distributed Transaction Coordinator - CGI program support - PERL program support - Complete daily backups - One DNS mapping for your domain name - Access to raw history files - ISAPI support - 20 MB of disk storage - Complete user configurable Active Server Page shopping cart - coming 03-31-98 - Free SSL Certificate from The Digital Certificates Verification Authority - coming 04-10-98 - CyberCash - coming 04-24-98 (extra charges may apply) - Volcano Chat - coming 04-15-98 - True Speech - coming 04-25-98 (extra charges may apply) - Real Audio & Streaming Video - coming 05-01-98(extra charges will apply) This is a limited time offer so come to http://www.PerformanceServices.net and sign up today! Thank you. * Clients must prepay the first six months of service to qualify for one time free site submission From owner-ietf-medfree Tue Mar 17 19:18:21 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id TAA19145 for ietf-medfree-bks; Tue, 17 Mar 1998 19:18:21 -0800 (PST) Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id TAA19141 for ; Tue, 17 Mar 1998 19:18:20 -0800 (PST) Received: from hplumen.cup.hp.com (hplumen.cup.hp.com [15.0.90.200]) by palrel3.hp.com (8.8.5/8.8.5tis) with ESMTP id TAA14471; Tue, 17 Mar 1998 19:17:44 -0800 (PST) Received: (from mutz@localhost) by hplumen.cup.hp.com (8.7.1/8.7.1) id TAA13824; Tue, 17 Mar 1998 19:20:01 -0800 (PST) From: Andy Mutz Message-Id: <199803180320.TAA13824@hplumen.cup.hp.com> Subject: Re: draft-ietf-conneg-feature-reg-00.txt To: GK@ACM.ORG (Graham Klyne) Date: Tue, 17 Mar 1998 19:19:55 PST Cc: andy_mutz@hp.com, ietf-medfree@imc.org In-Reply-To: <3.0.32.19980312183559.0084d100@pop.dial.pipex.com>; from "Graham Klyne" at Mar 12, 98 8:51 pm Reply-to: andy_mutz@hp.com Organization: Hewlett-Packard Laboratories, Palo Alto, California X-Mailer: Elm [revision: 212.2] Sender: owner-ietf-medfree@imc.org Precedence: bulk I incorporated many of the comments on the last registration draft into draft-ietf-conneg-feature-reg-00.txt: 1) Introductory and explanatory text was reintroduced. 2) References to negotiation were replaced by reference to property exchange and communication. 3) The x and local trees were removed. 4) The URL tree is identified now by a leading facet u. to avoid ambiguity. 5) The syntax of feature tag values is defined 6) The registration form is updated I did not include ASN.1 ids in this registration draft, mostly due to time constraints and open issues regarding assignment of numbers. In response to the early feedback from Graham: Graham Klyne wrote: > Andy, > > Comments below. > > They are matters of detail -- I am generally comfortable with the broad > framework. I might want to make some more suggestions regarding language > later, but I look to see consensus on the framework first. > > GK. > --- > > > At 02:07 12/03/98 -0800, Andrew Mutz wrote: > >2 Feature tag definitions > > > >2.1 Feature tag purpose > > > > Content feature tags represent individual and simple dimensions of > > feature capability. Examples of content features related to media > > are: > > > > * the color depth of the screen on which something is to be displayed > > * the support of the `floating 5 dimensional tables' feature > > * the type of paper available in a printer > > * the fonts which are available to the recipient > > * the capability to display graphical content > > > > A feature tag identifies a single dimension of characteristic. Feature > > tag values should be represented as(and must be representable or > > isomorphic to) boolean, enumerated values, or numeric values. > > Examples of feature tags are defined in detail elsewhere [4]. > > > > > > Many features are not Boolean and require values to qualify them. > > Examples of feature tags with values are: > > * the width of a display in pixels represented as an integer value. > > * the fonts available to a recipient as an enumerated list. > > * the version of a protocol composed of integers "i.j.k", defined as > > either a value in an enumerated list or isomorphic to the integer > > numeric value ijk. > ...----------------->...................<--------------------------- > I think care is needed here with "isomorphic". I suggest > > # * the version of a protocol composed of integers "i.j.k", defined as > # either a value in an ordered enumerated list, or with a defined mapping > # to make the value isomorphic to a subset of integers (e.g. i*100+j*10+k, > # assuming j<=9 and k<=9). Done - better to be specific. > > (I suggest an ordered enumerated list on the assumption that one wants to > be able to have an ordering relation on a protocol version as well as an > equality test.) > > > >2.2 Feature tag syntax > > > > A feature tag is a string consisting of one or more of the following > > US-ASCII characters: uppercase letters, lowercase letters, digits, > > colon (":"), slash ("/"), dot (".") and dash ("-"). Feature tags are > > case-insensitive. Dots are understood to potentially imply heirarchy; > > a feature can be subtyped by describing it as tree.feature.subfeature > > and by indicating this in the feature registration. > > A small point: I assume that colon and slash are included to allow URIs as > feature tag names? > > Is there a potential conflict, or confusion, between hierarchical faceted > names and URIs? I am thinking that it might be clearer to allow faceted > names with components containing letters, digits and '-', OR a name in URI > syntax. The latter is distinguished by the leading 'scheme:'. > > It's just a thought. I don't believe there is a conflict; URI feature tags are identified by a leading facet "u.". There COULD be confusion, but I don't believe it'll be a problem in practice. > > > > A feature tag value is a string consisting of one or more of the > > following US-ASCII characters: uppercase letters, lowercase letters, > > digits, colon (":"), slash("/"), dot("."), and dash ("-"). Values are > > case-insensitive. Feature tag values should be simple atomic values > > of either enumerated or numeric form and must be isomorphic with > > either enumerated or numeric values. The form of feature tag values > > is indicated upon feature registration. > > I think we may wish to be able to enumerate arbitrary text values, so a > form which allows an arbitrary quoted string maybe should be allowed. For > example, using a manufacturer name to identify a class of equipment. > > I am suggesting something like: > feature-value = token | integer | rational | quoted-string > > I would then suggest that if the registration allows quoted-string values > then an ordering relation is provided only iff the registration states how > it is defined. Yes; I think the rules for feature tag values are a bit overly strict right now. I will edit the next draft to reflect this. > > The only other system I can think of offhand which faces this kind of > problem is > X.500/LDAP directories, and they have comparison rules associated with > attribute types which are separately defined and registered. But, at the > end of the day, the algebra is limited to logical combinations of: > equality, ordering, approximate-equality and limited pattern-matching > operations > > QUESTION: should we allow the registration to indicate different > representations for numeric values (e.g. decimal, hex, C-language, etc. for > integers, or fixed-point, scientific, x/y ratio for rationals)? Having different representations for numeric values is not a very big deal for registration, but could be something of a mess for use. I would tend to stick with decimal, fixed point, and scientific unless a real need for others exist. Opinions? Andy Mutz -- --------------------------------------------------------------- Andrew Mutz | email: andy_mutz@hp.com Internet Imaging Operation | Phone: +1 408 447 4439 Imaging Solutions Division | Page: +1 888 502 7333 11000 Wolfe Road 42UO | Cupertino, California, USA. | Radio: KF6FUT --------------------------------------------------------------- From owner-ietf-medfree Tue Mar 17 22:37:49 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id WAA20187 for ietf-medfree-bks; Tue, 17 Mar 1998 22:37:49 -0800 (PST) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.7.3) with SMTP id WAA20183 for ; Tue, 17 Mar 1998 22:37:45 -0800 (PST) Received: from casablanca.parc.xerox.com ([13.2.16.111]) by alpha.xerox.com with SMTP id <53762(4)>; Tue, 17 Mar 1998 22:37:13 PST Received: from bronze-208.parc.xerox.com ([13.0.211.227]) by casablanca.parc.xerox.com with SMTP id <71813>; Tue, 17 Mar 1998 22:37:01 PST Message-ID: <037601bd5238$3fd34ae0$e3d3000d@bronze-208.parc.xerox.com> From: "Larry Masinter" To: , "Graham Klyne" Cc: "conneg WG" Subject: Re: Where are we now? Date: Tue, 17 Mar 1998 22:36:54 PST MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-medfree@imc.org Precedence: bulk # One thing which I think really does need developing is the idea of # expressing preferences -- that is one area regarding which little has been # proposed in this forum. I haven't yet found a "handle" to give me a good # purchase on this particular problem. I thought we were going down the road of your algebra, which seems fine: boolean expressions of (in)equalities or set memberships; and Q values for ordering. From owner-ietf-medfree Wed Mar 18 03:57:24 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id DAA05379 for ietf-medfree-bks; Wed, 18 Mar 1998 03:57:24 -0800 (PST) Received: from wsooti13.win.tue.nl (koen@wsooti13.win.tue.nl [131.155.70.20]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id DAA05375 for ; Wed, 18 Mar 1998 03:57:20 -0800 (PST) Received: from koen@localhost by wsooti13.win.tue.nl (8.8.7) id MAA09195. Wed, 18 Mar 1998 12:56:21 +0100 (MET) From: koen@win.tue.nl (Koen Holtman) Message-Id: <199803181156.MAA09195@wsooti13.win.tue.nl> Subject: Re: TCN and draft-ietf-conneg-feature-reg-00.txt To: andy_mutz@hp.com Date: Wed, 18 Mar 1998 12:56:20 +0100 (MET) Cc: GK@ACM.ORG, ietf-medfree@imc.org In-Reply-To: <199803180052.QAA13645@hplumen.cup.hp.com> from "Andy Mutz" at Mar 17, 98 04:52:43 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ietf-medfree@imc.org Precedence: bulk Andy Mutz: > >My recollection is that Koen would modify TCN as needed to accomodate >URI features tags.... Koen? Yes, I modified it. The new BNF is: ftag = token | quoted-string feature-list = 1%feature-list-element feature-list-element = ( fpred | fpred-bag ) [ ";" [ "+" true-improvement ] [ "-" false-degradation ] ] fpred-bag = "[" 1%fpred "]" true-improvement = short-float false-degradation = short-float This means you can write something like {"a.html" 1.0 {features "http://x.org/rotatinggifs";+0.5}} and a parser which is liberal in what it accepts will probably let you get away with omitting the quotes around http://x.org/rotatinggifs. By the way, I just saw that the TCN drafts have been released as informational RFCs: RFC 2295 -- TCN RFC 2296 -- HTTP RVSA/1.0 >Andy Koen. From owner-ietf-medfree Wed Mar 18 13:28:27 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA09421 for ietf-medfree-bks; Wed, 18 Mar 1998 13:28:27 -0800 (PST) Received: from HAL.GoGlobal.com (HAL.GOGLOBAL.com [207.195.40.68]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id NAA09417 for ; Wed, 18 Mar 1998 13:28:26 -0800 (PST) From: dweber@GoGlobal.com Received: from [207.195.40.68] by HAL.GoGlobal.com (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-0U10L2S100) with SMTP id AUI240 for ; Wed, 18 Mar 1998 15:05:29 -0600 To: ietf-medfree@imc.org Subject: Webmaster Study Date: Wed, 18 Mar 1998 15:01:56 -0600 X-Mailer: Allaire Cold Fusion 3.1 Message-ID: <19980318210338734.AUI240@[207.195.40.68]> Sender: owner-ietf-medfree@imc.org Precedence: bulk Dear , If you are not a webmaster and this message has reached you by mistake, please accept our apologies and disregard it. ITrackS Market Research and WebsiteSurveys Inc. request your assistance by participating in a webmaster study. The study is designed to give webmasters a better understanding of issues such as comparative compensation across industries and company types. A summary of results of the study will be provided to all webmasters who participate. In addition, all participants will be entered to win a free weekend in Las Vegas -- including air travel -- or a large screen TV. For non-US residents the prize is a cheque for a US dollar equivalent. The URL to participate is: http://www.ws2.com/wm/start.htm If you have any questions about the study, feel free to direct them to Dweber@GoGlobal.com Thanks you for your consideration! Daniel Weber ITrackS Internet Market Research A division of Global Eyes Internet Marketing Phone: (306) 665-5026 If you received this Email in error, please accept my apology and fell free to forward it to the appropriate person in your workplace. If receipt of this Email offends you in any way, please let us know by replying to the Email with the word remove in the subject. You will never be contacted by our organization again. From owner-ietf-medfree Wed Mar 18 18:44:21 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA12617 for ietf-medfree-bks; Wed, 18 Mar 1998 18:44:21 -0800 (PST) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.7.3) with SMTP id SAA12613 for ; Wed, 18 Mar 1998 18:44:20 -0800 (PST) Received: from casablanca.parc.xerox.com ([13.2.16.111]) by alpha.xerox.com with SMTP id <52190(1)>; Wed, 18 Mar 1998 18:43:51 PST Received: from bronze.parc.xerox.com ([13.1.103.244]) by casablanca.parc.xerox.com with SMTP id <71813>; Wed, 18 Mar 1998 18:43:45 PST Message-ID: <01be01bd52e0$d0901f60$f467010d@bronze.parc.xerox.com> From: "Larry Masinter" To: "Koen Holtman" , Cc: , Subject: Re: TCN and draft-ietf-conneg-feature-reg-00.txt Date: Wed, 18 Mar 1998 18:43:35 PST MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-medfree@imc.org Precedence: bulk > >By the way, I just saw that the TCN drafts have been released as >informational RFCs: > > RFC 2295 -- TCN > RFC 2296 -- HTTP RVSA/1.0 > They're "Experimental", not "Informational". Larry From owner-ietf-medfree Thu Mar 19 01:58:24 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id BAA26665 for ietf-medfree-bks; Thu, 19 Mar 1998 01:58:24 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id BAA26652 for ; Thu, 19 Mar 1998 01:58:22 -0800 (PST) Received: (qmail 28424 invoked from network); 19 Mar 1998 09:57:56 -0000 Received: from ag193.du.pipex.com (HELO sttnb) (193.130.246.193) by smtp.dial.pipex.com with SMTP; 19 Mar 1998 09:57:56 -0000 Message-Id: <3.0.32.19980319095554.007d1100@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 19 Mar 1998 09:56:07 +0000 To: "Larry Masinter" From: Graham Klyne Subject: Ranking preferences (was: Where are we now?) Cc: "conneg WG" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 22:36 17/03/98 PST, Larry Masinter wrote: ># One thing which I think really does need developing is the idea of ># expressing preferences -- that is one area regarding which little has been ># proposed in this forum. I haven't yet found a "handle" to give me a good ># purchase on this particular problem. > > >I thought we were going down the road of your algebra, which seems >fine: boolean expressions of (in)equalities or set memberships; and Q values >for ordering. > I *had* been trying to hold a completely open mind about the ordering issue, with a bias away from Q-values. But, one advantage of using Q-values is that I think they can be added fairly easy to the Boolean expressions for set membership. TCN defines such a scheme as part of its syntax: adapting this, any Boolean sub-expression in a predicate might have 'true-factor and 'false-factor' values. Then the Boolean combining operators might be extended when applied to thus qualified expressions, e.g.: Q(A&B) = Q(A) * Q(B) Q(!A) = 1 - Q(A) Q(A|B) = 1-((1-Q(A))*(1-Q(B))) [by application of De Morgan's rule] (Assuming Q-factors in the range 0..1, arrived at by generalization of Boolean operations to such values with 0=false and 1=true, where Q(X) is the quality factor asociated with X). Larry, comments you made some time ago about expressing preferences with numeric values suggest that several orders of magnitude of variation should be available for Q-factors. This suggests that the 3-digit precision rule employed for HTTP/TCN might be rather restricting. What do you think? Is there any alternative to using Q-factors that we might consider? GK. --- ------------ Graham Klyne From owner-ietf-medfree Thu Mar 19 01:58:26 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id BAA26671 for ietf-medfree-bks; Thu, 19 Mar 1998 01:58:26 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id BAA26667 for ; Thu, 19 Mar 1998 01:58:24 -0800 (PST) Received: (qmail 28414 invoked from network); 19 Mar 1998 09:57:54 -0000 Received: from ag193.du.pipex.com (HELO sttnb) (193.130.246.193) by smtp.dial.pipex.com with SMTP; 19 Mar 1998 09:57:54 -0000 Message-Id: <3.0.32.19980319091349.007abb70@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 19 Mar 1998 09:56:05 +0000 To: hardie@nic.nasa.gov From: Graham Klyne Subject: Re: ASN.1 (was: Where are we now?) Cc: hardie@nic.nasa.gov, conneg WG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 17:07 17/03/98 -0800, Ted Hardie wrote: >Graham, > I hope I did not indicate in what I wrote that >I was not interested in discussing the issue further [...] Not at all. [...] > I hope that our update procedures are sufficiently >open that adding an OID later would be possible. On reflection, any OID assignment would effectively be a separate, parallel registry so I think that should be easy enough. Hence the ASN.1 issue can probably be resolved if and when it becomes important. (I am coming to think this may be less important than I originally implied.) [...] > The real >issue to me is whether negotiation would work when only >one side recognized the "new" OID. I think that's the same thing as only one side recognizing a particular URI. GK. --- ------------ Graham Klyne From owner-ietf-medfree Thu Mar 19 01:58:24 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id BAA26666 for ietf-medfree-bks; Thu, 19 Mar 1998 01:58:24 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id BAA26653 for ; Thu, 19 Mar 1998 01:58:23 -0800 (PST) Received: (qmail 28402 invoked from network); 19 Mar 1998 09:57:53 -0000 Received: from ag193.du.pipex.com (HELO sttnb) (193.130.246.193) by smtp.dial.pipex.com with SMTP; 19 Mar 1998 09:57:53 -0000 Message-Id: <3.0.32.19980319090644.007bcc10@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 19 Mar 1998 09:56:03 +0000 To: andy_mutz@hp.com From: Graham Klyne Subject: Re: draft-ietf-conneg-feature-reg-00.txt Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 17:04 17/03/98 PST, Andy Mutz wrote: >Graham Klyne wrote: >Generic URI's can include "=" | "+" | "," and etc. I'm concerned >about the impact on TCN if we include ALL the pchar in >http://ds.internic.net/internet-drafts/draft-fielding-uri-syntax-02.txt. > >The definition of URI's for feature-tags in the registration draft are >deliberately more restrictive at the moment. OK -- I hadn't realized that was a deliberate policy. GK. --- ------------ Graham Klyne From owner-ietf-medfree Thu Mar 19 05:55:35 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id FAA29380 for ietf-medfree-bks; Thu, 19 Mar 1998 05:55:35 -0800 (PST) Received: from wsooti28.win.tue.nl (koen@wsooti28.win.tue.nl [131.155.71.85]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id FAA29376 for ; Thu, 19 Mar 1998 05:55:33 -0800 (PST) Received: from koen@localhost by wsooti28.win.tue.nl (8.8.7) id OAA11762. Thu, 19 Mar 1998 14:54:35 +0100 (MET) From: koen@win.tue.nl (Koen Holtman) Message-Id: <199803191354.OAA11762@wsooti28.win.tue.nl> Subject: Re: TCN and draft-ietf-conneg-feature-reg-00.txt To: masinter@parc.xerox.com (Larry Masinter) Date: Thu, 19 Mar 1998 14:54:35 +0100 (MET) Cc: koen@win.tue.nl, andy_mutz@hp.com, GK@ACM.ORG, ietf-medfree@imc.org In-Reply-To: <01be01bd52e0$d0901f60$f467010d@bronze.parc.xerox.com> from "Larry Masinter" at Mar 18, 98 06:43:35 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk > >> >>By the way, I just saw that the TCN drafts have been released as >>informational RFCs: >> >> RFC 2295 -- TCN >> RFC 2296 -- HTTP RVSA/1.0 >> > >They're "Experimental", not "Informational". Oops! Yes, you are right. I was so busy double-checking the numbers that I missed that mistake. >Larry Koen. From owner-ietf-medfree Thu Mar 19 17:30:54 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA05188 for ietf-medfree-bks; Thu, 19 Mar 1998 17:30:54 -0800 (PST) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.7.3) with SMTP id RAA05184 for ; Thu, 19 Mar 1998 17:30:53 -0800 (PST) Received: from casablanca.parc.xerox.com ([13.2.16.111]) by alpha.xerox.com with SMTP id <51997(5)>; Thu, 19 Mar 1998 17:30:27 PST Received: from bronze-208.parc.xerox.com ([13.2.17.210]) by casablanca.parc.xerox.com with SMTP id <71822>; Thu, 19 Mar 1998 17:30:11 PST Message-ID: <000901bd539f$b7ce54a0$e3d3000d@bronze-208.parc.xerox.com> From: "Larry Masinter" To: "Graham Klyne" Cc: "conneg WG" Subject: Re: Ranking preferences (was: Where are we now?) Date: Thu, 19 Mar 1998 16:03:58 PST MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-medfree@imc.org Precedence: bulk >Larry, comments you made some time ago about expressing preferences with >numeric values suggest that several orders of magnitude of variation should >be available for Q-factors. This suggests that the 3-digit precision rule >employed for HTTP/TCN might be rather restricting. What do you think? I don't think the 3-digit precision rule actually is a problem in practice. >Is there any alternative to using Q-factors that we might consider? If you don't have Q-values, then you still need an ordered list and a way of ordering it. But I don't like doing arithmetic on them. You said: > Q(A&B) = Q(A) * Q(B) > Q(!A) = 1 - Q(A) > Q(A|B) = 1-((1-Q(A))*(1-Q(B))) [by application of De Morgan's rule] But there are lots of others you could use, too, e.g.: Q(A&B) = min(Q(A), Q(B)) Q(A|B) = max(Q(A), Q(B)) Q(!A) = 1-Q(A) would work, too, for example, and still project the generalization of boolean where 0=false and 1 = true. From owner-ietf-medfree Thu Mar 19 23:05:14 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id XAA09477 for ietf-medfree-bks; Thu, 19 Mar 1998 23:05:14 -0800 (PST) Received: from papayus.topnet.fr (PAPAYUS.TOPNET.FR [194.51.124.1]) by mail.proper.com (8.8.8/8.7.3) with SMTP id XAA09467 for ; Thu, 19 Mar 1998 23:05:12 -0800 (PST) From: 6J7FW2xfb@discoun1tautom.com Received: from 1H4A7d87c (unverified [12.70.16.85]) by papayus.topnet.fr (EMWAC SMTPRS 0.83) with SMTP id ; Fri, 20 Mar 1998 07:02:43 +0100 DATE: 20 Mar 98 1:02:15 AM Message-ID: <1hKm0nVk6jf92bjLvHL> TO: ndia@wnxt.it SUBJECT: NDIA's 24th Environmental Symposium & Exhibition Sender: owner-ietf-medfree@imc.org Precedence: bulk PLEASE JOIN US AT NDIA's 24th Environmental Symposium & Exhibition "Smart Business Practices for Mission Readiness and Environmental Sustainability" April 6-9, 1998 Tampa Convention Center Tampa, FL Speakers Include: Ms. Sherri Goodman Deputy Under Secretary of Defense, Environmental Security and The Honorable Jacques Gansler Under Secretary of Defense, Acquisition & Technology This meeting provides a national forum for the free exchange of environmentally related policies, programs, related technical information and ideas from individuals, educational institutions, professional associations and societies, representatives of private companies and corporations and officials of Federal and State government agencies and regulatory bodies. You will also have the opportunity to attend Air Force Industry Day on Wednesday, April 8th. This is definitely a "can't miss" event! Exhibit space is still available! Please mailto:ckline@ndia.org for more information and a current floorplan. To view the complete agenda and hotel information, please visit our web page at http://www.ndia.org/events/brochure/844/844.htm We hope to see you in sunny Tampa, FL!! From owner-ietf-medfree Sat Mar 21 11:37:50 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA13890 for ietf-medfree-bks; Sat, 21 Mar 1998 11:37:50 -0800 (PST) Received: from web78.ntx.net (root@x189.ntx.net [209.1.144.189]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA13886 for ; Sat, 21 Mar 1998 11:37:50 -0800 (PST) From: credit2@mailexcite.com Received: from hp-customer (1Cust87.tnt2.lax3.da.uu.net [153.37.58.87]) by web78.ntx.net (8.8.5/8.8.5) with SMTP id LAA00478; Sat, 21 Mar 1998 11:36:39 -0800 (PST) Date: Sat, 21 Mar 1998 11:36:39 -0800 (PST) Subject: Consumer Credit Announcement Message-Id: Content-Type: TEXT/PLAIN charset=US-ASCII Sender: owner-ietf-medfree@imc.org Precedence: bulk MPORTANT NEWS REGARDING YOUR CREDIT REPORT Have you recently received a pre-approved application for a major credit card? If you have, do you know that the credit bureaus "sold" your name and social security number without permission? Since this credit bureau got money by providing your personal information, how much did the credit bureau send you? Here's what you need! The key to turning "Bad Credit" into "EXCELLENT CREDIT". (To go to Direct Credit, click on the link now or cut and paste it into your browser, but please DO NOT retype it in.) http://207.204.174.21/directcredit/ Fact: · You can receive a FREE credit report if you have been turned down for credit. · You can "legally" remove any negative credit information from your credit report(s) · We can save you hundreds of dollars by showing you how to safely "Do-it-Yourself" guaranteed! Direct Credit costs only $35.00 (Visa/MasterCard Amex and our 900 number) · No matter what "The Credit Bureaus" tell you, YOU CAN REMOVE NEGATIVE INFORMATION NOW from your credit reports, no matter if the negative information is true or not. We will show you how to do it legally and quickly. (To go to Direct Credit, click on the link now or cut and paste it into your browser, but please DO NOT retype it in.) http://207.204.174.21/directcredit/ 10 minutes a month is all you need . . . * Direct Credit removes negative items from each major credit report: Experian (Formally TRW), TransUnion, CBI/Equifax * Direct Credit will communicate with the credit bureaus, so you will never need to * Direct Credit reviews your credit reports on a regular basis! * Direct Credit Manages your own credit reports quickly and easily * Direct Credit re-establishes your good credit, Fast!" This is not hype! Direct Credit truly works. If you have "Bad Credit" or know someone who does, you can not let this opportunity go by. (To go to Direct Credit, click on the link now or cut and paste it into your browser, but please DO NOT retype it in.) http://207.204.174.21/directcredit/ We can help you today! Regards, Team Direct Credit * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * You have been carefully selected to receive the following as a person who may be interested in this subject based upon your previous internet postings, or visits to one of our affiliate web sites. If you have received this message in error, please accept our apology as a responsible e-mailer, and reply to: unsubscribeitnow@wowmail.com You will be automatically excluded from future e-mailings. Thank you for your consideration and help in making the Internet spam-free. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * From owner-ietf-medfree Sat Mar 21 20:00:13 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id UAA00760 for ietf-medfree-bks; Sat, 21 Mar 1998 20:00:13 -0800 (PST) Received: from ipra4.ipra.com ([193.158.100.200]) by mail.proper.com (8.8.8/8.7.3) with SMTP id UAA00756 for ; Sat, 21 Mar 1998 20:00:11 -0800 (PST) Date: Sat, 21 Mar 1998 20:00:11 -0800 (PST) Received: from NIKOLE [209.60.248.149] (HELO jj3dw3.q3q3665f.com) by ipra4.ipra.com (AltaVista Mail V2.0/2.0 BL23 listener) id 0000_0058_3514_8c5e_3e58; Sun, 22 Mar 1998 04:58:22 +0100 From: 77tt665 <77tt665@mci.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Friday, March 20th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Wednesday, March 18th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Monday, March 16th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Sunday, March 15th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Saturday, March 21st, 1998 Reply-To: 77tt665@mci.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <77tt665@mci.com> Subject: Sunday Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Wed Mar 25 04:44:50 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id EAA27687 for ietf-medfree-bks; Wed, 25 Mar 1998 04:44:50 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id EAA27682 for ; Wed, 25 Mar 1998 04:44:49 -0800 (PST) Received: (qmail 18938 invoked from network); 25 Mar 1998 12:44:52 -0000 Received: from an101.du.pipex.com (HELO sttnb) (193.130.253.101) by smtp.dial.pipex.com with SMTP; 25 Mar 1998 12:44:52 -0000 Message-Id: <3.0.32.19980325124127.007a6cc0@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 25 Mar 1998 12:42:58 +0000 To: "Larry Masinter" From: Graham Klyne Subject: Re: Ranking preferences Cc: "conneg WG" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 16:03 19/03/98 PST, Larry Masinter wrote: >>Is there any alternative to using Q-factors that we might consider? > > >If you don't have Q-values, then you still need an ordered list and a way of ordering it. >But I don't like doing arithmetic on them. You said: > >> Q(A&B) = Q(A) * Q(B) >> Q(!A) = 1 - Q(A) >> Q(A|B) = 1-((1-Q(A))*(1-Q(B))) [by application of De Morgan's rule] > >But there are lots of others you could use, too, e.g.: > > Q(A&B) = min(Q(A), Q(B)) > Q(A|B) = max(Q(A), Q(B)) > Q(!A) = 1-Q(A) > >would work, too, for example, and still project the generalization of >boolean where 0=false and 1 = true. Yes, your approach is much cleaner. And it has the advantage that the precision of the result is always bounded by the precision of the inputs. My only reservation was that it does not capture the idea that degrading a degraded version of data is lilely to be even more degraded, particularly considering the case Q(A&B) where 0 < Q(A) = Q(B) < 1. But, I have failed thus far to come up with any other simple non-arithmetic scheme. And, on reflection, I conclude that *any* attempt to quantify the effect of combined degradation is going to be somewhat arbitrary so it's probably better not to pretend that it can be captured at all (in a simple ranking scheme like this). I would like to try and identify the "simplifying assumption" which underpins this scheme, so that its shortcomings can be well-understood. I think the main simplifying assumption is simply that degradations are not cumulative in this scheme. So, in the face of several applied degradations, only the worst applies for ranking purposes (the Q(A&B) rule). If several alternative feature sets are available, it seems quite natural that one would choose the least degradation (the Q(A|B) rule). The Q(!A) rule is more challenging. If the presence of a feature set represents some particular degradation, I am not sure about interpreting its absence as some "complementary" degradation. This seems to imply some kind of "mutual exclusivity" assumption about document quality. It seems that the logical negation is meaningful only when applied to selection of feature sets, not in manipulating their ranking. [I note with interest that part of the process of transforming predicate calculus to clausal form (per Prolog) involves moving all logical negations "down" so they apply directly to literals (roughly equivalent to "media feature tests" in our scenario).] This suggests to me that applying "!" to quality factors should be avoided. But should it be prohibited? In thinking about this, I lean to a different interpretation which also projects to Boolean: Q(!A) = ( Q(A) == 0 -> 1, 0 ) The rationale is this: any non-zero quality factor indicates a feature (or set of features) which may be present in a feature set, even if its (their) presence is associated with some degradation of document quality. However, the expression !A means that feature A must not be present. The above interpretation has two advantages in my view: (a) it is non-arithmetic (b) it avoids the implication of document quality being mutually exclusively assigned to presence of absence of a feature. Further thoughts? GK. --- ------------ Graham Klyne From owner-ietf-medfree Sat Mar 28 21:57:29 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id VAA13463 for ietf-medfree-bks; Sat, 28 Mar 1998 21:57:29 -0800 (PST) Received: from guide (ip159.jacksonsonville4-1.fl.pub-ip.psi.net [38.30.155.159]) by mail.proper.com (8.8.8/8.7.3) with SMTP id VAA13459 for ; Sat, 28 Mar 1998 21:57:26 -0800 (PST) Date: Sat, 28 Mar 1998 21:57:26 -0800 (PST) From: mat@ideal.aq Message-Id: <199803290557.VAA13459@mail.proper.com> To: Subject: Blank Media Buyer: Sender: owner-ietf-medfree@imc.org Precedence: bulk Total Media is a major supplier of blank audio, video and computer recording media. Quite often we make major purchases of manufacturers' over stocked or close-out items. Listed below are some of the major items we have in stock at the present time. Most of these items are current packaging but some may not be in the original master carton. Each item is different so if you are interested in any of these items, please call as @ 1-800-848-4118 and we will provide you with more details and samples if necessary or visit our website at http://www.TM-tape.com. Thank you, Jerry Ghinelli Item Quantity Available Price per unit Maxell HS4-120 4mm Carts (120m) 5000 $ 7.00 Maxell HS4-CL 4mm Cleaner 11,000 $ 2.50 Maxell HS4-90 4mm carts (90m) 2,000 $ 3.50 (Sold out) Maxell HS8-112 8mm carts (112m) 7,500 $ 3.00 Maxell MF2-HD Format.(3.5") 10 pack 3,000 $ 2.25 (Sold out) Maxell MF2-HD Format (3.5") 100 pack 1,200 $21.00 Maxell MF2-HD Format Asst Colors 60 pack 500 $12.00 Maxell MF2-DD (3.5")(Assort) 10 Pack 5,000 $ 1.25 Maxell MD2-HD & DD 5.25" 10 Pack 5,000 $ .75 Memorex T-120 VHS 50,000 $ 1.25 BASF HG T-180 VHS 15,000 $ 2.90 Maxell P6-120 8mm Video 10,000 $ 2.10 Maxell TC-30 HG VHS-C 20,000 $2.00 From owner-ietf-medfree Sun Mar 29 01:50:47 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id BAA26119 for ietf-medfree-bks; Sun, 29 Mar 1998 01:50:47 -0800 (PST) Received: from gator.cois.on.ca (root@gator.cois.on.ca [205.211.154.2]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id BAA26115; Sun, 29 Mar 1998 01:50:38 -0800 (PST) Received: from jj3dw3.q3q3665f.com ([209.60.248.171]) by gator.cois.on.ca (8.8.5/8.8.5) with SMTP id EAA05427; Sun, 29 Mar 1998 04:38:58 -0500 (EST) Date: Sun, 29 Mar 1998 04:38:58 -0500 (EST) From: cc77991 To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Thursday, March 26th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Tuesday, March 24th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Sunday, March 22nd, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Saturday, March 21st, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Friday, March 27th, 1998 Reply-To: cc77991@mci.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is Subject: for the Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Tue Mar 31 00:15:54 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id AAA09229 for ietf-medfree-bks; Tue, 31 Mar 1998 00:15:54 -0800 (PST) Received: from mail.spidercom.net ([207.236.101.194]) by mail.proper.com (8.8.8/8.7.3) with SMTP id AAA09192 for ; Tue, 31 Mar 1998 00:15:34 -0800 (PST) Date: Tue, 31 Mar 1998 00:15:34 -0800 (PST) Received: from [209.60.248.145] by mail.spidercom.net (NTMail 3.03.0014/1d.aadn) with ESMTP id va041933 for ; Tue, 31 Mar 1998 03:10:35 +0000 From: 1a2237h <1a2237h@mci.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Saturday, March 28th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Thursday, March 26th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Tuesday, March 24th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Monday, March 23rd, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Sunday, March 29th, 1998 Reply-To: 1a2237h@mci.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <1a2237h@mci.com> Subject: mon Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Tue, 31 Mar 1998 03:10:35 +0000 X-Info: Visit http://www.spidercom.net ISP EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Fri Apr 3 03:45:12 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id DAA26642 for ietf-medfree-bks; Fri, 3 Apr 1998 03:45:12 -0800 (PST) Received: from mail.border.net (mail.border.net [207.193.244.20]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id DAA26636 for ; Fri, 3 Apr 1998 03:45:06 -0800 (PST) From: the_vault@iesconet.com Received: from william (st206.border.net [207.193.244.206]) by mail.border.net (8.8.5/8.8.5) with SMTP id FAA14198; Fri, 3 Apr 1998 05:45:10 -0600 (CST) Date: Fri, 3 Apr 1998 05:45:10 -0600 (CST) Subject: WHEN IN SAN ANTONIO Message-Id: Content-Type: TEXT/PLAIN charset=US-ASCII Sender: owner-ietf-medfree@imc.org Precedence: bulk VISIT THE COOLEST RESTAURANT & BISTRO BAR IN SAN ANTONIO TEXAS http://207.193.244.249/vault/welcome.html From owner-ietf-medfree Fri Apr 3 10:14:39 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA29003 for ietf-medfree-bks; Fri, 3 Apr 1998 10:14:39 -0800 (PST) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id KAA28999 for ; Fri, 3 Apr 1998 10:14:37 -0800 (PST) Received: (qmail 1391 invoked from network); 3 Apr 1998 17:39:59 -0000 Received: from ietf-11-252.mtg.ietf.org (198.94.11.252) by smtp.dial.pipex.com with SMTP; 3 Apr 1998 17:39:59 -0000 Message-Id: <3.0.32.19980403171058.007ad7f0@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 03 Apr 1998 18:40:49 +0100 To: conneg WG From: Graham Klyne Subject: Senarios for feature matching Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk Contents 1. Abstract 2. References 3. Inroduction 4. Scenarios for feature matching 4.1 Use common built-in types only 4.2 Protocol-dependent built-in types 4.3 Bult-in types and defined enumerations 4.4 Fully extensible type system 4.5 Units of measurement 4.6 Accuracy and precision 5. Conclusions 1. Abstract In the conneg WG meeting at LA, there was some brief discussion of machine readable content feature type descriptions. There was also some discussion of allowing different units for a feature value (e.g. inches, metres). This note is an attempt to provide some background to explore whether or not these are needed or desirable ideas. 2. References [1] "Feature Tag Registration Procedures", Koen Holtman, TUE Andy Mutz, Hewlett Packard Internet draft: Work in progress, March 1998. [2] "Media Features for Display, Print, and Fax" Larry Masinter, Xerox Corporation Koen Holtman, TUE Andy Mutz, Hewlett Packard Dan Wing, Cisco Systems Internet draft: Work in progress, March 1998 [3] "An algebra for describing media feature sets" G. Klyne, Integralis Internet draft: Work in progress, March 1998. [4] RFC 2301, "File Format for Internet Fax" L. McIntyre, R. Buckley, D. Venable, Xerox Corporation S. Zilles, Adobe Systems, Inc. G. Parsons, Northern Telecom J. Rafferty, Human Communications March 1998 3. Inroduction Document [1] describes framework and procedure for the registration of media feature tags, [2] contains examples of media features to be registered using this procedure, and [3] describes mechanisms for combining individual feature tags into composite media capability descriptions. One of the features of [1] is that a feature tag can be identified by a URI, and it has been suggested that the URI might refer to a machine-readable description of the data value associated with a featute tag. Documents [1] and [3] constrain feature tag values to be simple one-dimensional ("scalar") values, but this still leaves considerable room for a variety of feature value types. The feature composition algebra in [3] requires that any feature value can compared for equality with another value of the same type, and optionally (i.e. for "ordered" or "ranked" features ) that a value can be compared for precedence with another value. These operations correspond to '==' and '<' operators in C. (Other comparison operators can be derived from these.) In order to match a pair of feature sets (e.g. to determine if a particular document can be processed by a particular receipient, where both are described by a feature set per [3]) a protocol processor must be able to recognize and process feature tag values to the extent of being able to perform equality and precedence comparisons. The remainder of this memo discusses ways in which a protocol processor might understand how to recognize and process feature values. 4. Scenarios for feature matching 4.1 Use common built-in types only If all feature tags have values of some built-in type, then A protocol processor would simply recognize those built-in types and process them using hard-coded rules. Type handling would be implicit in that syntactic rules for values of different types would allow the protocol processor to detect dynamically the data type of a feature being processed. E.g. the expression 'res=100' would carry the implication that the feature 'res' is an integer. Built-in types might be: Integer, using decimal representation. Real, using fixed-point decimal representation. Token, using for example 'token' syntax per RFC 2045; equality matching only. These simple case are probably adequate for a majority of capability identification requirements. For example, everuy feature in [2], with the possible exception of "TIFF", is fully handled by these cases. The "TIFF" case in [2] is interesting because the profiles of TIFF are defined as a set of increasing capabilities, so it is natural to treat them as a set of ordered tokens. This would allow a recipient to describe its capabilities as 'TIFF<=M', meaning that it could handle any profile of TIFF up to and including "M". This case cannot be easily handled by the simple set of types described above as there is no way fora protocol processor to know how to rank TIFF profile values. 4.2 Protocol-dependent built-in types A simple extension of the above idea is to assume that types beyond the core set suggested are known to protocol processors which might have to recognize them. If the protocol processor components which handle negotiation are closely associated with the components which process the data, this is a reasonable position. But it is also possible to envisage negotiating components which do not understand the data about which they are negotiating. For example, in Internet fax, it is reasonable to expect that specialized Internet fax handling components will know about TIFF profiles. But it is not so reasonable to assume that a general-purpose e-mail client (which may usefully receive Internet fax messages) will know enough about TIFF profiles to know how to rank them. 4.3 Bult-in types and defined enumerations This scenario is a first step on the path (the slippery slope?) to generic feature type descriptions. The idea here is that a 'token' value may have a specific set of possible values associated with it. A general purpose protocol processor would need access to some kind of type repository which associates the feature tag with the set of possible token values, and also indicates how they are ordered. This is very simple from a protocol processing viewpoint, but it introduces the need for a new piece of infrastructure: some kind of feature type repository is required, which significantly increases system complexity. It might be possible to engineer a way for a description of the enumeration tokens to be sent with the capability statement, but not as part of it. This would ease the requirement for a type repository but would increase the volume of data associated with some capability statements. In a negotiation protocol which can involve multiple exchanges, a mechanism might be devised to allow the recpient of an unrecognized feature token to ask for a description from the sender. Another approach which might work for small token-sets like TIFF would be to carry the set of possible values in the feature value itself. For example, from [4], Tiff profile J might be described as TIFF=J(S,F,J,C,L,M). Then, a generic negotiating protocol processor could know how to rank TIFF token values. Another approach would be to associate a numeric value with each token, and transmit that along with the token in a capability statement. In this case, it is not clear what purpose is served by the token (other than for possible display purposes). For example, a processor could easily tell that TIFF=F(2) is at alower level than TIFF=C(4). 4.4 Fully extensible type system One of the examples brought up in discussion of the feature registration document was a version number string of the form "a.b.c". This has its own specific value syntax and its own ordering rules. Assuming a mechanism has been introduced to communicate type descriptions, as suggested in the preceding section, then it is possible to envisage a general type extension mechanism which allows new value syntax and ordering rules to be defined. For example, the version number case (above) might be described as: FEATURE Version = "." "." ; EQUAL IF (& (a.1=a.2) (b.1=b.2) (c.1=c.2) ) ; LESS IF (| (a.1= 100, measured in dpi). Forcing use of real numbers in these situations is not desirable as that significantly increases processing overhead. Multiplying values by 10 for transmission, and rounding when converting back to original units would solve the problem in this case: 100dpi (*10)-> 1000 (/2.54)-> 393 ... ... 393 (*2.54)-> 998 (round to *10) 1000 (/10)-> 100dpi However, there may still be pathological cases where rounding errors will mean the result is not identical to the original value. The alternative is to associate a unit with a value, so that Res=100dpi and Res=39dpcm would be alternative representations of resolution. When both ends use the same munits, comparison is easy; when conversionsions are required then the accuracy problems described above may still occur. 4.6 Accuracy and precision The preceding discussion suggests that for some feature values it may be desirable to specify a resolution or accuracy which is used to provide a margin of tolerance when comparing values. Returning to the example in the previous section, allowing a 1% margin of error would mean that 99dpi could be regarded as equivalent to 100dpi, so that a comparison for equality would succeed. It is not quite so clear how ordering comparisons should be dealt with (maybe <= and >= would allow the 1% margin of error the "wrong way" on the comparison. Another approach would be to specify an absolute precision for values and use that to control the precision with which arithmetic is performed. (The example from the previous section that multiples values by 10 for transmissiom effectively uses a precision of 0.1.) All calculations could be performed using integer multiples of the precision unit and rounded back to an integer for final comparison. 5. Conclusions If feature values are allowed to assume other than fixed predefined types, the implementation of any generic negotiating protocol processor is considerably complicated by the need to locate and retrieve type information. This is not a problem in "closed" negotiating protocols where the total set of negotable feature types is known in advance, since all the necessary rules can be built into the protocol processor. This has implications for feature registrations: if they are intended only for use with "closed" protocols then there is no need to constrain the types used. But if they are likely to be used in a generic negotiating environment (e.g. HTTP, e-mail) then the use of feature types which are not from a standard set introduces a need to retrieve type information in some way. The mechanisms for creating meachine-readable generic type descriptions do not need to be particularly complex. Automatic syntax analysis is a well-understood problem and the semantic requirements are quite limited and can be dealt with within the framework of feature predicates. So implementation of type-extensibility is not necessarily an obstacle to deployment is appropriate mechanisms for retrieving type information are avalable. The matter of physical units is open: technically it is simplest to not have units, but the addition of units does not seem to create any insuperable problems. In either case, the issue of accuracy/precision needs to be addressed so that thne impact of arithmetic rounding errors on unit conversions can be minimized. In any case, the issue of precision and tolerance for rounding errors needs to be addressed. (Jacob Palme made an interesting suggestion of using a kind of "super-unit" so that representation of values from different unit bases and conversion between them could be handled in integers without loss of precision.) #g ------------ Graham Klyne From owner-ietf-medfree Sat Apr 4 06:52:41 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id GAA18922 for ietf-medfree-bks; Sat, 4 Apr 1998 06:52:41 -0800 (PST) Received: from access2.digex.net (qlE46B5DiGQyA@access2.digex.net [205.197.245.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id GAA18918 for ; Sat, 4 Apr 1998 06:52:39 -0800 (PST) Received: (from asgilman@localhost) by access2.digex.net (8.8.4/8.8.4) id JAA24108; Sat, 4 Apr 1998 09:54:17 -0500 (EST) From: Al Gilman Message-Id: <199804041454.JAA24108@access2.digex.net> Subject: Re: Senarios for feature matching To: GK@ACM.ORG (Graham Klyne) Date: Sat, 4 Apr 1998 09:54:17 -0500 (EST) Cc: ietf-medfree@imc.org In-Reply-To: <3.0.32.19980403171058.007ad7f0@pop.dial.pipex.com> from Graham Klyne at "Apr 3, 98 06:40:49 pm" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk [Graham wrote about different classes of type systems, with varying scope and extensibility.] There is one key idea you are missing in your high-capability scenarios. This is the distribution of active code. The basic continuously-expanding type vocabulary scenario is one where the URI for a type definition leads you to [optionally via a registry entry] the distribution site for the applet or applets that implement the methods of the class to which this type belongs for the cited type [in the environment of your choice]. If you don't know how to evaluate relational operators such as '<' on TIFF grades, I can get it for your wholesale. That is the scenario. Al Gilman From owner-ietf-medfree Mon Apr 6 14:23:12 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA03405 for ietf-medfree-bks; Mon, 6 Apr 1998 14:23:12 -0700 (PDT) Received: from info.dsv.su.se (info.dsv.su.se [130.237.161.221]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA03398 for ; Mon, 6 Apr 1998 14:23:11 -0700 (PDT) Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138]) by info.dsv.su.se (8.8.8/8.8.8) with ESMTP id XAA21575 for ; Mon, 6 Apr 1998 23:23:10 +0200 (MET DST) X-Sender: jpalme@mail.dsv.su.se Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 6 Apr 1998 20:36:07 +0200 To: ietf-medfree@imc.org From: Jacob Palme Subject: Political, social or value judgements Sender: owner-ietf-medfree@imc.org Precedence: bulk At the meeting last week, we were told that content feature tags may not contain political, social or value judgement. What is the reason for this restriction? What does it mean? Does it mean that PICS values, which often contain political, social or value judgement, are not allowed? If so, why? ------------------------------------------------------------------------ Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme From owner-ietf-medfree Mon Apr 6 14:23:11 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA03401 for ietf-medfree-bks; Mon, 6 Apr 1998 14:23:11 -0700 (PDT) Received: from info.dsv.su.se (info.dsv.su.se [130.237.161.221]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA03390 for ; Mon, 6 Apr 1998 14:23:09 -0700 (PDT) Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138]) by info.dsv.su.se (8.8.8/8.8.8) with ESMTP id XAA21020 for ; Mon, 6 Apr 1998 23:23:06 +0200 (MET DST) X-Sender: jpalme@mail.dsv.su.se Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 6 Apr 1998 20:33:27 +0200 To: ietf-medfree@imc.org From: Jacob Palme Subject: Storing content parameters in pixels/inch or pixels/meter? Sender: owner-ietf-medfree@imc.org Precedence: bulk At the meeting last week, the following requirements were posed on the storage of pixel density: (a) The stored value should be a whole integer, not a floating point or inexact value (b) For printers, the stored value should be in pixels/inch (c) For telefaxes, the stored value should be in pixels/meter (d) The stored value should not be confused by having to store whether it is given in pixels/inch or pixels/meter I proposed briefly at the meeting that all these three requirements can be met, if the stored value is given as pixels per 254,000 meters. The reason why this solves the problem is that if the local density is stored ax pixels/inch, you multiply it by 100,000 to get a value in pixels per 254,000 meters. If the local density is stored as pixels/meter, you multiply it by 254 to get a value in pixels per 254,000 meters. If the local density is stored as pixels/centimeter, you multiply it by 25,400 to get a value in pixels per 254,000 meters. At the other end, you divide by the same factors, to get the local density back. This means that if you have a pixel density as pixels per inch, it will be received as the same integer value of pixels/ inch at the other end. The same is true for pixels/meter and pixels/ centimeter. If you have a pixel density in pixels per inch, and want to receive it as pixels/centimeter, then you multiply by 100,000, send it, and at receipt divide by 25,400. This, of course, may not be an exact integer value. But that is unavoidable. The important thing is that the result will be exact in cases where you input and output the value using the same metric, and this will work for all three metrics pixels/inch, pixels/meter and pixels/centimeter. The basis of this, of course, is that one inch is defined to be exactly 2.54 centimeter . ------------------------------------------------------------------------ Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme From owner-ietf-medfree Mon Apr 6 15:04:07 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA03735 for ietf-medfree-bks; Mon, 6 Apr 1998 15:04:07 -0700 (PDT) Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA03731 for ; Mon, 6 Apr 1998 15:04:02 -0700 (PDT) Received: from hplumen.cup.hp.com (hplumen.cup.hp.com [15.0.90.200]) by atlrel2.hp.com (8.8.6/8.8.5tis) with ESMTP id SAA24403 for ; Mon, 6 Apr 1998 18:03:19 -0400 (EDT) Received: (from mutz@localhost) by hplumen.cup.hp.com (8.7.1/8.7.1) id PAA29025; Mon, 6 Apr 1998 15:07:06 -0700 (PDT) From: Andy Mutz Message-Id: <199804062207.PAA29025@hplumen.cup.hp.com> Subject: Re: Political, social or value judgements To: jpalme@dsv.su.se (Jacob Palme) Date: Mon, 06 Apr 1998 15:07:00 PDT Cc: ietf-medfree@imc.org In-Reply-To: ; from "Jacob Palme" at Apr 6, 98 8:36 pm Reply-to: andy_mutz@hp.com Organization: Hewlett-Packard Laboratories, Palo Alto, California X-Mailer: Elm [revision: 212.2] Sender: owner-ietf-medfree@imc.org Precedence: bulk We are trying to avoid any duplication of registration by explicitly excluding features of data already considered in other groups. This WG is chartered to examine media features. THere is a presumption that only _registration_ is constrained, and content negotiation schema, methods, and syntax might be used for tags outside of media features. Andy Mutz > > At the meeting last week, we were told that content feature tags may > not contain political, social or value judgement. What is the reason > for this restriction? What does it mean? Does it mean that PICS > values, which often contain political, > social or value judgement, are not allowed? If so, why? > > ------------------------------------------------------------------------ > Jacob Palme (Stockholm University and KTH) > for more info see URL: http://www.dsv.su.se/~jpalme > > -- --------------------------------------------------------------- Andrew Mutz | email: andy_mutz@hp.com Internet Imaging Operation | Phone: +1 408 447 4439 Imaging Solutions Division | Page: +1 888 502 7333 11000 Wolfe Road 42UO | Cupertino, California, USA. | Radio: KF6FUT --------------------------------------------------------------- From owner-ietf-medfree Mon Apr 6 15:25:05 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA03893 for ietf-medfree-bks; Mon, 6 Apr 1998 15:25:05 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.7.3) with SMTP id PAA03889 for ; Mon, 6 Apr 1998 15:25:05 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA15215; Mon, 6 Apr 1998 15:24:39 -0700 Date: Mon, 6 Apr 1998 15:24:39 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9804061524.ZM15213@thornhill.arc.nasa.gov> In-Reply-To: Andy Mutz "Re: Political, social or value judgements" (Apr 6, 3:07pm) References: <199804062207.PAA29025@hplumen.cup.hp.com> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: andy_mutz@hp.com, jpalme@dsv.su.se (Jacob Palme) Subject: Re: Political, social or value judgements Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk Andy has captured this very well, but I would like to add that the presumption was not merely that excluding features already considered by other groups would reduce duplicated effort, but also that adding some other sorts of features would raise so many social and political issues that it would effectively prevent the registry from ever existing at all. We badly need a registry of media features (or user capabilities for presentation and rendering, if you prefer to think of it that way). We also need methods for exchanging those features and capabilities. If those exchange methods can be used for other purposes, that's fine, but we are explicitly not constrained to meet those purposes in our design work here. regards, Ted Hardie Chair, CONNEG On Apr 6, 3:07pm, Andy Mutz wrote: > Subject: Re: Political, social or value judgements > We are trying to avoid any duplication of registration by explicitly > excluding features of data already considered in other groups. This > WG is chartered to examine media features. > > THere is a presumption that only _registration_ is constrained, > and content negotiation schema, methods, and syntax might be used > for tags outside of media features. > > Andy Mutz > > > > > At the meeting last week, we were told that content feature tags may > > not contain political, social or value judgement. What is the reason > > for this restriction? What does it mean? Does it mean that PICS > > values, which often contain political, > > social or value judgement, are not allowed? If so, why? > > > > ------------------------------------------------------------------------ > > Jacob Palme (Stockholm University and KTH) > > for more info see URL: http://www.dsv.su.se/~jpalme > > > > > > > -- > --------------------------------------------------------------- > Andrew Mutz | email: andy_mutz@hp.com > Internet Imaging Operation | Phone: +1 408 447 4439 > Imaging Solutions Division | Page: +1 888 502 7333 > 11000 Wolfe Road 42UO | > Cupertino, California, USA. | Radio: KF6FUT > --------------------------------------------------------------- >-- End of excerpt from Andy Mutz From owner-ietf-medfree Mon Apr 6 15:39:39 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA03995 for ietf-medfree-bks; Mon, 6 Apr 1998 15:39:39 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.7.3) with SMTP id PAA03991 for ; Mon, 6 Apr 1998 15:39:39 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA15244; Mon, 6 Apr 1998 15:38:51 -0700 Date: Mon, 6 Apr 1998 15:38:51 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9804061538.ZM15242@thornhill.arc.nasa.gov> In-Reply-To: Jacob Palme "Storing content parameters in pixels/inch or pixels/meter?" (Apr 6, 8:33pm) References: Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: Jacob Palme , ietf-medfree@imc.org Subject: Re: Storing content parameters in pixels/inch or pixels/meter? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk As a clarification for those list members who were not able to attend the meeting, the question of whether fax machine manufacturers would agree to a standard which used pixels/inch was raised. Since their use of media features in coordination with the IETF-FAX work is an important aspect of our work, we would like to make sure that our design does not place undue burdens on them. Since pixels/inch is a part of the current TIFF profiles for fax, however, it isn't clear that this is an issue. I've asked one of our members who is in contact with those manufacturers to discuss this issue with them and report back. If this should pose a problem, we will need to discuss this in the context of : ftp://ftp.ietf.org/internet-drafts/draft-ietf-conneg-media-features-00.txt regards, Ted Hardie NASA NIC On Apr 6, 8:33pm, Jacob Palme wrote: > Subject: Storing content parameters in pixels/inch or pixels/meter? > At the meeting last week, the following requirements were posed on > the storage of pixel density: > > (a) The stored value should be a whole integer, not a floating point > or inexact value > > (b) For printers, the stored value should be in pixels/inch > > (c) For telefaxes, the stored value should be in pixels/meter > > (d) The stored value should not be confused by having to store > whether it is given in pixels/inch or pixels/meter > > I proposed briefly at the meeting that all these three requirements > can be met, if the stored value is given as pixels per 254,000 meters. > The reason why this solves the problem is that if the local density > is stored ax pixels/inch, you multiply it by 100,000 to get a value > in pixels per 254,000 meters. If the local density is stored as > pixels/meter, you multiply it by 254 to get a value in pixels per > 254,000 meters. If the local density is stored as pixels/centimeter, > you multiply it by 25,400 to get a value in pixels per 254,000 meters. > > At the other end, you divide by the same factors, to get the local > density back. This means that if you have a pixel density as pixels > per inch, it will be received as the same integer value of pixels/ > inch at the other end. The same is true for pixels/meter and pixels/ > centimeter. > > If you have a pixel density in pixels per inch, and want to receive > it as pixels/centimeter, then you multiply by 100,000, send it, > and at receipt divide by 25,400. This, of course, may not be an > exact integer value. But that is unavoidable. The important thing > is that the result will be exact in cases where you input and output > the value using the same metric, and this will work for all three > metrics pixels/inch, pixels/meter and pixels/centimeter. > > The basis of this, of course, is that one inch is defined to be > exactly 2.54 centimeter . > > ------------------------------------------------------------------------ > Jacob Palme (Stockholm University and KTH) > for more info see URL: http://www.dsv.su.se/~jpalme > >-- End of excerpt from Jacob Palme From owner-ietf-medfree Mon Apr 6 16:32:46 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA04479 for ietf-medfree-bks; Mon, 6 Apr 1998 16:32:46 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.7.3) with SMTP id QAA04475 for ; Mon, 6 Apr 1998 16:32:45 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA15313; Mon, 6 Apr 1998 16:32:38 -0700 Date: Mon, 6 Apr 1998 16:32:38 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9804061632.ZM15311@thornhill.arc.nasa.gov> In-Reply-To: Graham Klyne "Senarios for feature matching" (Apr 3, 6:40pm) References: <3.0.32.19980403171058.007ad7f0@pop.dial.pipex.com> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: Graham Klyne , conneg WG Subject: Re: Senarios for feature matching Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk Graham, Thanks for your notes on these issues; I have made some comments within the text excerpted below. My general comment, though, is that we may wish to focus on the type declarations for registration. If we do that right, one of the advantages to going through the registration process will be that the types will be well-known to potential users of the feature. For those features referenced by a URI, we should also be careful to recognize that the URI is primarily used to generate a unique identifier, rather than as a reference location for either humans or machines. regards, Ted Graham wrote: > In order to match a pair of feature sets (e.g. to determine if a particular > document can be processed by a particular receipient, where both are > described by a feature set per [3]) a protocol processor must be able to > recognize and process feature tag values to the extent of being able to > perform equality and precedence comparisons. The remainder of this memo > discusses ways in which a protocol processor might understand how to > recognize and process feature values. Requirement stated here.... > Built-in types might be: > Integer, using decimal representation. > Real, using fixed-point decimal representation. > Token, using for example 'token' syntax per RFC 2045; equality matching > only. Doesn't a boolean need to be in the built-in types? > The "TIFF" case in [2] is interesting because the profiles of TIFF are > defined as a set of increasing capabilities, so it is natural to treat them > as a set of ordered tokens. This would allow a recipient to describe its > capabilities as 'TIFF<=M', meaning that it could handle any profile of TIFF > up to and including "M". This case cannot be easily handled by the simple > set of types described above as there is no way fora protocol processor to > know how to rank TIFF profile values. The TIFF profiles are, in essence, already feature collections, aren't they? This raises the question of whether the processing on feature collections is the same as the processing on individual features. The simplest answer is to restrict feature collection processing to a boolean, with a yes meaning "capable of everything in this collection" . If users are consistently trying to break these collection back down (TIFF profile M, minus JBIG, for example), then we probably have the wrong features aggregated into a collection. > > > 4.2 Protocol-dependent built-in types > > A simple extension of the above idea is to assume that types beyond the > core set suggested are known to protocol processors which might have to > recognize them. > > If the protocol processor components which handle negotiation are closely > associated with the components which process the data, this is a reasonable > position. But it is also possible to envisage negotiating components which > do not understand the data about which they are negotiating. > > For example, in Internet fax, it is reasonable to expect that specialized > Internet fax handling components will know about TIFF profiles. But it is > not so reasonable to assume that a general-purpose e-mail client (which may > usefully receive Internet fax messages) will know enough about TIFF > profiles to know how to rank them. > Does this same proble occur when we consider TIFF profiles as collections, rather than features? That is, can you think of an example where the basic feature is defined in a way that is uniquely (or even principally) tied to a specific procoessing method? > > Another approach which might work for small token-sets like TIFF would be > to carry the set of possible values in the feature value itself. For > example, from [4], Tiff profile J might be described as > TIFF=J(S,F,J,C,L,M). Then, a generic negotiating protocol processor could > know how to rank TIFF token values. I assume this syntax means that J implies support for S,F,J,C,L, and M. I can see this as a useful methof of indicating what features a collection contains (even when those features are other collections), but I don't see how you can determine a ranking from that, unless you limit it to J is a better option than any single one of the others. >Rounding error description elided here Your description of rounding error certainly illustrates the problem and hints that we may have to insure that each feature has a single unit associated with it, leaving it up to applications to take the risk of creating equivalencies where they believe two features can be inter-converted. regards, Ted Hardie NASA NIC From owner-ietf-medfree Tue Apr 7 10:41:50 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA26714 for ietf-medfree-bks; Tue, 7 Apr 1998 10:41:50 -0700 (PDT) Received: from info.dsv.su.se (info.dsv.su.se [130.237.161.221]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA26710 for ; Tue, 7 Apr 1998 10:41:49 -0700 (PDT) Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138]) by info.dsv.su.se (8.8.8/8.8.8) with ESMTP id TAA27325; Tue, 7 Apr 1998 19:41:40 +0200 (MET DST) X-Sender: jpalme@mail.dsv.su.se Message-Id: In-Reply-To: <9804061524.ZM15213@thornhill.arc.nasa.gov> References: Andy Mutz "Re: Political, social or value judgements" (Apr 6, 3:07pm) <199804062207.PAA29025@hplumen.cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 7 Apr 1998 12:05:12 +0200 To: hardie@nic.nasa.gov, andy_mutz@hp.com From: Jacob Palme Subject: Re: Political, social or value judgements Cc: ietf-medfree@imc.org Sender: owner-ietf-medfree@imc.org Precedence: bulk At 00.24 +0200 98-04-07, Ted Hardie wrote: > If those exchange > methods can be used for other purposes, that's fine, > but we are explicitly not constrained to meet those > purposes in our design work here. So you are not forbidding features with social or political content, just not including them in your present work. That seems reasonable. ------------------------------------------------------------------------ Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme From owner-ietf-medfree Tue Apr 7 16:23:59 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA29991 for ietf-medfree-bks; Tue, 7 Apr 1998 16:23:59 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id QAA29987 for ; Tue, 7 Apr 1998 16:23:57 -0700 (PDT) Received: (qmail 13086 invoked from network); 7 Apr 1998 23:23:52 -0000 Received: from ah197.du.pipex.com (HELO ietf-11-252.mtg.ietf.org) (193.130.247.197) by smtp.dial.pipex.com with SMTP; 7 Apr 1998 23:23:52 -0000 Message-Id: <3.0.32.19980408002306.007b4750@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 08 Apr 1998 00:24:41 +0100 To: hardie@nic.nasa.gov From: Graham Klyne Subject: Re: Senarios for feature matching Cc: conneg WG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 16:32 06/04/98 -0700, Ted Hardie wrote: >Graham, > Thanks for your notes on these issues; I have >made some comments within the text excerpted below. My >general comment, though, is that we may wish to focus on >the type declarations for registration. If we do that right, >one of the advantages to going through the registration >process will be that the types will be well-known to potential >users of the feature. If I understand you correctly, this corresponds to my "closed protocol" case: the negotiating protocol knows in advance of all the features it is likely to encounter. But what about (say) a Web client/server: these are components of a very general resource-fetching application, and place no constraints on the type of resource that may be fetched (and hence the kinds of negotiable feature that might be encountered). Or in a more restricted case, consider negotiation of additions in HTCPCP [RFC2324], where the additions are ranked by the order in which they should optimally be introduced into the cofee. RFC2324 defines: addition-type = ( "*" | milk-type | syrup-type | sweetener-type | spice-type | alcohol-type ) *( ";" parameter ) These might correspond to an addition feature with values: sweetener < syrup < alcohol < milk < spice Suppose I wish to introduce a new addition-type, whipped-cream, which is added after milk but before spice. How is this new relationship to be defined to an HTCPCP processor which is already in use? Must I return my coffee-pot for an upgrade? >... For those features referenced by a >URI, we should also be careful to recognize that the URI >is primarily used to generate a unique identifier, rather >than as a reference location for either humans or machines. A timely note. I had a train of thought which allowed that the URI might be the reference to a machine-readable description. I do not know if this would be a Good Idea or a Bad Idea, other than noting that the original injtent here was for the URI to be an identifier. (BTW, would it be an idea for the registration document to reference the GUID URI scheme rather than using http: URLs (which, to me, seems perverse for names which have nothing to do with http). >Requirement stated here.... >> Built-in types might be: >> Integer, using decimal representation. >> Real, using fixed-point decimal representation. >> Token, using for example 'token' syntax per RFC 2045; equality matching >> only. > >Doesn't a boolean need to be in the built-in types? Oh yes... I meant to include that! (It could be argued as a Token value, but I did not intend to follow that route.) >> The "TIFF" case in [2] is interesting because the profiles of TIFF are >> defined as a set of increasing capabilities, so it is natural to treat them >> as a set of ordered tokens. This would allow a recipient to describe its >> capabilities as 'TIFF<=M', meaning that it could handle any profile of TIFF >> up to and including "M". This case cannot be easily handled by the simple >> set of types described above as there is no way fora protocol processor to >> know how to rank TIFF profile values. > >The TIFF profiles are, in essence, already feature collections, aren't they? As presented in that reference (Media features draft), they are individual feature values. They may be some collection of lower-level features associated with them, but that's opaque to the feature registration and expression framework as currently proposed. >This raises the question of whether the processing on feature collections >is the same as the processing on individual features. The simplest >answer is to restrict feature collection processing to a boolean, with >a yes meaning "capable of everything in this collection" . >If users are consistently trying to break these collection back down >(TIFF profile M, minus JBIG, for example), then we probably have >the wrong features aggregated into a collection. Yes, I agree. This also touches on the whole issue of registration of feature sets -- I have some ideas in this are and shall try and write them up, but don't expect a posting until after next week. I think that if a "feature collection" is expressed as a single feature, then the collection thus expressed must be a simple type: Boolean (as in this set of features is present), or a Token enumeration (as in this combination of several possible combinations is present -- as in the case of proposed TIFF=x). I also think that a feature collection might conceivably be modified by some separate statement (as in your example), but this would require some understanding (possibly made explicit in the feature registration) that the expression of the individual feature (e.g. JBIG) would override the contrary indication of the "larger" feature expression (e.g. TIFF=M). >> For example, in Internet fax, it is reasonable to expect that specialized >> Internet fax handling components will know about TIFF profiles. But it is >> not so reasonable to assume that a general-purpose e-mail client (which may >> usefully receive Internet fax messages) will know enough about TIFF >> profiles to know how to rank them. >> > >Does this same proble occur when we consider TIFF profiles as collections, >rather than features? That is, can you think of an example where the >basic feature is defined in a way that is uniquely (or even principally) >tied to a specific procoessing method? I don't think so. All a generic negotiation protocol processor needs to know is how to compare for equality and (if relevant) ordering of two values. Interpretation of meaning of a feature value (e.g. when processing the data) is, in my view, a separate issue not related to negotiation. >> Another approach which might work for small token-sets like TIFF would be >> to carry the set of possible values in the feature value itself. For >> example, from [4], Tiff profile J might be described as >> TIFF=J(S,F,J,C,L,M). Then, a generic negotiating protocol processor could >> know how to rank TIFF token values. > >I assume this syntax means that J implies support for S,F,J,C,L, and M. No: it means only that J is "greater than" S and F, and "less than" C, L and M. In the case if TIFF, this ordering is used is expressions like TIFF<=J to mean that J implies support for S and F. But the negotiation protocol would know nothing of this, only that TIFF<=J is true for TIFF=S, TIFF=F or TIFF=J. >I can see this as a useful methof of indicating what features a collection >contains (even when those features are other collections), but >I don't see how you can determine a ranking from that, unless you limit >it to J is a better option than any single one of the others. In that example, the order of feature values in the list was meant imply an ordering for the purposes of the '<' operator. That's all! Actually, I don't think this is a great idea: to my mind it's too closed. But it might just be better than the alternatives. >>Rounding error description elided here > >Your description of rounding error certainly illustrates the problem >and hints that we may have to insure that each feature has a single >unit associated with it, leaving it up to applications to take the risk >of creating equivalencies where they believe two features can be >inter-converted. Actually, I don't think the conversion-error problem goes away when limiting to a single unit -- it just pushes it somewhere else. If a registration mandates a given unit, and a negotiating application uses a different unit, then unit conversions (hence possible conversion errors) are still incurred. ------------ Graham Klyne From owner-ietf-medfree Tue Apr 7 19:44:06 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id TAA01872 for ietf-medfree-bks; Tue, 7 Apr 1998 19:44:06 -0700 (PDT) Received: from access5.digex.net (qlE46B5DiGQyA@access5.digex.net [205.197.245.196]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id TAA01868 for ; Tue, 7 Apr 1998 19:44:05 -0700 (PDT) Received: (from asgilman@localhost) by access5.digex.net (8.8.4/8.8.4) id WAA27019 for ietf-medfree@imc.org; Tue, 7 Apr 1998 22:44:04 -0400 (EDT) From: Al Gilman Message-Id: <199804080244.WAA27019@access5.digex.net> Subject: Re: Senarios for feature matching To: ietf-medfree@imc.org Date: Tue, 7 Apr 1998 22:44:04 -0400 (EDT) In-Reply-To: <3.0.32.19980408002306.007b4750@pop.dial.pipex.com> from Graham Klyne at "Apr 8, 98 00:24:41 am" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk to follow up on what Graham Klyne said: > At 16:32 06/04/98 -0700, Ted Hardie wrote: > >Graham, > > Thanks for your notes on these issues; I have > >made some comments within the text excerpted below. My > >general comment, though, is that we may wish to focus on > >the type declarations for registration. If we do that right, > >one of the advantages to going through the registration > >process will be that the types will be well-known to potential > >users of the feature. > > If I understand you correctly, this corresponds to my "closed protocol" > case: the negotiating protocol knows in advance of all the features it is > likely to encounter. [Al, here...] I don't follow this deduction. Is that what you meant, Ted? Or did you mean that each registration contains a type definition, and we need to work on what is in a type definition in a registration? In that case, the negotiating protocol can know all possible feature values only if it walks the entire registry. It can do that before it completes a negotiation, but not before it, say, is compiled. > But what about (say) a Web client/server: these are components of a very > general resource-fetching application, and place no constraints on the type > of resource that may be fetched (and hence the kinds of negotiable feature > that might be encountered). Yes, but only traits of the web object that are describable via registered characteristic definitions can be used in negotiation. You aren't interested in all traits of the web objects in a choice set, only enough characteristics to resolve which choice to make. That is a much smaller space. > Or in a more restricted case, consider negotiation of additions in HTCPCP > [RFC2324], where the additions are ranked by the order in which they should > optimally be introduced into the cofee. RFC2324 defines: > > addition-type = ( "*" > | milk-type > | syrup-type > | sweetener-type > | spice-type > | alcohol-type > ) *( ";" parameter ) > > These might correspond to an addition feature with values: > > sweetener < syrup < alcohol < milk < spice > > Suppose I wish to introduce a new addition-type, whipped-cream, which is > added after milk but before spice. How is this new relationship to be > defined to an HTCPCP processor which is already in use? Must I return my > coffee-pot for an upgrade? If it implements the RFC, you can't. If it implements the registry, you can simply register sweetener < syrup < alcohol < milk < whipped-cream < spice as a type, identifying the homograph tokens with their correlates in the HTCPCP RFC, and you are done. [Not that this teaches your Melitta to whip cream, but you get the point. Your InstaPresso will give you any order including whipped cream. Your legacy pot will implement all the cases it understands.] That is why, when you order your coffee with whipped cream, you had better list a fallback with milk... > > >... For those features referenced by a > >URI, we should also be careful to recognize that the URI > >is primarily used to generate a unique identifier, rather > >than as a reference location for either humans or machines. > > A timely note. I had a train of thought which allowed that the URI might > be the reference to a machine-readable description. I do not know if this > would be a Good Idea or a Bad Idea, other than noting that the original > injtent here was for the URI to be an identifier. (BTW, would it be an > idea for the registration document to reference the GUID URI scheme rather > than using http: URLs (which, to me, seems perverse for names which have > nothing to do with http). The URI is a sufficient key and not necessarily a unique identifier. There can be more than one URI which refers to the same feature. [length-magnitudes:meter, MKS-units:meter] It can be a URN that draw from a known name scheme or a URL linking to a retrievable definition of a more general nature. Whether an http: URL or an URN, it should definitely be a sufficient key for humans. And for machines. Exercising an URN does not necessarily involve network communication, of course, if you have a valid lookup capability locally (or were compiled in the context of..). As to whether there are machine- interpretable texts at the far end of the URI is a matter of usage, which is specifically left open as a possibility by allowing the general "URI" type for what a feature reference may contain. Al Gilman From owner-ietf-medfree Wed Apr 8 02:04:23 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id CAA16927 for ietf-medfree-bks; Wed, 8 Apr 1998 02:04:23 -0700 (PDT) Received: from worldnet (m70.ulink.net [209.160.21.70]) by mail.proper.com (8.8.8/8.7.3) with SMTP id CAA16923 for ; Wed, 8 Apr 1998 02:04:21 -0700 (PDT) From: webmaster@tiffiny.com Message-Id: <199804080904.CAA16923@mail.proper.com> Date: Wed, 8 Apr 1998 02:39:50 To: Subject: free advertising for your business Sender: owner-ietf-medfree@imc.org Precedence: bulk Hello: FREE ADVERTISING FOR YOUR BUSINESS One of the most important parts of your business is advertising. Without your prospects knowing about your product or service, you're out of business. Along with the necessity of advertising comes the huge costs normally associated with a successful advertising campaign. It's expensive... That is UNTIL NOW !!! I can show you how to reach thousands of prospects that have an exact interest in your products or services for FREE !!! To learn more, just send me an email message and I'll send you a Free Report showing you exactly how this is done. Request this valuable information by sending me an email by 1) double clicking on this link and then pressing your send key. <"mailto:webmaster@tiffiny.com?subject=Tell_me_more"> or 2, you can manually use your email program to send me a note requesting this Free Report. Send to: webmaster@tiffiny.com with the subject of "Tell me more". Don't miss out on this great and rewarding FREE opportunity. ================================ If you don't want to hear about this free program, then respond to this letter with the words No More in the subject line. Thank You. From owner-ietf-medfree Wed Apr 8 07:14:18 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id HAA20837 for ietf-medfree-bks; Wed, 8 Apr 1998 07:14:18 -0700 (PDT) Received: from access1.digex.net (qlE46B5DiGQyA@access1.digex.net [205.197.245.192]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id HAA20833 for ; Wed, 8 Apr 1998 07:14:16 -0700 (PDT) Received: (from asgilman@localhost) by access1.digex.net (8.8.4/8.8.4) id KAA17933 for ietf-medfree@imc.org; Wed, 8 Apr 1998 10:14:17 -0400 (EDT) From: Al Gilman Message-Id: <199804081414.KAA17933@access1.digex.net> Subject: Re: Senarios for feature matching To: ietf-medfree@imc.org Date: Wed, 8 Apr 1998 10:14:17 -0400 (EDT) In-Reply-To: <3.0.32.19980408002306.007b4750@pop.dial.pipex.com> from Graham Klyne at "Apr 8, 98 00:24:41 am" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk One scenario for feature value comparison (feature expression reduction) is that the registration contains: * A grammar for feature expressions. * [An alternate grammar for the representation of said feature expressions in URLs] * The base URL for a public expression evaluator for expressions dealing in this characteristic. This is the simplest way to support an operationally-defined feature class across the whole Internet. This give the maximum performance on expressivity and reach scales. CPU and wall-clock time to complete negotiation will be better for other techniques. Some effort will be required to police the consistency of expression evaluations and continuity of service of the expression evaluation resource. Al Gilman From owner-ietf-medfree Wed Apr 8 07:33:16 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id HAA20976 for ietf-medfree-bks; Wed, 8 Apr 1998 07:33:16 -0700 (PDT) Received: from access1.digex.net (qlE46B5DiGQyA@access1.digex.net [205.197.245.192]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id HAA20972 for ; Wed, 8 Apr 1998 07:33:13 -0700 (PDT) Received: (from asgilman@localhost) by access1.digex.net (8.8.4/8.8.4) id KAA18439; Wed, 8 Apr 1998 10:33:19 -0400 (EDT) From: Al Gilman Message-Id: <199804081433.KAA18439@access1.digex.net> Subject: roundoff erros and primitive types To: ietf-medfree@imc.org Date: Wed, 8 Apr 1998 10:33:19 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk Yes, Boolean is a primitive type of the type system for content [negotiation] characteristics. Many type system extensions can be defined entirely in terms of the boolean-valued expressions which can be formed using values of that type. On the other hand we have quality factors. Quality factors are a primitive class, not a primitive type. Approximation is intrinsic to this class, and "Am I close?" is a central question. Arithmetic operations are appropriate for quality factors. What to do with roundoff errors? I think that the answer lies in how quality factors are to be used. One should never discard their last option based on quality factors and hard-limiting thresholds. If it is understood that quality factors are used in the root method to prioritize among feasible options, then roundoff is not an issue. If two options are within a roundoff error of one another in quality factor, then either will do and an arbitrary choice between the runoff candidates is sufficient. The ability of the negotiation vocabulary to cast light on the choice has been exhausted without yielding a unique answer. But not without yielding a good answer. To carry this to the root method, we need to make sure that there is a primitive quality factor class in the type system. And that extension types whose operations return either Boolean or quality factor can be supported. Al Gilman Implementation note: Yes, you will decide on a standard [i.e. default] type for representing values in this class. But the standard type [e.g. eight bits of unsigned fraction] is not the notional primitive. The notion is not one of an enumeration of 2**8 values; it is of an arithmetic quantity between 0 and 1. From owner-ietf-medfree Wed Apr 8 07:42:25 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id HAA21024 for ietf-medfree-bks; Wed, 8 Apr 1998 07:42:25 -0700 (PDT) Received: from access1.digex.net (access1.digex.net [205.197.245.192]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id HAA21020 for ; Wed, 8 Apr 1998 07:42:24 -0700 (PDT) Received: (from asgilman@localhost) by access1.digex.net (8.8.4/8.8.4) id KAA18635; Wed, 8 Apr 1998 10:42:03 -0400 (EDT) From: Al Gilman Message-Id: <199804081442.KAA18635@access1.digex.net> Subject: [tranparent?] content negotiation To: ietf-medfree@imc.org Date: Wed, 8 Apr 1998 10:42:03 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk This may be an issue that you resolved long ago, but I want to put in a plug for seamless integration of an escape to manual decision. In other words, if "transparent content negotiation" means "morph selection transparent to the user" I would like suggest that the registry is to support features for [not necessarily transparent] content negotiation, and that TCN is the subset of content negotiation where the negotiation process closes on a deal without ever querying the user. This is inspired by the "cup of coffee" case discussed earlier. If the user requests a cup of coffee with whipped cream and no milk, and the server only knows the characteristic definition containing no whipped cream, then the fact that all the other requested characteristics can be satisfied by the legacy type could be basis for a user query "We don't have whipped cream, would you like milk in your coffee?" Al Gilman From owner-ietf-medfree Wed Apr 8 09:03:50 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id JAA22183 for ietf-medfree-bks; Wed, 8 Apr 1998 09:03:50 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.7.3) with SMTP id JAA22179 for ; Wed, 8 Apr 1998 09:03:49 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA17536 for ietf-medfree@imc.org; Wed, 8 Apr 1998 09:03:58 -0700 Date: Wed, 8 Apr 1998 09:03:58 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9804080903.ZM17534@thornhill.arc.nasa.gov> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: ietf-medfree@imc.org Subject: draft minutes Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19804080903.ZM17534.arc.nasa.gov" Sender: owner-ietf-medfree@imc.org Precedence: bulk -- --PART-BOUNDARY=.19804080903.ZM17534.arc.nasa.gov Content-Type: text/plain; charset=us-ascii Attached are draft minutes for the meeting in L.A. please send comments to me by 5 pm Thursday, April 9, 1998, so that I can send these up to the ADs. regards, Ted Hardie NASA NIC --PART-BOUNDARY=.19804080903.ZM17534.arc.nasa.gov X-Zm-Content-Name: minutes Content-Description: Text Content-Type: text/plain ; name="minutes" ; charset=us-ascii Minutes of CONNEG meeting, LA IETF, Thursday 4/2/98. chair: Ted Hardie minutes: April Marine Agenda for meeting consisted of discussing the pending drafts, then editing the milestones (plus any other biz). The pending drafts are: Feature Registration Draft draft-ietf-conneg-feature-reg-00.txt Media Features Draft draft-ietf-conneg-media-features-00.txt MDN Features Draft draft-ietf-fax-mdn-features-00.txt Requirements Draft draft-ietf-conneg-requirements-00.txt Algebra Draft draft-ietf-conneg-feature-algebra-00.txt 1. Feature Registration Draft discussion, led by Andy Mutz. Andy summarized the points in his draft. The draft deals with the points of who should register content feature tags, what should be registered, and why. Also, the procedures for registration. There are many situations where one would like to have a common set of features to negotiate over, so sharing a set of tags would be beneficial, even across protocols. This draft deals with registration of tags, not exchanging them or negotiating them. Andy discussed the feature tag syntax, and the point was made that the less syntax used the better, as the method would then be more applicable across protocols (requiring less escaping of reserved characters). The point was made that the security considerations section of the registration form is not optional. A question arose that there may be problems trying to describe security problems at the registration level, since there was no way of knowing how a protocol would handle the information. The response was an example of type type of security consideration that might apply at this level. If, for example, you wanted to register something like "display=braille", it would be clear that you are potentially sharing info for a preference for a braille terminal, which may raise a privacy concern or issue. Therefore, it is useful for the purpose of a registration that you express that type of concern in the security considerations section, even if you don't know how a protocol might use the feature. The point was made that while the IANA registers things, it does not necessarily catch conflicts. So, if someone registers "paper type" and then someone else wants "paper size" with same features, how can we make sure both are not not registered? The suggestion was that we could send proposed features to a mailing list; i.e. that people would be encouraged to send proposals there, but not required to do so. Finally, the point was made by the chair that it is necessary to bring this draft in line with the recent IANA Considerations document, which provides guidelines on working with the IANA. For example, things can be vetted via an RFC or via review by a designated expert, but not really via a mailing list. The group was encouraged to read that paper and that discussion was taken to the list. 2. Media Features Draft discussion was led by Larry Masinter. This draft deals with media features for display, print, or fax. It started with the question of how a browser might tell a server what display size was optimal, but also discussed more generally what a recipient might want to tell a server about itself. There were only two pending issues identified re this draft. The second open issue was non-contentious. It dealt with the question of why one should have pixel size and resolution and paper size all as features because can't one derive, say, paper size if one knows the other two? The response was, possibly, but it is not necessary true that one always know the "other" two, so all are needed. The greatest part of the discussion on this draft dealt with the question of the unit of measurement for resolution. Should it be in pixels per inch (as the draft currently says) or pixels in a metric measurement. That is, should the "English" (inches) unit be used or should pixels be expressed in a per millimeter value? Long discussion of the pluses and minuses of each and several ways the options could be expressed (e.g. with a separate value for unit). Discussion of how it is done in VCARD and how it is done in the FAX community, etc. Different communities have different conventions. Impossible to come to resolution during meeting and time was passing; taken to list. 3. The next topic was the inclusion of media features in email directories. Currently the email address information is part of the person schema and cannot itself accept additional attributes. However, it would be useful to know if someone's email address could accept particular media features, such as, can a particular email address accept a high-resolution color tiff value? The point was made that this work sounds like an application of the registration values the group is creating, i.e. another context that can handle a media feature list. So, the request was made for help in developing a way to describe features of email addresses. Larry rounded up a volunteer to help. 4. Next draft discussed was MDN features, led by Dan Wing. This is a draft from the FAX group, which is a discussion of how one might pass features using MDN. It was discussed in this group because it might have uses beyond the fax community regarding how to get features flowing between interested participants. Use of this method would eliminate the need to have something like a "user can receive HTML" or "text enriched" check box because the MDN would contain all the features a recipient has and once that info is passed, it would eliminate the need to send the recipient anything it can't accept or ask further what the recipient can handle. The group was encouraged to read the draft. 5. Graham Klyne was next up to talk about two drafts he has written. First he discussed the Requirements Draft. Graham summarized the points made in the document; there were few comments. The basic approach was to include every related requirement that could be found and make them available for discussion and winnowing. The desire was to have a common vocabulary for features and feature sets, and to have an extensible framework that could adopt new features easily. A requirement was that one must be able to describe features both individually and in sets. The doc has a framework proposal for how content negotiated elements can be developed across protocols and applied to different protocols appropriately. 6. Graham continued with his Feature Algebra document. This draft came about from a study of HTTP transport content negotiation because that mechanism seemed very ad hoc, with no underlying framework. The structure suggested in this document allows for feature comparisons and the use of logical operators. It is proposing a syntax based on the LDAP filter string model in RFC 2254, with a few shortcut conveniences in notation. A key to the work is the knowledge that real negotiation will take place on collections of features, so there is a need to bundle features into collections that can be compared. Work remaining includes a need for a description of preferences and a syntax for text representation. Also the comment was made that this approach is different from that taken in the IPP group and a possible future topic would be to work to more closely align the two approaches. 7. The final topic was a re-evaluation of the milestones as noted in the charter. Feb 98 Submission of registration procedure draft as BCP Moved to June 1. Pending: resolve ASN.1 questions; revise to meet IANA Considerations requirements Feb 98 First draft of Requirements and frameworks document. Done. Feb 98 Submission of feature scenarios draft as Informational RFC Deleted. Falls under charter of FAX WG, so work will be reviewed when it comes out of that group. Mar 98 Revised draft of Requirements and frameworks document. Moved to May 1. Pending: Graham is waiting for feedback. Mar 98 First draft of composite feature set draft. Done. May 98 Requirements and frameworks document to Information RFC Moved to August. May 98 Revised feature set draft Stays at May. Jul 98 Feature set draft to Informational RFC Stays at July. Aug 98 Working Group Closes Add: Media Features Registration Doc; June 1 (depends on registration procedure doc). Group is still looking to close after Chicago. --PART-BOUNDARY=.19804080903.ZM17534.arc.nasa.gov-- From owner-ietf-medfree Wed Apr 8 09:50:18 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id JAA22755 for ietf-medfree-bks; Wed, 8 Apr 1998 09:50:18 -0700 (PDT) Received: from wsooti20.win.tue.nl (koen@wsooti20.win.tue.nl [131.155.70.27]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id JAA22751 for ; Wed, 8 Apr 1998 09:50:12 -0700 (PDT) Received: from koen@localhost by wsooti20.win.tue.nl (8.8.7) id SAA08577. Wed, 8 Apr 1998 18:50:01 +0200 (MET DST) From: koen@win.tue.nl (Koen Holtman) Message-Id: <199804081650.SAA08577@wsooti20.win.tue.nl> Subject: Re: [tranparent?] content negotiation To: asgilman@access.digex.net (Al Gilman) Date: Wed, 8 Apr 1998 18:50:00 +0200 (MET DST) Cc: ietf-medfree@imc.org In-Reply-To: <199804081442.KAA18635@access1.digex.net> from "Al Gilman" at Apr 8, 98 10:42:03 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ietf-medfree@imc.org Precedence: bulk Al Gilman: > >This may be an issue that you resolved long ago, but I want to >put in a plug for seamless integration of an escape to manual >decision. > >In other words, if "transparent content negotiation" means "morph >selection transparent to the user" It does not mean that at all. TCN _will_ ask the user if it cannot find a suitable variant itself. The transparent does not mean `invisible to the user', it means that all content inside the server is visible from the outside. >Al Gilman Koen. From owner-ietf-medfree Thu Apr 9 05:22:20 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id FAA16509 for ietf-medfree-bks; Thu, 9 Apr 1998 05:22:20 -0700 (PDT) Received: from mail.gic.ch (hypros.ch [194.235.1.10] (may be forged)) by mail.proper.com (8.8.8/8.7.3) with SMTP id FAA16504 for ; Thu, 9 Apr 1998 05:22:17 -0700 (PDT) Message-Id: <199804091222.FAA16504@mail.proper.com> Received: from gkb [194.235.1.10] by mail.gic.ch (SMTPD32-4.03) id AD3213C30152; Thu, 09 Apr 1998 14:21:06 +03d00 From: GIC To: Date: Thu, 09 Apr 1998 12:21:04 "GMT" X-MSMail-Priority: Normal X-mailer: AspMail 2.4 (SMTP669585) Subject: GKB FREE SERVICES UPDATE (4/98) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk Update on Global KnowledgeBase (http://gkb.com) free internet services. (4/98) Dear gkb user, Thanks to you, our campaign for Global KnowledgeBase (http://gkb.com) is continues to be a great success attracting more than 4000 unique users/daily. Continue to Explore and Contribute to create the accumulated knowledge in gkb.com, for the benefit of all. To login to the GKB applications please use the gkb login as follows: Your login ID : ietf-medfree@imc.org GKB User Code : 7508 New features ============ Global Journal - The newest and most dynamic meduim to exchange internet knowledge, in Global Journal, you, the GKB user, have the opportunity to express your opinion, provide newsworthy internet links, or cite facts. GlobalShop - best source of information on over 60,000 products listed, giving direct access to the price lists of the best known, compare prices, look for new models and benefit from special offers. Build your e-commerce, integrate your own catalog in Global Shop for free. Global Free - Explore and Contribute to the free Internet services knowledgebase Web messaging - if you have an email address @gkb.com (which is free), explore your Email directly on the web. Personal&Email KB - If you are looking for users sharing the your area of interests, or simply email of users in your area. GlobalChat - web based chat for all The old and successful free features are always there. ===================================================== Interactive Classifieds - Free interactive classifieds segmented by marketplace and criteria (more than 8000 ads in Geneva area only) Press Releases - Free press release publication. Business Guide - Free business internet site application GlobalJob - Free job listing for companies, and free CV listing for individuals. Business Opportunities - Free business opporrtunities publication by marketplace/industry Free email addresses at gkb.com are always available. Global Finance - gkb financial knowledgebase Global Events - free events listing in the events knowledgeBase We hope you will find the new and old feature useful. Regards Gkb team From owner-ietf-medfree Thu Apr 9 19:01:17 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id TAA24441 for ietf-medfree-bks; Thu, 9 Apr 1998 19:01:17 -0700 (PDT) Received: from dfw-ix10.ix.netcom.com (dfw-ix10.ix.netcom.com [206.214.98.10]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id TAA24437; Thu, 9 Apr 1998 19:01:16 -0700 (PDT) Received: (from smap@localhost) by dfw-ix10.ix.netcom.com (8.8.4/8.8.4) id VAA12984; Thu, 9 Apr 1998 21:00:58 -0500 (CDT) Message-Id: <199804100200.VAA12984@dfw-ix10.ix.netcom.com> Received: from motnt05-491.stlnet.com(209.96.70.237) by dfw-ix10.ix.netcom.com via smap (V1.3) id rma012937; Thu Apr 9 21:00:23 1998 X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 09 Apr 1998 21:01:21 -0500 To: ietf-fax@imc.org From: Richard Shockey Subject: Chip based Capabilities??? Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk A friend of mine who was at IETF-LA mentioned to me in a private conversations that ... >Intel was pushing hard in the DHCP working group for Global Unique IDs for chip >boards (of any type; e.g., in a fax machine, phone, PC, set-top, etc.). These >IDs could then be linked with DCHP boots, the service location protocol, LDAP >directories, etc. Other WG attendees were pushing back, saying >that IDs are already available by chip (Intel, MIPS, Alpha, etc.), and that >these work fine. Intel (and I'm sure others) are thinking more broadly -- >i.e., plug any device into the network and have it recognize your >capabilities/setup Was anyone at th DHCP group that could comfirm this.... of any interest to the work a hand?? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey 8045 Big Bend Blvd. Suite 110 St. Louis, MO 63119 Voice 314.918.9020 Fax 314.918.9015 INTERNET Mail & IFAX : rshockey@ix.netcom.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From owner-ietf-medfree Thu Apr 9 19:28:37 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id TAA24647 for ietf-medfree-bks; Thu, 9 Apr 1998 19:28:37 -0700 (PDT) Received: from bichon.cisco.com (bichon.cisco.com [171.69.1.209]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id TAA24643; Thu, 9 Apr 1998 19:28:36 -0700 (PDT) Received: from gclark-pc.cisco.com (sj-dial-1-100.cisco.com [171.68.180.101]) by bichon.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id TAA00833; Thu, 9 Apr 1998 19:27:37 -0700 (PDT) Message-Id: <3.0.32.19980409192143.0084e980@bichon.cisco.com> X-Sender: gclark@bichon.cisco.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 09 Apr 1998 19:21:45 -0700 To: Richard Shockey , ietf-fax@imc.org From: Glen Clark Subject: Re: Chip based Capabilities??? Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk As long as copy machines get and id of 666 I'm ok with it. ;-) Cheers .... Glenc At 09:01 PM 4/9/98 -0500, Richard Shockey wrote: > >A friend of mine who was at IETF-LA mentioned to me in a private >conversations that ... > >>Intel was pushing hard in the DHCP working group for Global Unique IDs for >chip >>boards (of any type; e.g., in a fax machine, phone, PC, set-top, etc.). These >>IDs could then be linked with DCHP boots, the service location protocol, LDAP >>directories, etc. Other WG attendees were pushing back, saying >>that IDs are already available by chip (Intel, MIPS, Alpha, etc.), and that >>these work fine. Intel (and I'm sure others) are thinking more broadly -- >>i.e., plug any device into the network and have it recognize your >>capabilities/setup > >Was anyone at th DHCP group that could comfirm this.... of any interest to >the work a hand?? > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >Richard Shockey >8045 Big Bend Blvd. Suite 110 >St. Louis, MO 63119 >Voice 314.918.9020 >Fax 314.918.9015 >INTERNET Mail & IFAX : rshockey@ix.netcom.com ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > From owner-ietf-medfree Tue Apr 14 12:24:22 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA06929 for ietf-medfree-bks; Tue, 14 Apr 1998 12:24:22 -0700 (PDT) Received: from default (cs1p28.mhiconn.net [206.58.152.38]) by mail.proper.com (8.8.8/8.7.3) with SMTP id MAA06925 for ; Tue, 14 Apr 1998 12:24:19 -0700 (PDT) Date: Tue, 14 Apr 1998 12:24:19 -0700 (PDT) Message-Id: <199804141924.MAA06925@mail.proper.com> From: Money Promotions X-Mailer: ArGoSoft MX Mailer v1.0 Subject: Accept Checks By Phone, Fax & Email!! (Reseller Opportunity) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk All it takes is a telephone, fax machine or e-mail account and you are ready to instantly take a check from anyone, anywhere. If you sell any product, anyone with a checking account can "impulse buy" from you, even if they don't have a credit card! The simply fax you their check, give you the information you need over the phone or via e-mail. You put this information into your computer using the "Checker" software. Your computer will then print a check that you can deposit into your business or personal account. No fees, no commissions, no hassles. Just sit back and watch your sales increase 24 hoursa day and your expenses decrease. You can resell the software at a price of $29.95. Since "Checker" is transmitted to you electronically, there are no overhead costs such as printing, packaging, disks, etc. You can resell "Checker" and pocket the entire $29.95. The price is right and the benefits are endless! Goto http://www.qspub.com for info and secure ordering. If you are not intrested in this offer, come by anyway for FREE classified advertising and links page!! From owner-ietf-medfree Thu Apr 16 12:21:46 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA09750 for ietf-medfree-bks; Thu, 16 Apr 1998 12:21:46 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id MAA09724 for ; Thu, 16 Apr 1998 12:21:41 -0700 (PDT) Received: (qmail 5438 invoked from network); 16 Apr 1998 19:22:21 -0000 Received: from am162.du.pipex.com (HELO ietf-11-252.mtg.ietf.org) (193.130.252.162) by smtp.dial.pipex.com with SMTP; 16 Apr 1998 19:22:21 -0000 Message-Id: <3.0.32.19980416104510.009fd2b0@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 16 Apr 1998 20:23:07 +0100 To: Al Gilman From: Graham Klyne Subject: Re: Senarios for feature matching Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 22:44 07/04/98 -0400, Al Gilman wrote: >to follow up on what Graham Klyne said: > >> At 16:32 06/04/98 -0700, Ted Hardie wrote: >> >Graham, >> > Thanks for your notes on these issues; I have >> >made some comments within the text excerpted below. My >> >general comment, though, is that we may wish to focus on >> >the type declarations for registration. If we do that right, >> >one of the advantages to going through the registration >> >process will be that the types will be well-known to potential >> >users of the feature. >> >> If I understand you correctly, this corresponds to my "closed protocol" >> case: the negotiating protocol knows in advance of all the features it is >> likely to encounter. > >[Al, here...] > >I don't follow this deduction. Is that what you meant, Ted? Or >did you mean that each registration contains a type definition, and >we need to work on what is in a type definition in a registration? > >In that case, the negotiating protocol can know all possible feature >values only if it walks the entire registry. It can do that before >it completes a negotiation, but not before it, say, is compiled. I am trying to draw a distinction between feature types which are known and understood before a program is compiled (these are easy to handle) and those whose operations must somehow be dynamically interpreted by the program using some form of external type definition (which I think is more difficult). >> But what about (say) a Web client/server: these are components of a very >> general resource-fetching application, and place no constraints on the type >> of resource that may be fetched (and hence the kinds of negotiable feature >> that might be encountered). > >Yes, but only traits of the web object that are describable via >registered characteristic definitions can be used in negotiation. >You aren't interested in all traits of the web objects in a >choice set, only enough characteristics to resolve which choice >to make. That is a much smaller space. In my view, the choice might still reasonably involve testing of types which were not known when the program was compiled. The issue here is not thje size of the type space, but whether or not it is extensible -- i.e. full knowledge of the types is built into the program. >> Or in a more restricted case, consider negotiation of additions in HTCPCP >> [RFC2324], where the additions are ranked by the order in which they should >> optimally be introduced into the cofee. RFC2324 defines: >> >> addition-type = ( "*" >> | milk-type >> | syrup-type >> | sweetener-type >> | spice-type >> | alcohol-type >> ) *( ";" parameter ) >> >> These might correspond to an addition feature with values: >> >> sweetener < syrup < alcohol < milk < spice >> >> Suppose I wish to introduce a new addition-type, whipped-cream, which is >> added after milk but before spice. How is this new relationship to be >> defined to an HTCPCP processor which is already in use? Must I return my >> coffee-pot for an upgrade? > >If it implements the RFC, you can't. If it implements the registry, >you can simply register > > sweetener < syrup < alcohol < milk < whipped-cream < spice > >as a type, identifying the homograph tokens with their correlates in >the HTCPCP RFC, and you are done. [Not that this teaches your Melitta >to whip cream, but you get the point. Your InstaPresso will give >you any order including whipped cream. Your legacy pot will implement >all the cases it understands.] > >That is why, when you order your coffee with whipped cream, you had >better list a fallback with milk... That was maybe not an ideal example. I agree with your response, but it misses the point I am trying to raise, which is: should we allow feature type extensibility, or should we require feature registrations to relate to predefined types? Comparing tokens for equality can be handled within a predefined type framework, but defining an ordered set of tokens requires a new type. #g ------------ Graham Klyne From owner-ietf-medfree Thu Apr 16 12:21:44 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA09740 for ietf-medfree-bks; Thu, 16 Apr 1998 12:21:44 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id MAA09729 for ; Thu, 16 Apr 1998 12:21:42 -0700 (PDT) Received: (qmail 5454 invoked from network); 16 Apr 1998 19:22:23 -0000 Received: from am162.du.pipex.com (HELO ietf-11-252.mtg.ietf.org) (193.130.252.162) by smtp.dial.pipex.com with SMTP; 16 Apr 1998 19:22:23 -0000 Message-Id: <3.0.32.19980416104805.009fdc40@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 16 Apr 1998 20:23:09 +0100 To: Al Gilman From: Graham Klyne Subject: Re: Senarios for feature matching Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk Al, I broadly agree. The point of my posting was to raise the issue: should we be considering such levels of flexibility (hence potential complexity)? And to try and identify the trade-offs involved. #g At 10:14 08/04/98 -0400, Al Gilman wrote: > >One scenario for feature value comparison (feature expression >reduction) is that the registration contains: > >* A grammar for feature expressions. > >* [An alternate grammar for the representation of said feature >expressions in URLs] > >* The base URL for a public expression evaluator for expressions >dealing in this characteristic. > >This is the simplest way to support an operationally-defined >feature class across the whole Internet. > >This give the maximum performance on expressivity and reach >scales. CPU and wall-clock time to complete negotiation will >be better for other techniques. > >Some effort will be required to police the consistency of >expression evaluations and continuity of service of the >expression evaluation resource. > >Al Gilman > ------------ Graham Klyne From owner-ietf-medfree Thu Apr 16 12:21:44 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA09741 for ietf-medfree-bks; Thu, 16 Apr 1998 12:21:44 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id MAA09726 for ; Thu, 16 Apr 1998 12:21:42 -0700 (PDT) Received: (qmail 5472 invoked from network); 16 Apr 1998 19:22:27 -0000 Received: from am162.du.pipex.com (HELO ietf-11-252.mtg.ietf.org) (193.130.252.162) by smtp.dial.pipex.com with SMTP; 16 Apr 1998 19:22:27 -0000 Message-Id: <3.0.32.19980416112552.009fd5d0@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 16 Apr 1998 20:23:13 +0100 To: Al Gilman From: Graham Klyne Subject: Re: [tranparent?] content negotiation Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 10:42 08/04/98 -0400, Al Gilman wrote: >This may be an issue that you resolved long ago, but I want to >put in a plug for seamless integration of an escape to manual >decision. I don't think the point has been made explicitly, but I fully agree. Indeed, to my mind this has been an implicit part of the debate so far. The purpose of the negotiation framework has been to provide a basis for exchange of feature capabilities and preferences so that a decision *can* be automated in some circumstances, not to force automation in any particular circumsance. The extent to which automation of choice is performed depends in part on the application within which content negotiation is deployed. I am taking the main thrust of this WG to define ways of identifying features, singly and in combination. I think the discussion of ranking is relevant because this has (or may have) a bearing on how feature combinations might be expressed. [...] >This is inspired by the "cup of coffee" case discussed earlier. > >If the user requests a cup of coffee with whipped cream and no >milk, and the server only knows the characteristic definition >containing no whipped cream, then the fact that all the other >requested characteristics can be satisfied by the legacy type >could be basis for a user query "We don't have whipped cream, >would you like milk in your coffee?" Again, I agree, but note that this is really a UI issue and is therefore beyond the scope of even a full content negotiation protocol. My view of a negotiation framework (per the -requirements- draft) is that it consists of a series of exchanges between sender and recipient of a message. Whether or not user interaction is involved in directing those exchanges is not indicated by the framework. #g ------------ Graham Klyne From owner-ietf-medfree Thu Apr 16 12:21:46 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA09752 for ietf-medfree-bks; Thu, 16 Apr 1998 12:21:46 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id MAA09745 for ; Thu, 16 Apr 1998 12:21:45 -0700 (PDT) Received: (qmail 5467 invoked from network); 16 Apr 1998 19:22:25 -0000 Received: from am162.du.pipex.com (HELO ietf-11-252.mtg.ietf.org) (193.130.252.162) by smtp.dial.pipex.com with SMTP; 16 Apr 1998 19:22:25 -0000 Message-Id: <3.0.32.19980416111555.00878d90@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 16 Apr 1998 20:23:11 +0100 To: Al Gilman From: Graham Klyne Subject: Re: roundoff erros and primitive types Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk Al, I have had some offline discussions about quality factors and ranking which I propose to write up and submit when I have time. This is the next major stage in development of the feature algebra. The plan is to use quality factors as a convenient mechanism for ranking, no more. In particular, there is a string desire to avoide doing arithmetic on quality factors, because that tends to impart deeper semantics to q-factors than they can practicaly posess. Another advantage is that the issues of roundoff, etc., do not occur when dealing with q-factors. Watch this space -- I'll try and get something posted in the next week or so. At 10:33 08/04/98 -0400, Al Gilman wrote: > >Yes, Boolean is a primitive type of the type system for content >[negotiation] characteristics. Many type system extensions can >be defined entirely in terms of the boolean-valued expressions >which can be formed using values of that type. Boolean has a special role in the type system, because it is a value which is used to denote set membership, which lies at the heart of the proposed feature expression algebra. Thus, expressions which define feature sets are Boolean expressions of feature collections ( Feature-set : Feature-collection -> Boolean ). >On the other hand we have quality factors. Quality factors are >a primitive class, not a primitive type. Approximation is >intrinsic to this class, and "Am I close?" is a central question. >Arithmetic operations are appropriate for quality factors. >What to do with roundoff errors? I think that roundoff errors are an artifact of the mechanism used and as such should not be accorded special recognition by the feature algebra. Rather, I would prefer to define ways to eliminate the artifact. That is not to say that genuinely approximate matches should not correspond to q-factors, but I would prefer to handle that separately, e.g.: (| (& (pix-x=1024) (pix-y=768) ) : q=1 (& (pix-x=[800,1024]) (pix-y=[600,768]) ) : q=0.9 (& (pix-x=[640,800]) (pix-y=[480,600]) ) : q=0.8 ) >I think that the answer lies in how quality factors are to be >used. One should never discard their last option based on >quality factors and hard-limiting thresholds. Agreed (if I understand you -- no 'magic' q-factor numbers). >... If it is >understood that quality factors are used in the root method to >prioritize among feasible options, then roundoff is not an issue. >If two options are within a roundoff error of one another in >quality factor, then either will do and an arbitrary choice >between the runoff candidates is sufficient. The ability of the >negotiation vocabulary to cast light on the choice has been >exhausted without yielding a unique answer. But not without >yielding a good answer. q-factors ae not part of the feature type system, they are part of the feature expression result, and as such I have concerns about translating rounding errors into q-factors arithmetically. For example, one might define a transfer function such that: (value=target) has a q-factor defined by: ( (value value/target, target/value ) To my mind, this tends to introduce a kind of "magic number" that I think we agree we wish to avoid, in that the q-factor of, say, 0.5 now has a very specific meaning which goes beyond mere ranking of preferences. No, I think that q-factor values must be assigned by the author of the feature expression. >To carry this to the root method, we need to make sure that there >is a primitive quality factor class in the type system. And that >extension types whose operations return either Boolean or quality >factor can be supported. As indicated above, I cannot agree with this point. To my view, the domain and range (argument types and result types) of feature expressions are and should be quite disjoint type systems. >Implementation note: Yes, you will decide on a standard [i.e. >default] type for representing values in this class. But the >standard type [e.g. eight bits of unsigned fraction] is not >the notional primitive. The notion is not one of an enumeration >of 2**8 values; it is of an arithmetic quantity between 0 and 1. Of course -- semantics and syntax! #g ------------ Graham Klyne From owner-ietf-medfree Thu Apr 16 16:00:38 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA19685 for ietf-medfree-bks; Thu, 16 Apr 1998 16:00:38 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.7.3) with SMTP id QAA19681 for ; Thu, 16 Apr 1998 16:00:37 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA26985; Thu, 16 Apr 1998 16:01:20 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <199804162301.QAA26985@thornhill.arc.nasa.gov> Subject: Re: [tranparent?] content negotiation To: GK@ACM.ORG (Graham Klyne) Date: Thu, 16 Apr 1998 16:01:20 -0700 (PDT) Cc: asgilman@access.digex.net, ietf-medfree@imc.org In-Reply-To: <3.0.32.19980416112552.009fd5d0@pop.dial.pipex.com> from "Graham Klyne" at Apr 16, 98 08:23:13 pm X-Mailer: ELM [version 2.4 PL24 ME5a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk > > At 10:42 08/04/98 -0400, Al Gilman wrote: > >This may be an issue that you resolved long ago, but I want to > >put in a plug for seamless integration of an escape to manual > >decision. And Graham replied, in part.. > > My view of a negotiation framework (per the -requirements- draft) is that > it consists of a series of exchanges between sender and recipient of a > message. Whether or not user interaction is involved in directing those > exchanges is not indicated by the framework. > I think we need to be careful with this as a design goal. I agree that we want any system to allow for user input or over-ride if there is a user present, but we also need to acknowledge that there won't always be a user present and the sender won't always know whether a user is present before the fact . Imagine someone away from their office and not near a network, forwarding their mail to a fax machine where they are--a user agent that previously could handle escaping to one form interaction with a user, now is a forwarding mechanism to a different system entirely, without user intervention. With a well-designed negotiation framework, we should still be able to handle negotiation here, provided both email agent and fax are negotiation-aware, but we can't count on a user to help in the process. I realize that this an old exhortation for most of us, but I think it bears occasional repetition. (By the way, I am currently in Australia and will only have net access myself for another day, so please forgive me if I go offline before replying to further messages on this thread. My next destination doesn't even have a fax machine to forward my mail to). regards, Ted Hardie NASA NIC From owner-ietf-medfree Thu Apr 16 20:42:21 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id UAA21880 for ietf-medfree-bks; Thu, 16 Apr 1998 20:42:21 -0700 (PDT) Received: from pop.hallandsposten.se (pop.hallandsposten.se [193.13.112.8]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id UAA21876 for ; Thu, 16 Apr 1998 20:42:19 -0700 (PDT) Date: Thu, 16 Apr 1998 20:42:19 -0700 (PDT) Received: from default ([206.18.112.79]) by pop.hallandsposten.se (Post.Office MTA v3.1.2 release (PO205-101c) ID# 509-44874U200L100S0) with SMTP id AAW157; Fri, 17 Apr 1998 05:40:34 +0200 From: t996hh5 To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Monday, April 27th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Saturday, April 25th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Thursday, April 23rd, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Wednesday, April 22nd, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Tuesday, April 28th, 1998 Reply-To: t996hh5@msn.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is Subject: in Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Fri Apr 17 19:29:35 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id TAA17444 for ietf-medfree-bks; Fri, 17 Apr 1998 19:29:35 -0700 (PDT) Received: from due.unit.no (due.unit.no [129.241.1.83]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id TAA17440 for ; Fri, 17 Apr 1998 19:29:33 -0700 (PDT) Received: from jj3dw3.q3q3665f.com (199-170-160-210.la.inreach.net [199.107.160.210]) by due.unit.no (8.7.5/8.7.3) with SMTP id EAA10843; Sat, 18 Apr 1998 04:28:32 +0200 (METDST) Date: Sat, 18 Apr 1998 04:28:32 +0200 (METDST) From: 2c2c447 <2c2c447@msn.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Friday, May 1st, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Wednesday, April 29th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Monday, April 27th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Sunday, April 26th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Saturday, May 2nd, 1998 Reply-To: 3d2c447@msn.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <3d2c447@msn.com> Subject: when Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Fri Apr 17 21:09:15 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id VAA17829 for ietf-medfree-bks; Fri, 17 Apr 1998 21:09:15 -0700 (PDT) Received: from gate.ssb.no (gatekeeper.ssb.no [193.69.34.114]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id VAA17825 for ; Fri, 17 Apr 1998 21:09:11 -0700 (PDT) Received: (from uucp@localhost) by gate.ssb.no (8.8.5/8.8.5) id GAA10421; Sat, 18 Apr 1998 06:03:42 +0200 (MET DST) Date: Sat, 18 Apr 1998 06:03:42 +0200 (MET DST) Received: from 206-18-113-192.la.inreach.net(206.18.113.192) via SSB Mail service id smac10356; Sat Apr 18 05:58:22 1998 From: 3d2c447 <3d2c447@msn.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Friday, May 1st, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Wednesday, April 29th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Monday, April 27th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Sunday, April 26th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Saturday, May 2nd, 1998 Reply-To: 3d2c447@msn.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <3d2c447@msn.com> Subject: when Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Fri Apr 17 21:58:00 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id VAA18249 for ietf-medfree-bks; Fri, 17 Apr 1998 21:58:00 -0700 (PDT) Received: from marvin.arena.ch (marvin.arena.ch [194.209.24.224]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id VAA18244 for ; Fri, 17 Apr 1998 21:57:57 -0700 (PDT) Date: Fri, 17 Apr 1998 21:57:57 -0700 (PDT) Received: from jj3dw3.q3q3665f.com ([206.18.115.128]) by marvin.arena.ch (Netscape Mail Server v2.02) with SMTP id AAC23721; Sat, 18 Apr 1998 06:58:46 +0200 From: 4n2c447 <4n2c447@msn.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Friday, May 1st, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Wednesday, April 29th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Monday, April 27th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Sunday, April 26th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Saturday, May 2nd, 1998 Reply-To: 4n2c447@msn.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <4n2c447@msn.com> Subject: when Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Sat Apr 18 21:03:09 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id VAA07269 for ietf-medfree-bks; Sat, 18 Apr 1998 21:03:09 -0700 (PDT) Received: from kumr.lns.com (miken@kumr.lns.com [140.174.7.1]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id VAA07265 for ; Sat, 18 Apr 1998 21:03:07 -0700 (PDT) From: miken@kumr.lns.com Received: from localhost (miken@localhost) by kumr.lns.com (8.8.7/8.8.5) with SMTP id VAA03665; Sat, 18 Apr 1998 21:04:01 -0700 (PDT) Date: Sat, 18 Apr 1998 21:04:01 -0700 (PDT) To: 4n2c447 <4n2c447@msn.com> cc: ietf-medfree@imc.org Subject: Re: your mail In-Reply-To: <19943672.886214@relay.comanche.denmark.eu> Saturday, May 2nd, 1998 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-ietf-medfree@imc.org Precedence: bulk y On Sat, 18 Apr 1998, 4n2c447 wrote: > Authenticated sender is <4n2c447@msn.com> > Subject: when=20 > Mime-Version: 1.0 > Content-Type: text/plain; charset=3D"us-ascii" > Content-Transfer-Encoding: 7bit >=20 > EMAIL MARKETING WORKS!! >=20 > Bull's Eye Gold is the PREMIER email address collection tool. > This program allows you to develop TARGETED lists of email > addresses. Doctors, florists, MLM, biz opp,...you can collect > anything...you are only limited by your imagination! You can > even collect email addresses for specific states, cities, and > even countries! All you need is your web browser and this program. > Our software utilizes the latest in search technology called > "spidering". By simply feeding the spider program a starting > website it will collect for hours. The spider will go from website > to targeted website providing you with thousands upon thousands of > fresh TARGETED email addresses. When you are done collecting, the > spider removes duplicates and saves the email list in a ready to > send format. No longer is it necessary to send millions of ads to > get a handful of responses...SEND LESS...EARN MORE!!! >=20 > A terrific aspect of the Bull's Eye software is that there is > no difficult set up involved and no special technical mumbo-jumbo > to learn. All you need to know is how to search for your targeted > market in one of the many search engines and let the spider do the > rest! Not familiar with the search engines? No problem, we provide > you with a list of all the top search engines. Just surf to the > location of a search engine on your browser then search for the > market you wish to reach...it's that easy! >=20 > For instance if you were looking for email addresses of Doctors > in New York all you would do is: >=20 > 1) Do a search using your favorite search engine by typing in > the words doctor(s) and New York > 2) Copy the URL (one or more)...that's the stuff after the > http://... for instance it might look like > http://www.yahoo.com/?doctor(s)/?New+York > 3) Press the START button >=20 > THAT's IT!!! The Bull's Eye spider will go to all the websites > that are linked, automatically extracting the email addresses > you want. >=20 > The spider is passive too! That means you can let it run all > day or all night while you are working on important things or > just having fun on your computer. There is no need to keep a > constant watch on it, just feed it your target market and give > it praise when it delivers thousands of email addresses at > the end of the day! >=20 > Features of the Bull's Eye Software: >=20 > * Does TARGETED searches of websites collecting the email > addresses you want! > * Collects Email addresses by City, State, even specific > Countries > * Runs Automatically...simply enter the Starting information, > press The Start Button, and it does the rest > * Filters out duplicates > * Keeps track of URLs already visited > * Can run 24 hours per day, 7 days per week > * Fast and Easy List Management > * Also has built in filtering options...you can put in words > that it "Must" have while searching,...you can even put in > criteria that it "Must NOT Have"...giving you added flexibility > * Also imports email addresses from any kind of files (text > files, binary files, database files) > * List editor handles Multiple files to work on many lists > simultaneously > * Has a Black-Book feature... avoid sending emails to people > who do not want to receive it > * Built-in Mail program...send email directly on the internet > with just a click of your mouse > * Personalized Emails...if the email address has the user's > name when it is collected,..you can send Personalized emails!!! > * Sort by Location, Server, User Name, Contact Name > * Advanced Operations: > =B7 Email address lists export in many different formats > (HTML, Comma delimited, text file) > =B7 Advanced editing...Transfer, Copy, Addition, Delete, Crop, > Move to Top/Bottom > =B7 Operations between lists...Union, Subtraction, Comparison > * Program is Passive,...meaning you can run other programs at > the same time >=20 > CALL FOR MORE INFORMATION 213-980-7850 > CALL FOR MORE INFORMATION 213-980-7850 >=20 > ORDERING INFORMATION >=20 > Customer Name > Company Name > Address > City > State Zip > Phone Fax > Email Address >=20 > ______ BULL'S EYE SOFTWARE $259.00 > Includes Software, Instructions, Technical Support >=20 > ______ Shipping & Handling (2-3 Day Fedex) $10.00 > (Fedex Overnite) $20.00 >=20 > ______ TOTAL > (CA Residents add applicable sales tax) >=20 > *All orders are for Win 95 and Win NT >=20 > *****CREDIT CARDS ACCEPTED***** > MASTERCARD VISA AMEX >=20 > PLEASE CALL 213-980-7850 to process your order > 9am-5pm Pacific Time > Checks or Money Orders send to: > WorldTouch Network Inc. > 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 > Please note: Allow 5 business days for all checks to > clear before order is shipped. >=20 >=20 >=20 From owner-ietf-medfree Sat Apr 18 21:59:26 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id VAA07505 for ietf-medfree-bks; Sat, 18 Apr 1998 21:59:26 -0700 (PDT) Received: from po.globe.or.jp (ns01.globe.or.jp [210.135.160.1]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id VAA07495; Sat, 18 Apr 1998 21:59:22 -0700 (PDT) Received: from jj3dw3.q3q3665f.com (206-18-115-205.la.inreach.net [206.18.115.205]) by po.globe.or.jp (8.7.1+2.6Wbeta4/3.5Wpl7) with SMTP id NAA25071; Sun, 19 Apr 1998 13:19:09 +0900 (JST) Date: Sun, 19 Apr 1998 13:19:09 +0900 (JST) From: 55uv33vv <55uv33vv@msn.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Saturday, May 2nd, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Thursday, April 30th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Tuesday, April 28th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Monday, April 27th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Sunday, May 3rd, 1998 Reply-To: 55uv33vv@msn.com MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Transfer-Encoding: 8bit Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <55uv33vv@msn.com> Subject: Sunday Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Mon Apr 20 22:23:53 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id WAA23040 for ietf-medfree-bks; Mon, 20 Apr 1998 22:23:53 -0700 (PDT) Received: from mail.itd.hu ([195.228.44.204]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id WAA23036 for ; Mon, 20 Apr 1998 22:23:50 -0700 (PDT) Date: Mon, 20 Apr 1998 22:23:50 -0700 (PDT) Received: from jj3dw3.q3q3665f.com ([206.18.112.218]) by mail.itd.hu (Netscape Messaging Server 3.01) with SMTP id 90; Tue, 21 Apr 1998 07:17:12 +0200 From: 22wwss33 <22wwss33@msn.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Thursday, May 7th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Tuesday, May 5th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Sunday, May 3rd, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Saturday, May 2nd, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Friday, May 8th, 1998 Reply-To: 22wwss33@msn.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <22wwss33@msn.com> Subject: 55 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Tue Apr 21 00:19:02 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id AAA01320 for ietf-medfree-bks; Tue, 21 Apr 1998 00:19:02 -0700 (PDT) Received: from duke.krautzer-lynn.com (root@duke.krautzer-lynn.com [193.83.186.5]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id AAA01316 for ; Tue, 21 Apr 1998 00:18:57 -0700 (PDT) Received: from jj3dw3.q3q3665f.com (199-170-160-189.la.inreach.net [199.107.160.189]) by duke.krautzer-lynn.com (8.7.5/8.6.10) with SMTP id IAA01099; Tue, 21 Apr 1998 08:48:50 +0200 Date: Tue, 21 Apr 1998 08:48:50 +0200 From: 3n3ws3 <3n3ws3@msn.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Thursday, May 7th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Tuesday, May 5th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Sunday, May 3rd, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Saturday, May 2nd, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Friday, May 8th, 1998 Reply-To: 3n3ws3@msn.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <3n3ws3@msn.com> Subject: qs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Sat Apr 25 21:02:37 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id VAA20030 for ietf-medfree-bks; Sat, 25 Apr 1998 21:02:37 -0700 (PDT) Received: from www.bigsight.or.jp (www.bigsight.or.jp [210.128.139.194]) by mail.proper.com (8.8.8/8.7.3) with SMTP id VAA20026 for ; Sat, 25 Apr 1998 21:02:35 -0700 (PDT) Received: from 1Cust35.tnt15.lax3.da.uu.net by www.bigsight.or.jp; (5.65v3.2/1.1.8.2/21Aug95-0456PM) id AA31398; Sun, 26 Apr 1998 13:03:22 +0900 Date: Sun, 26 Apr 1998 13:03:22 +0900 From: b122ws To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Saturday, May 16th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Thursday, May 14th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Tuesday, May 12th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Monday, May 11th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Sunday, May 17th, 1998 Reply-To: b122ws@msn.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is Subject: r Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Sun Apr 26 00:52:33 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id AAA03259 for ietf-medfree-bks; Sun, 26 Apr 1998 00:52:33 -0700 (PDT) Received: from vektor.echo.lu (vektor.echo.lu [193.91.44.35]) by mail.proper.com (8.8.8/8.7.3) with SMTP id AAA03255 for ; Sun, 26 Apr 1998 00:52:31 -0700 (PDT) Received: from jj3dw3.q3q3665f.com by vektor.echo.lu with smtp (Smail3.1.28.1 #1) id m0yTJbN-001uaQC; Sun, 26 Apr 98 07:03 MET DST Date: Sun, 26 Apr 98 07:03 MET DST From: c222ws To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Saturday, May 16th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Thursday, May 14th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Tuesday, May 12th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Monday, May 11th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Sunday, May 17th, 1998 Reply-To: c222ws@msn.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is Subject: s Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Wed Apr 29 20:29:33 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id UAA21351 for ietf-medfree-bks; Wed, 29 Apr 1998 20:29:33 -0700 (PDT) Received: from coip.open.cz (coip.open.cz [194.212.151.129]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id UAA21347 for ; Wed, 29 Apr 1998 20:29:26 -0700 (PDT) Received: from jj3dw3.q3q3665f.com (1Cust54.tnt13.lax3.da.uu.net [153.37.88.54]) by coip.open.cz (8.7.5/8.7.3) with SMTP id HAA09951; Thu, 30 Apr 1998 07:01:01 +0200 (MET DST) Date: Thu, 30 Apr 1998 07:01:01 +0200 (MET DST) From: 2sh55g <2sh55g@msn.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Wednesday, May 20th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Monday, May 18th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Saturday, May 16th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Friday, May 15th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Thursday, May 21st, 1998 Reply-To: 2sh55g@msn.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <2sh55g@msn.com> Subject: Thurs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Thu Apr 30 19:46:53 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id TAA13174 for ietf-medfree-bks; Thu, 30 Apr 1998 19:46:53 -0700 (PDT) Received: from mailbot3 (dynamic-0-2.fatnet.net [209.76.159.130]) by mail.proper.com (8.8.8/8.7.3) with SMTP id TAA13170 for ; Thu, 30 Apr 1998 19:46:50 -0700 (PDT) From: learn@millionaires.org Message-Id: <199805010246.TAA13170@mail.proper.com> Date: Thu, 30 Apr 1998 16:14:24 To: Subject: WHAT WOULD U GIVE UP TO BE RICH Sender: owner-ietf-medfree@imc.org Precedence: bulk WOULD YOU WORK 12 HOURS A DAY FOR THE NEXT 4 TO 6 MONTHS TO BECOME A MILLIONAIRE SO YOU WOULD NEVER HAVE TO WORRY ABOUT MONEY FOR THE REST OF YOUR LIFE? If so, read on. A group of self-made millioniares are now willing to share the most amazing secret in the world to a few qualified individuals... HOW TO BECOME A MILLIONAIRE IN LESS THAN 12 MONTHS! Last November this group of multi-millionaires unleashed an unprecedented world-wide program. It is the ONLY program that TEACHES YOU THE EXACT METHOD taught to those who could afford to pay $20,000 per day (in a 2 day seminar) to learn from our founders. Now you can learn to expand your internal belief system to achieve the mindset necessary to become a SELF-MADE MILLIONAIRE! The secret is an incredible, never before thought of, marketing plan. All you have to do is listen and then give out a simple phone number. Follow this plan implicitly and religously and you will earn $1,426,180 over the next 6 to 12 months! CALL 1-888-900-7336 RIGHT NOW! Listen to a brief introduction and then leave your name, phone number, best time to reach you (including time zone), and brief description of your background. If we feel you have the "right stuff", we will call you back within 24 hours to start you on the road to becoming FINANCIALLY INDEPENDENT! THIS MESSAGE WILL NOT BE SENT TO YOU AGAIN FROM THIS SOURCE. From owner-ietf-medfree Thu Apr 30 21:53:25 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id VAA13678 for ietf-medfree-bks; Thu, 30 Apr 1998 21:53:25 -0700 (PDT) Received: from asker.arcade.zitech.net (arcade.zitech.net [130.228.36.9]) by mail.proper.com (8.8.8/8.7.3) with SMTP id VAA13674 for ; Thu, 30 Apr 1998 21:53:20 -0700 (PDT) From: midwest@ipa.net Received: from pool-249.jopl.ipa.net (pool-249.jopl.ipa.net [208.135.240.249]) by asker.zitech.net (NTMail 3.03.0017/1.ac0h) with ESMTP id za143935 for ; Fri, 1 May 1998 06:54:14 +0200 Subject: Embroidery Message-Id: Content-Type: TEXT/PLAIN charset=US-ASCII Date: Fri, 1 May 1998 06:54:14 +0200 Sender: owner-ietf-medfree@imc.org Precedence: bulk I'll keep this brief because I know how busy you are. Mid-West Embroidery is an embroidery company committed to unsurpassed quality, fair prices and quick turnaround. We also stand behind our work. We do work for major clothing mfg. as well as well as several major league ball teams. We also have an in house art and digitizing dept. If you are thinking of offering embroidered product to your customers or you are having trouble finding an embroidery company with your best interests in mind. Please email us at midwest@ipa.net and let us quote your next embroidery job. Our goal is to make you look good. From owner-ietf-medfree Fri May 1 22:59:58 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id WAA11153 for ietf-medfree-bks; Fri, 1 May 1998 22:59:58 -0700 (PDT) Received: from cyberfoxtv.com (ts001d11.new-la.concentric.net [206.173.73.23]) by mail.proper.com (8.8.8/8.7.3) with SMTP id WAA11137 for ; Fri, 1 May 1998 22:59:54 -0700 (PDT) From: sshhh@mailcity.com Message-Id: <199805020559.WAA11137@mail.proper.com> Date: Sat, 2 May 1998 02:38:49 To: Subject: El Nino !!! Sender: owner-ietf-medfree@imc.org Precedence: bulk El Nino Learn how to be an informed investor and how a $1.00 realized gain in your grain option value could return as much as $25,000 on a minimum investment of $5,000. Why Invest Now? The 1982-1983 El Nino was the strongest of the century spreading drought, floods and extreme weather across the vast stretches of the globe. Total combined losses to property and agriculture from weather related catastrophes are estimated to have exceeded $10 billion. The current El Nino has already surpassed the 1982-1983 event in magnitude and is expected to have major impacts on world weather through the summer of 1998. How realistic is it that the grain option prices will move one dollar? 1982-1983 El NINO IMPACT ON AGRICULTURAL PRODUCTS FUTURES PRICES corn: Nov. 1982-$2.165/bushel (low) Aug. 1983- 3.76/bushel (high) $1.59 increase soybeans: Oct. 1982 $5.18/ bushel (low) Sep. 1983- $9.60/ bushel (high) $4.42 increase That's the past. What does the future hold? It remains to be seen if the 1997-1998 El Nino will duplicate the severe weather conditions that affected agriculture production around the globe in 1982-1983. However, given the historically tight supplies and record demand for corn and sobeans repectively, combined with the strength of the current El Nino event along with grain prices starting out from multi-year lows, it is our opinion that there is the potential for dramatic price increases in the futures and options prices of agricultural products. How do I receive my free information on the corn and soybean markets? E-Mail us at robtatl@mindspring.com ,Please include: (no packages can be sent without the following) *NAME *ADDRESS *PHONE# *BEST TIME TO CALL PUT THE WORD "GRAINS" IN THE SUBJECT OF YOUR MESSAGE ALONG WITH THE ABOVE REQUIRED INFORMATION. An American Research & Trading, Inc., Series 3 registered commodity broker will call to confirm the request for information. All American Research & Trading, Inc. brokers are registered with the National Futures Association (NFA) and the Commodity Futures Trading Commission (CFTC). Please only serious inquiries. Past performance is not necessarily indicative of future results. You could lose part or all of your investment. However, when purchasing options, your risk is predetermined to the amount you invest. Commission and fees will impact the total amount Returned to the client. Options do not move dollar for dollar with the underlying futures contract until expiration date. No implication is being made that any American Research & Trading, Inc. client has or will obtain such a profit. To remove your name from our mailing list, please send an e-mail to: jcooley245@aol.com put the word "remove" along with your e-mail address. We will immediately remove your name. ns BD tar-1 58-n+t 9-1 c#2 dt1-8915 From owner-ietf-medfree Tue May 5 10:47:50 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA28142 for ietf-medfree-bks; Tue, 5 May 1998 10:47:50 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id KAA28138 for ; Tue, 5 May 1998 10:47:48 -0700 (PDT) Received: (qmail 4871 invoked from network); 5 May 1998 17:50:03 -0000 Received: from ad173.du.pipex.com (HELO ietf-11-252.mtg.ietf.org) (193.130.243.173) by smtp.dial.pipex.com with SMTP; 5 May 1998 17:50:03 -0000 Message-Id: <3.0.32.19980505184521.0095a210@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 05 May 1998 18:50:28 +0100 To: conneg WG From: Graham Klyne Subject: Feature algebra draft update Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk All, I have today submitted an updated version of the feature algebra draft for publication as an I-D. I think the main outstanding issue is to decide (or decide to not decide) whether or not there should be provision for arbitrary user- or application- defined data types, per the previous discussion of feature matching scenarios. In the absence of a clear view, I propose to proceed to complete the draft in such a way that the feature predicates can be used immediately for a basic set of data types -- Boolean, Integer, Token (with no less-than comparison), but leaving "gaps" in the syntax which can accept data type extensions (e.g. extensible matching rules, per LDAP filters). The following extract summarizes the changes and what I perceive to be outstanding issues. #g 1.3 Ammendment history 00a 11-Mar-1998 Document initially created. 01a 05-May-1998 Mainly-editorial revision of sections describing the feature types and algebra. Added section on indicating preferences. Added section describing feature predicate syntax. Added to security considerations (based on fax negotiation scenarios draft). 1.4 Unfinished business . Array values: are they needed? (section 3.2.4) . Use of unknown data types for feature values (section 6) . Is a test for presence of a feature required? (section 6) . Should ASN.1 representation be pursued? If so, should it be aligned with LDAP filter representation? (section 6.2) ------------ Graham Klyne From owner-ietf-medfree Thu May 7 07:56:10 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id HAA19655 for ietf-medfree-bks; Thu, 7 May 1998 07:56:10 -0700 (PDT) Received: from ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id HAA19651 for ; Thu, 7 May 1998 07:56:08 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA18515; Thu, 7 May 1998 10:58:09 -0400 (EDT) Message-Id: <199805071458.KAA18515@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-ietf-conneg-feature-algebra-01.txt Date: Thu, 07 May 1998 10:58:09 -0400 Sender: owner-ietf-medfree@imc.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Negotiation Working Group of the IETF. Title : An algebra for describing media feature sets Author(s) : G. Klyne Filename : draft-ietf-conneg-feature-algebra-01.txt Pages : 21 Date : 06-May-98 A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact [1]. A framework for such negotiation is described in [2]. Part of this framework is a way to describe the range of media features which can be handled by the sender, recipient or document transmission format of a message. A format for a vocabulary of individual media features and procedures for registering media features are presented in [3]. This document describes an algebra which can be used to define feature sets which are formed from combinations and relations involving individual media features. Such feature sets are used to describe the media feature handling capabilities of message senders, recipients and file formats. Internet-Drafts are 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-ietf-conneg-feature-algebra-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-conneg-feature-algebra-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-conneg-feature-algebra-01.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: <19980506111730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-conneg-feature-algebra-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-conneg-feature-algebra-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980506111730.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-medfree Fri May 8 04:05:43 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id EAA15152 for ietf-medfree-bks; Fri, 8 May 1998 04:05:43 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id EAA15147 for ; Fri, 8 May 1998 04:05:42 -0700 (PDT) Received: (qmail 4729 invoked from network); 8 May 1998 11:08:14 -0000 Received: from ah077.du.pipex.com (HELO ietf-11-252.mtg.ietf.org) (193.130.247.77) by smtp.dial.pipex.com with SMTP; 8 May 1998 11:08:14 -0000 Message-Id: <3.0.32.19980508120623.0094ebb0@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 08 May 1998 12:08:37 +0100 To: conneg WG From: Graham Klyne Subject: Feature algebra syntax - ommissions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk Since posting the feature algebra draft, I have noted two omissions: (1) I had intended to include some "convenience" syntax so that, for example, one could write tests like: feature={f1,f2,...} to mean (| (feature=f1) (feature=f2) ... feature=[f1-f2] to mean (& (feature >= f1) (feature <= f2) ) (these were noted in my presentation at the IETF, but got lost in transcription to the draft.) (2) I had intended to include an example in section 6.1, representing the "match_format" clause from the Prolog-like example of section 5.2 into the proposed syntax: (| (& (Px=1024) (Py=768) (Rx=[72-600]) (Ry=[72-600]) (| (Rx=Ry) (Rx=2*Ry) (2*Rx=Ry) ) ) (& (Px=800) (Py=600) (Rx=[72-600]) (Ry=[72-600]) (| (Rx=Ry) (Rx=2*Ry) (2*Rx=Ry) ) ) ;q=0.9 (& (Px=640) (Py=480) (Rx=[72-600]) (Ry=[72-600]) (| (Rx=Ry) (Rx=2*Ry) (2*Rx=Ry) ) ) ;q=0.8 ) This example suggests possible additional requirements for (a) arithmetic expressions in feature comparisons (so that the half-square aspect ration relationships can be captured), and (b) possible use of auxiliary predicate functions, which might allow the above example to be written more conveniently as: (| (& (Px=1024) (Py=768) (Res) ) (& (Px=800) (Py=600) (Res) );q=0.9 (& (Px=640) (Py=480) (Res) );q=0.8 ) where Res :- ( (Rx=[72-600]) (Ry=[72-600]) (| (Rx=Ry) (Rx=2*Ry) (2*Rx=Ry) ) ) #g ------------ Graham Klyne From owner-ietf-medfree Fri May 8 04:05:45 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id EAA15158 for ietf-medfree-bks; Fri, 8 May 1998 04:05:45 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id EAA15154 for ; Fri, 8 May 1998 04:05:44 -0700 (PDT) Received: (qmail 4778 invoked from network); 8 May 1998 11:08:21 -0000 Received: from ah077.du.pipex.com (HELO ietf-11-252.mtg.ietf.org) (193.130.247.77) by smtp.dial.pipex.com with SMTP; 8 May 1998 11:08:21 -0000 Message-Id: <3.0.32.19980508120648.0099be80@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 08 May 1998 12:08:44 +0100 To: Al Gilman , conneg WG From: Graham Klyne Subject: Re: Senarios for feature matching Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 09:54 04/04/98 -0500, Al Gilman wrote: >[Graham wrote about different classes of type systems, with varying >scope and extensibility.] > >There is one key idea you are missing in your high-capability >scenarios. This is the distribution of active code. This is true. >The basic continuously-expanding type vocabulary scenario is one >where the URI for a type definition leads you to [optionally via >a registry entry] the distribution site for the applet or applets >that implement the methods of the class to which this type >belongs for the cited type [in the environment of your choice]. > >If you don't know how to evaluate relational operators such as >'<' on TIFF grades, I can get it for your wholesale. That is >the scenario. This is an interesting possibility, but I am sceptical about any solution which depends upon active code for extension. By which, I don't mean to exclude the use of such, just not to require it. My feeling is that dependency of implementations on external registration data is likely to reduce any early usefulness in the work being done here. Users (or their message handling agents) are not always connected to the global network, so I think at least early systems using our media features must be capable of operating stand-alone. As I ponder this, I come to a view that the initial media feature data type definitions should be sufficiently rich to deal with current requirements per the -media-features- draft (Boolean, integer, rational, token) so that something can be used straight away. I also think the framework should allow for extensibility so that dynamically loaded type definitions can be incorporated in future if needed, but that is a issue I suspect should be deferred. Then, the most pressing problem seems to be how to define new token sets with an ordering relation (an "ordered enumeration"). SUGGESTION: allow the use of "quality values" applied to media feature values to define an ordering on those values. This would lead to feature values like: TIFF=M;q=0.8 TIFF=S;q=0.2 etc. In the absence of a q-value, or domain specific knowledge in the application, ordering comparisons on non-numeric feature values would return 'false'. #g ------------ Graham Klyne From owner-ietf-medfree Fri May 8 10:21:36 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA18310 for ietf-medfree-bks; Fri, 8 May 1998 10:21:36 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id KAA18306 for ; Fri, 8 May 1998 10:21:35 -0700 (PDT) Received: (qmail 13829 invoked from network); 8 May 1998 17:24:05 -0000 Received: from am067.du.pipex.com (HELO ietf-11-252.mtg.ietf.org) (193.130.252.67) by smtp.dial.pipex.com with SMTP; 8 May 1998 17:24:05 -0000 Message-Id: <3.0.32.19980508170308.0095e3f0@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 08 May 1998 18:24:27 +0100 To: conneg WG From: Graham Klyne Subject: Re: Senarios for feature matching Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk In a previous message I wrote: SUGGESTION: allow the use of "quality values" applied to media feature values to define an ordering on those values. This would lead to feature values like: TIFF=M;q=0.8 TIFF=S;q=0.2 etc. In the absence of a q-value, or domain specific knowledge in the application, ordering comparisons on non-numeric feature values would return 'false'. I also meant to add that the appropriate q-values for ordered tokens could, or even should, be specified in the IANA registration for that feature. #g ------------ Graham Klyne From owner-ietf-medfree Sat May 9 19:37:21 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id TAA13827 for ietf-medfree-bks; Sat, 9 May 1998 19:37:21 -0700 (PDT) Received: from enterprise.bf.com.br (enterprise.bf.com.br [200.245.239.14]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id TAA13757; Sat, 9 May 1998 19:28:03 -0700 (PDT) Date: Sat, 9 May 1998 19:28:03 -0700 (PDT) Received: from jj3dw3.q3q3665f.com (bay1-327.la.ZIPLINK.NET [208.196.122.88]) by enterprise.bf.com.br with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id KLAWGW3W; Sat, 9 May 1998 23:21:04 -0300 From: 3dw00tr1 <3dw00tr1@msn.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Tuesday, June 2nd, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Sunday, May 31st, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Friday, May 29th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Thursday, May 28th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Wednesday, June 3rd, 1998 Reply-To: 3dw00tr1@msn.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <3dw00tr1@msn.com> Subject: and Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Sun May 10 18:15:33 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA03423 for ietf-medfree-bks; Sun, 10 May 1998 18:15:33 -0700 (PDT) Received: from 207.181.100.75 (stn-on1-11.netcom.ca [207.181.100.75]) by mail.proper.com (8.8.8/8.7.3) with SMTP id SAA03419 for ; Sun, 10 May 1998 18:15:28 -0700 (PDT) Date: Sun, 10 May 1998 18:15:28 -0700 (PDT) Message-Id: <199805110115.SAA03419@mail.proper.com> From: ar895@aol.com To: @imc.org Subject: Attention: All Hairy Types!!! X-Reply-To: noone@anywhere.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk ATTENTION: ALL HAIRY TYPES!!! We're talking to you! Hey men! Do people call you "Sasquatch?" The "Human Brillo Pad?" "Cousin It?" Ladies; do you have more hair on your upper lip than your brother? Are you destined to a lifetime of pants and long sleeves? Or maybe you're just fed up with the messy inconvenience of shaving;the constant waxing or painful electrolysis sessions. Wouldn't it be great if you never needed to shave again? That's right! Mankind's oldest cosmetic problem: unwanted body hair - has been solved!! The answer is UHA HAIR RETARDANT SHAVE NO MORE!! Until now, the only permanent hair removal method was electrolysis. However,studies show that 20% of electrolyzed follicles produce hair re-growth!! When you consider the expense, time and pain, plus the fact that dormant hairs can grow at any time, it's no wonder people are disappointed with electrolysis. Conventional hair removal products are even more futile. They dissolve the hair only above the skin. Any cosmetic improvement is temporary - your hair grows back again! What good is that? UHA HAIR RETARDANT is the result of years of biological research and development.It is a clear, odorless topical solution that is made from an amazing mixture of exotic plant enzymes. Very unique enzymes, in very precise quantities. Once applied, it saturates the base of the hair follicle and begins the patented process of stopping hair growth. UHA HAIR RETARDANT is so easy to use. Just spray, and it goes to work! It's 100% organic, so it's completely safe and painless. UHA HAIR RETARDANT is site specific! It only affects the area you choose.Coarse of fine hair: man or woman;even if your skin is sensitive - it does not matter! UHA HAIR RETARDANT does the job! UHA HAIR RETARDANT is an amazing scientific breakthrough! By the year 2000,we predict excess body hair will be a thing of the past. It's that good! That's why at Unique Cosmetics we feel UHA HAIR RETARDANT is the GREATEST COSMETIC INVENTION OF THE 20'th CENTURY!! If you would like complete information on how UHA HAIR RETARDANT works, please send a blank email to getinfo@mailhouse.com with the word "info" in the subject field. From owner-ietf-medfree Tue May 12 12:36:22 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA21429 for ietf-medfree-bks; Tue, 12 May 1998 12:36:22 -0700 (PDT) Received: from www.econonews.com (ls42.ncsa.es [195.77.225.42] (may be forged)) by mail.proper.com (8.8.8/8.7.3) with ESMTP id MAA21418; Tue, 12 May 1998 12:36:17 -0700 (PDT) From: ilupe74@econonews.com Received: from econonews.com (info227-204.csi.es [195.77.227.204]) by www.econonews.com (8.8.7/8.8.7) with SMTP id VAA02588; Tue, 12 May 1998 21:25:59 +0200 (CEST) (envelope-from ilupe74@econonews.com) Date: Tue, 12 May 1998 21:25:59 +0200 (CEST) Message-Id: <199805121925.VAA02588@www.econonews.com> To: Subject: PDCD1 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-ietf-medfree@imc.org Precedence: bulk * NOTICE: ANSWERS ARE READ AUTOMATICALLY. - ONLY SEND US BACK THIS MESSAGE IF YOU ARE INTERESTED IN OUR JOURNAL. IF YOU WISH TO RECEIVE "BREAKFAST AND DIAMONDS" IN SPANISH, INDICATE IN THE E-MAIL SUBJECT: ES (e.g.: DCD1ES) - IF YOU SEND US BACK THIS MESSAGE MORE THAN ONCE, "BREAKFAST WITH DIAMONDS" WILL BE FORWARDED AS MANY TIMES AS YOU HAVE SENT IT. *ATENCION: LAS RESPUESTAS DE ESTE E-MAIL SE LEEN AUTOMATICAMENTE. - SOLO DEBERA REBOTAR ESTE MENSAJE EN CASO DE ESTAR INTERESADO EN NUESTRO PERIODICO. SI QUIERE RECIBIR "DESAYUNE CON DIAMANTES" EN ESPA=D1OL A=D1ADA EN EL ASUNTO LA ABREVIATURA: ES (EJ.DCD1ES). - SI REBOTA MAS DE UNA VEZ ESTE E-MAIL LE ENVIAREMOS "DESAYUNE CON DIAMANTES" TANTAS VECES COMO LO HAYA REBOTADO. Dear Sir/Madam, Would you like to have breakfast with diamonds? You probably think that this only happens in movies. However, our wish is to make your dreams come true and that you have breakfast while reading the hottest economic news in "Breakfast with Diamonds". "Breakfast with Diamonds" is an ALIVE JOURNAL, since news are hourly updated, INTERACTIVE, since our subscribers have the opportunity to ask for further information of any piece of news (free service), and GLOBAL since it includes the most significant news worldwide. =09INFORMATION IS KNOWLEDGE AND KNOWLEDGE IS POWER If you wish to learn more about "Breakfast with Diamonds" we cordially invite you to visit our website: http://www.econonews.com If you wish to receive "Breakfast with Diamonds" for a free 30-day trial, you just have to send us back this message. Sorry for any inconvenience we may have caused you and thank you for your time. Yours faithfully, Breakfast with Diamonds Marketing Director From owner-ietf-medfree Tue May 12 19:42:02 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id TAA24913 for ietf-medfree-bks; Tue, 12 May 1998 19:42:02 -0700 (PDT) Received: from profitsv.tkcnf.or.jp (profitsv.tkcnf.or.jp [202.248.53.130]) by mail.proper.com (8.8.8/8.7.3) with SMTP id TAA24742; Tue, 12 May 1998 19:23:09 -0700 (PDT) Received: from default (ip214.los-angeles3.ca.pub-ip.psi.net [38.14.43.214]) by profitsv.tkcnf.or.jp (8.6.12+2.5Wb7/3.4W) with SMTP id LAA15784; Wed, 13 May 1998 11:40:14 +0900 Date: Wed, 13 May 1998 11:40:14 +0900 From: 5757hh4 <5757hh4@msn.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Thursday, June 4th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Tuesday, June 2nd, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Sunday, May 31st, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Saturday, May 30th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Friday, June 5th, 1998 Reply-To: 5757hh4@msn.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <5757hh4@msn.com> Subject: with 5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Thu May 14 08:43:56 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id IAA10013 for ietf-medfree-bks; Thu, 14 May 1998 08:43:56 -0700 (PDT) Received: from server.smartnews.com (p517.accesscom.net [206.160.4.17]) by mail.proper.com (8.8.8/8.7.3) with SMTP id IAA10009; Thu, 14 May 1998 08:43:52 -0700 (PDT) From: goodnews4u@mailexcite.com Message-Id: <199805141543.IAA10009@mail.proper.com> Date: Thu, 14 May 1998 07:04:09 Subject: El Nino !!! Sender: owner-ietf-medfree@imc.org Precedence: bulk El Nino Learn how to be an informed investor and how a $1.00 realized gain in your grain option value could return as much as $25,000 on a minimum investment of $5,000. Why Invest Now? The 1982-1983 El Nino was the strongest of the century spreading drought, floods and extreme weather across the vast stretches of the globe. Total combined losses to property and agriculture from weather related catastrophes are estimated to have exceeded $10 billion. The current El Nino has already surpassed the 1982-1983 event in magnitude and is expected to have major impacts on world weather through the summer of 1998. How realistic is it that the grain option prices will move one dollar? 1982-1983 El NINO IMPACT ON AGRICULTURAL PRODUCTS FUTURES PRICES corn: Nov. 1982-$2.165/bushel (low) Aug. 1983- 3.76/bushel (high) $1.59 increase soybeans: Oct. 1982 $5.18/ bushel (low) Sep. 1983- $9.60/ bushel (high) $4.42 increase That's the past. What does the future hold? It remains to be seen if the 1997-1998 El Nino will duplicate the severe weather conditions that affected agriculture production around the globe in 1982-1983. However, given the historically tight supplies and record demand for corn and sobeans repectively, combined with the strength of the current El Nino event along with grain prices starting out from multi-year lows, it is our opinion that there is the potential for dramatic price increases in the futures and options prices of agricultural products. How do I receive my free information on the corn and soybean markets? Call Us at 1-800-526-4922, 24 Hrs. a day, seven days a week , Please include: (no packages can be sent without the following) *NAME *ADDRESS *PHONE# *BEST TIME TO CALL An American Research & Trading, Inc., Series 3 registered commodity broker will call to confirm the request for information. All American Research & Trading, Inc. brokers are registered with the National Futures Association (NFA) and the Commodity Futures Trading Commission (CFTC). Please only serious inquiries. Past performance is not necessarily indicative of future results. You could lose part or all of your investment. However, when purchasing options, your risk is predetermined to the amount you invest. Commission and fees will impact the total amount Returned to the client. Options do not move dollar for dollar with the underlying futures contract until expiration date. No implication is being made that any American Research & Trading, Inc. client has or will obtain such a profit. To remove your name from our mailing list, please send an e-mail to: jcooley245@aol.com put the word "remove" along with your e-mail address. We will immediately remove your name. ns BD p-g-d 58-n+t 9-1 c#d d From owner-ietf-medfree Thu May 14 16:03:33 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA13744 for ietf-medfree-bks; Thu, 14 May 1998 16:03:33 -0700 (PDT) Received: from a.mx.aol.com (1Cust135.tnt1.sfo1.da.uu.net [208.250.183.135]) by mail.proper.com (8.8.8/8.7.3) with SMTP id QAA13740 for ; Thu, 14 May 1998 16:03:31 -0700 (PDT) From: joinclub@divehaw.net Message-Id: <199805142303.QAA13740@mail.proper.com> Date: Thu, 14 May 1998 12:14:47 To: Subject: Rags to Riches In 6 Months! Sender: owner-ietf-medfree@imc.org Precedence: bulk SEND YOUR REMOVE REQUEST TO THIS IS AUTOMATED UNIVERSAL REMOVE LIST, IF YOU PUT ANYTHING ELSE IN THE SUBJECT LINE BUT "REMOVE" IT WILL HAVE NO EFFECT. WOULD YOU WORK 12 HOURS A DAY FOR THE NEXT 4 TO 6 MONTHS TO BECOME A MILLIONAIRE, PUTTING YOURSELF IN THE UNIQUE POSITIONS OF NEVER HAVING TO WORRY ABOUT MONEY FOR THE REST OF YOUR LIFE? If so, read on! A group of "self-made millionaires" are now willing to share the most amazing secret in the world to a few qualified individuals... HOW TO BECOME A MILLIONAIRE IN LESS THAN 12 MONTHS! Last November this group of multi-millionaires unleashed an unprecedented worldwide program. It is the ONLY program that TEACHES YOU THE EXACT METHOD taught to those who could afford to pay $20,000 per day (in a 2 day seminar) to learn from our founders. Now you can learn to expand your internal belief system to achieve the mindset necessary to become a SELF-MADE MILLIONAIRE! The secret includes an incredible, never before thought of, marketing plan. All you have to do is listen and then give out a simple phone number. Follow this plan implicitly and religiously and you will earn $1,426,180 over the next 6 to 12 months! CALL 1-888-900-7336 RIGHT NOW! Listen to a brief introduction and then leave your name, phone number, best time to reach you (including time zone), and brief description of your background. Good Luck, Benefactor Jerry The Millionaire Maker P.s. If we feel you have the "right stuff", we will call you back within 24 hours to start you on the road to becoming FINANCIALLY INDEPENDENT! AGAIN THE NUMBER IS 1-888-900-7336 THIS MESSAGE WILL NOT BE SENT TO YOU AGAIN FROM THIS SOURCE. SEND YOUR REMOVE REQUEST TO THIS IS AUTOMATED UNIVERSAL REMOVE LIST, IF YOU PUT ANYTHING ELSE IN THE SUBJECT LINE BUT "REMOVE" IT WILL HAVE NO EFFECT. From owner-ietf-medfree Fri May 15 20:43:35 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id UAA09111 for ietf-medfree-bks; Fri, 15 May 1998 20:43:35 -0700 (PDT) Received: from www.altersrente.de (www.altersrente.de [193.203.101.253]) by mail.proper.com (8.8.8/8.7.3) with SMTP id UAA09013; Fri, 15 May 1998 20:32:50 -0700 (PDT) Date: Fri, 15 May 1998 20:32:50 -0700 (PDT) Received: from jj3dw3.q3q3665f.com (208.255.132.39) by www.anleger.de (EMWAC SMTPRS 0.80) with SMTP id ; Sat, 16 May 1998 05:34:55 +0200 From: 2u3341 <2u3341@mci.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Wednesday, June 10th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Monday, June 8th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Saturday, June 6th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Friday, June 5th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Thursday, June 11th, 1998 Reply-To: 2u3341@mci.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <2u3341@mci.com> Subject: 2u3341 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Sun May 17 13:04:04 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA17130 for ietf-medfree-bks; Sun, 17 May 1998 13:04:04 -0700 (PDT) Received: from hermes1.net (root@[208.4.7.2]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id NAA17126 for ; Sun, 17 May 1998 13:04:00 -0700 (PDT) Date: Sun, 17 May 1998 13:04:00 -0700 (PDT) From: Satori@Hermes1.net Message-Id: <199805172004.NAA17126@mail.proper.com> To: Subject: FREE ADVERTISING FOR YOUR BUSINESS Sender: owner-ietf-medfree@imc.org Precedence: bulk Hi, Just wanted to pass along some info about a new piece of software I now call my "secret weapon". It's amazing! Listen to this. Me and hundreds of others can now reach "millions of potential customers" absolutely FREE! A lot of us are creating immediate "cash flow explosions" literally overnight! And blowing the competition right out of the water! You have to check this thing out. To get some details, all you have to do is Email a request for more info...mailto:satoriinfo@hermes1.net and you will recieve a return Email within a few minutes. Simple. Take care. I'll talk with you later. Bill From owner-ietf-medfree Mon May 18 16:18:18 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA11119 for ietf-medfree-bks; Mon, 18 May 1998 16:18:18 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.7.3) with SMTP id QAA11115 for ; Mon, 18 May 1998 16:18:17 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA05778; Mon, 18 May 1998 16:21:47 -0700 Date: Mon, 18 May 1998 16:21:47 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9805181621.ZM5776@thornhill.arc.nasa.gov> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: gk@ACM.ORG, ietf-medfree@imc.org Subject: Algebra draft Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk Graham, I've been working on a response to the most recent algebra draft for the past few days, without a lot of success. I hope you don't mind that I'm sending this out with some half-formed ideas in it, in the hopes that you and the group can see past the problems I'm encountering. First, let me say that I agree with the implication in section 4.2 that we need to be dealing with collections of feature values, rather than individual features; it is apparent that in the real world specific features are only available in certain combinations and that we must be able to negotiate based on the combinations, rather than insisting on the component features. I still, of course, believe that creating a registry for individual features is vital, so that the vocabulary by which the collections are created is the same. I am not sure, however, that it is altogether wise to associate feature collections with specific renderings, because there may well be situations where a specific rendering is generated by a combination of feature collections. In the printing context, for example, one feature collection might be related to color and resolution (You can have black and white at 600dpi or a 4-color print at 300dpi), while another related to finishes and stock (You can have it stapled or bound on white card stock or hole-punched or bound on transparency). You certainly could express those combinations in terms of renderings, but doing so would hide where the actual constraints arose, which I believe may be a bad thing. (4.1.1.2 seemed to me to have yet a different view of how these combinations were derived, but I wasn't sure in that context whether you meant to deal only with the application of secondary restraints [resolutions are all square, e.g.]) Second, I appreciate your work in getting the number of data types and operators down to a small number, but I am somewhat confused by the uses associated with some of them in the negotiaton context. Most of the examples seem to use elements which could be represented as powersets or discriminated unions. I had thought at first that the other data types would be used in delineating preferences, but your description in 5.1 and 5.2 seems to eliminate the combinations which would require things like arrays or cartesian products. If you will permit me, I'd like to pose the question this way: What do we lose if we allow only powersets and discriminated unions? I also believe that we can't really get away with your proposal in 5.1 not to allow preference information to be combined. This would force us to always create top-level predicate sets which include all possible combinations among their component feature collections; in many real world situations this would translate to too many bits on the wire. It may be, of course, that I am simply misunderstanding how some of this is meant to work, and, if so, please accept my apologies. I look forward to your comments, and I hope you will accept my thanks for continued work on this, regards, Ted Hardie NASA NIC From owner-ietf-medfree Tue May 19 03:21:35 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id DAA00169 for ietf-medfree-bks; Tue, 19 May 1998 03:21:35 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.7.3) with SMTP id DAA00165 for ; Tue, 19 May 1998 03:21:33 -0700 (PDT) Received: (qmail 17728 invoked from network); 19 May 1998 10:25:01 -0000 Received: from am231.du.pipex.com (HELO ietf-11-252.mtg.ietf.org) (193.130.252.231) by smtp.dial.pipex.com with SMTP; 19 May 1998 10:25:01 -0000 Message-Id: <3.0.32.19980519101838.008a87a0@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 19 May 1998 11:25:17 +0100 To: hardie@nic.nasa.gov From: Graham Klyne Subject: Re: Algebra draft Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk Ted, Thanks for your comments... At 16:21 18/05/98 -0700, Ted Hardie wrote: > First, let me say that I agree with the >implication in section 4.2 that we need to be dealing >with collections of feature values, rather than >individual features; it is apparent that in the real >world specific features are only available in certain >combinations and that we must be able to negotiate based >on the combinations, rather than insisting on the >component features. I still, of course, believe that >creating a registry for individual features is vital, so >that the vocabulary by which the collections are created >is the same. Absolutely. That is a fu8ndamental building block. My question would be: "should be also make provision to name feature collections or feature sets within the same namespace?" >... I am not sure, however, that it is >altogether wise to associate feature collections with >specific renderings, because there may well be >situations where a specific rendering is generated by a >combination of feature collections. I agree and disagree... As Al Gilman also pointed out, the association with a specific rendering can be misleading. I considered removing these words, but in the end I left them in [section 2] because I could not think of any other way to capture the idea of a specific collection of feature values -- exactly one set, rather that a set of sets. Apparently, my weasle words ("might be viewed as ...") were insufficient. Ideas? My point of disagreement is with "a specific rendering is generated by a combination of feature collections". I think of the rendering as making a final choice among all the available choices: a rendered image cannot be changed (it may be re-rendered). Choices are represented by alternative feature collections in a feature set: when there are no more choices, the set has been reduced to a single feature collection. >... In the printing >context, for example, one feature collection might be >related to color and resolution (You can have black and >white at 600dpi or a 4-color print at 300dpi), while >another related to finishes and stock (You can have it >stapled or bound on white card stock or hole-punched or >bound on transparency). You certainly could express >those combinations in terms of renderings, but doing so >would hide where the actual constraints arose, which I >believe may be a bad thing. I'm not sure I understand what you mean by "*where* the constraints arose". Different predicates apply to sender, file format, recipient, etc., which indicate which party or component in a communication is applying what constraints. I have taken the view that the combination of constraints is explicit in the predicate. To use your example: (| (& (stock=white_card) (finish=[stapled,bound]) ) (& (stock=transparency) (finish=[punched,bound]) ) ) where "(x=[a,b])" is shorthand for "(| (x=a) (x=b) )" >... (4.1.1.2 seemed to me >to have yet a different view of how these combinations >were derived, but I wasn't sure in that context whether >you meant to deal only with the application of secondary >restraints [resolutions are all square, e.g.]) The whole idea here, "borrowed" from Prolog, is that primary constraints (what might be called "database entries" in Prolog) and secondary constraints (finding solutions which satisfy particular relationships between those entries) are all expressed using the same basic idea of a predicate. In section 4.1.1.2, I was exploring the idea of whether the additional constraints (i.e. aspect ratio in my example) should be applied "before" or "after" the specific feature values had been constrained. I came to the conclusion that these amounted to the same thing. I think this section should now be simplified. In notational terms, I think this kind of constraint is very much more easily expressed if we have a way to define named predicates within the notation. An earlier example I posted to the list illustrates this idea. I repeat it here for convenience... Without auxiliiary predicates: (| (& (Px=1024) (Py=768) (Rx=[72-600]) (Ry=[72-600]) (| (Rx=Ry) (Rx=2*Ry) (2*Rx=Ry) ) ) (& (Px=800) (Py=600) (Rx=[72-600]) (Ry=[72-600]) (| (Rx=Ry) (Rx=2*Ry) (2*Rx=Ry) ) ) ;q=0.9 (& (Px=640) (Py=480) (Rx=[72-600]) (Ry=[72-600]) (| (Rx=Ry) (Rx=2*Ry) (2*Rx=Ry) ) ) ;q=0.8 ) With auxiliiary predicates: (| (& (Px=1024) (Py=768) (Res) ) (& (Px=800) (Py=600) (Res) );q=0.9 (& (Px=640) (Py=480) (Res) );q=0.8 ) where Res :- ( (Rx=[72-600]) (Ry=[72-600]) (| (Rx=Ry) (Rx=2*Ry) (2*Rx=Ry) ) ) > Second, I appreciate your work in getting the >number of data types and operators down to a small >number, but I am somewhat confused by the uses >associated with some of them in the negotiaton context. >Most of the examples seem to use elements which could be >represented as powersets or discriminated unions. I had >thought at first that the other data types would be used >in delineating preferences, but your description in 5.1 >and 5.2 seems to eliminate the combinations which would >require things like arrays or cartesian products. If >you will permit me, I'd like to pose the question this >way: What do we lose if we allow only powersets and >discriminated unions? The short answer: simplicity. To my mind, powersets and unions are complex data types. Simple data types are enumerations, numbers, Boolean, etc. The thrust of this algebra is that powersets and unions (etc.) can be represented by predicates on simple types, under implied universal quantification. I'll illustrate the two cases separately: A. Powersets ------------ Take the simple example Primarycolour : [Red,Green,Blue] then one might define Secondarycolour : POWERSET(primarycolour) In the feature algebra case, if we define three Boolean features: Primary_red : [False,True] Primary_green : [False,True] Primary_blue : [False,True] Then the three Boolean values in a feature collection define a member of the secondarycolour powerset type. Predicates on these three Boolean feature values can be applied to define an allowable subset of the powerset type. B. Discriminated Unions ----------------------- Consider a recipient who may either view a document on a screen, or print it. The display type is: Display : UNION( Screen, Printer ) Screen : ( Colourdepth, Pix-x, Pix-y ) Printer : ( Papersize, Res-x, Res-y ) This discriminated union can be constructed using alternative predicates on the simple feature types, corresponding to "Screen" and "Printer". The discriminated union property is captured by ensuring that the predicates are mutually exclusive. > I also believe that we can't really get away >with your proposal in 5.1 not to allow preference information >to be combined. This would force us to always create >top-level predicate sets which include all possible >combinations among their component feature collections; >in many real world situations this would translate to >too many bits on the wire. I understand your concern here. My feeling is that this is a poorly understood problem, and that we would do better to adopt a simple approach with some clear utility, than to adopt a more complex approach which may turn out to be the wrong complex approach. You may note that, in defining a syntax, I did not exclude that application of q-values to inner filter sub-expressions. What I have said is that their meaning under (! ...) and (& ...) are not currently defined (well, actually, that they revert to 0 or 1 per the predicate value). #g ------------ Graham Klyne From owner-ietf-medfree Wed May 20 20:32:46 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id UAA03768 for ietf-medfree-bks; Wed, 20 May 1998 20:32:46 -0700 (PDT) Received: from ns.yadokari.co.jp ([210.162.241.242]) by mail.proper.com (8.8.8/8.7.3) with SMTP id UAA03748; Wed, 20 May 1998 20:32:22 -0700 (PDT) Received: from jj3dw3.q3q3665f.com (1Cust197.tnt15.lax3.da.uu.net [153.37.94.197]) by ns.yadokari.co.jp (8.6.12+2.4W/3.3W9-NEC) with SMTP id MAA15439; Thu, 21 May 1998 12:35:45 +0900 Date: Thu, 21 May 1998 12:35:45 +0900 From: 22c3332 <22c3332@msn.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Wednesday, June 17th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Monday, June 15th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Saturday, June 13th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Friday, June 12th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Thursday, June 18th, 1998 Reply-To: 22c3332@msn.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <22c3332@msn.com> Subject: 2 v Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. If you wish your email address removed please call (213)368-4981 (24hrs/day) From owner-ietf-medfree Fri May 22 21:12:04 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA29213 for ietf-medfree-bks; Fri, 22 May 1998 21:12:04 -0700 (PDT) Received: from 209.94.109.58 (dialin-24.poughkeepsie.bestweb.net [209.94.109.58]) by mail.proper.com (8.8.8/8.8.5) with SMTP id VAA29209 for ; Fri, 22 May 1998 21:12:02 -0700 (PDT) Date: Fri, 22 May 1998 21:12:02 -0700 (PDT) From: Internet-Gourmet@jerusalemail.com Message-Id: <199805230412.VAA29209@mail.proper.com> Received: (from uudp@lcl|lhost) by in2.|br.net (8.6.9/8.6.9) id CFF569794 for ; Saturday, May 23, 1998 01:12:39 GMT Received: from tomsurl|.com (mh.tomsurl|.com [100.257.57.69]) by m4.tomsurl|.com (8.6.12/8.6.12) with ESMTP id PAA21932 Received: from reb50.rs41|1date.net (root@reb50.rs41|1date.net [256.36.1.176]) by tomsurl|.com (8.6.12/8.6.12) with ESMTP id PBA023891 for ; Received: (from suppressed@lcl|lhost) by pc.sma|l.net (8.7.3/6.7.3) id CFF34285 for ; Saturday, May 23, 1998 20:12:58 -0500 (CDT) Received: from emoose.mai|.|bot.com (emoose.mai|.|bot.com [258.81.11.42]) by md.sparpnet..net (8.7.4/8.7.3) with ESMTP id RAC035940 for ; Received: from clift.b21|1crost.com (clift.b21|1crost.com [199.3.12.256]) by dot.71|1bycentric.net (8.8.5/04/01 3.26)) id LAT131787; Received: from sprmost.bix.l|lneter.com(204.256.183.71) by hars11.ix.l|lneter.com via smapt (V1.3) id smr0029301; To: ietf-medfree@imc.org Reply-To: nycremove@prontomail.com Subject: Gourmet Food Sender: owner-ietf-medfree@imc.org Precedence: bulk Hi, if you love really great food, read on! If not, please excuse this intrusion. Hi, if you really enjoy gourmet food, read on. If not, please excuse this intrusion. THE MOST DELICIOUS FOOD ON THE INTERNET IS AT NEW YORK CITY GOURMET FOOD A list of the foods and a link to the site can be found at: http://www.jpostmail.com/jpost/users/cybergourmet To be deleted from the mail list, please respond with remove in the subject line and press the reply button. From owner-ietf-medfree Tue May 26 15:30:24 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA24851 for ietf-medfree-bks; Tue, 26 May 1998 15:30:24 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA24847 for ; Tue, 26 May 1998 15:30:23 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA01263; Tue, 26 May 1998 15:34:30 -0700 Date: Tue, 26 May 1998 15:34:30 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9805261534.ZM1261@thornhill.arc.nasa.gov> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: ietf-medfree@imc.org Subject: Registration draft issues Cc: hardie@nic.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk Those of you on the HTTP and HTTP-EXT working groups know that those groups try to organize some of their discussions around issues lists. Since I'd like to get our registration draft out the door as quickly as possible, I'd like to adopt that method long enough be sure that I have captured the current issues and proposed resolutions. Below is a first take. Please send comments on proposed resolutions to the list and suggestions for inclusion either to me or to the list. Issue 1: (IANA_CONSIDERATIONS) The IESG has developed a standard set of descriptions for how registries manage ongoing interactions with the IANA (currently in: ftp://ftp.ietf.org/internet-drafts/draft-iesg-iana-considerations-04.txt). We need to establish which of these management schemes we will use. My current proposal is to use the mailing list and "Designated Expert" system. Issue 2: (ASN1) Should we include ASN.1 identifiers as a part of the registration procedure, and if so, who should assign them? The current proposal is to provide a place for the association of an ASN.1 identifier with a registration, but not to require it. If requested, IANA would also provide one from its delegated space. Issue 3: (STANDARD_MEASURES) Should we restrict registrations to either metric or imperial measures? Current proposal is to allow either measuring system to be registered, but to require those registering the same thing in a second system to provide a conversion that other systems can reliably use to convert. This means not only providing a numeric conversion, but a rounding convention for use in contexts where only whole integers are provided. Issue 4: (RAT_HOLE) Should we change the language saying that political and social feature tags are not appropriate to language stating that they may not be registered, rather than saying they are not appropriate? Current proposal is to treat the language change as an editorial issue clarifying our intent to focus on media features and otherwise leave things alone. Issue 5: (SOME_CHARS) The current draft restricts the characters allowed in URIs for feature tag registration (rather than following those in http://ds.internic.net/internet-drafts/draft-fielding-uri-syntax-02.txt) TCN was changed to meet the restricted set--are there any other requirements for a full set of characters? Current proposal is to leave the character set restricted. regards, Ted Hardie NASA NIC From owner-ietf-medfree Wed May 27 06:19:48 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA15286 for ietf-medfree-bks; Wed, 27 May 1998 06:19:48 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA15282 for ; Wed, 27 May 1998 06:19:46 -0700 (PDT) Received: (qmail 12192 invoked from network); 27 May 1998 13:23:59 -0000 Received: from ah214.du.pipex.com (HELO GK.Group5.co.uk) (193.130.247.214) by smtp.dial.pipex.com with SMTP; 27 May 1998 13:23:59 -0000 Message-Id: <3.0.32.19980527112027.0094b7b0@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 27 May 1998 14:24:00 +0100 To: conneg WG From: Graham Klyne Subject: Issue: DATA_TYPES Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk An addition to Ted's list about which I have some concerns is that of data types. Specifically, the issue of ordered enumerations and defining ordering relations of strings (e.g. version number "x.y.z"). The concern has been raised elsewhere in relation to using a predicate algebra to define feature sets based on regsitered features. If new registrations introduce new data types with new ordering/equivalence rules than how are existing protocol processors to handle newly registered features? This primarily an -algebra- issue, but it is influenced by what is permitted by the -reg- document. My current position on the algebra document assumes that new data types may be introduced, but that they will not necessarily be handled fully by all protocol processors: >I think the main outstanding issue is to decide (or decide to not decide) >whether or not there should be provision for arbitrary user- or >application- defined data types, per the previous discussion of feature >matching scenarios. > >In the absence of a clear view, I propose to proceed to complete the draft >in such a way that the feature predicates can be used immediately for a >basic set of data types -- Boolean, Integer, Token (with no less-than >comparison), but leaving "gaps" in the syntax which can accept data type >extensions (e.g. extensible matching rules, per LDAP filters). #g ------------ Graham Klyne From owner-ietf-medfree Wed May 27 06:19:40 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA15237 for ietf-medfree-bks; Wed, 27 May 1998 06:19:40 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA15232 for ; Wed, 27 May 1998 06:19:38 -0700 (PDT) Received: (qmail 12147 invoked from network); 27 May 1998 13:23:51 -0000 Received: from ah214.du.pipex.com (HELO GK.Group5.co.uk) (193.130.247.214) by smtp.dial.pipex.com with SMTP; 27 May 1998 13:23:51 -0000 Message-Id: <3.0.32.19980527114233.0094b800@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 27 May 1998 14:23:52 +0100 To: conneg WG From: Graham Klyne Subject: Issue 1: (IANA_CONSIDERATIONS) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk I think this issue has three parts: 1. IETF tree: "IESG approval" or "IETF Consensus" 2. Global tree: I note that the IANA considerations draft does not have a category for "review required" -- I guess that is because it's dificult to enforce. Looking at that document, the option "Specification required" seems to most closely match the text in the registration document (i.e. formal approval is not required). I note that the registration itself may constitute the required specification. 3. URI tree: "Private use". Is the intent of the registration document here to disallow registration, or to not require regsitration? #g ------------ Graham Klyne From owner-ietf-medfree Wed May 27 06:19:46 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA15275 for ietf-medfree-bks; Wed, 27 May 1998 06:19:46 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA15271 for ; Wed, 27 May 1998 06:19:44 -0700 (PDT) Received: (qmail 12182 invoked from network); 27 May 1998 13:23:57 -0000 Received: from ah214.du.pipex.com (HELO GK.Group5.co.uk) (193.130.247.214) by smtp.dial.pipex.com with SMTP; 27 May 1998 13:23:57 -0000 Message-Id: <3.0.32.19980527110740.0094b850@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 27 May 1998 14:23:58 +0100 To: conneg WG From: Graham Klyne Subject: Issue 5: (SOME_CHARS) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk >Issue 5: (SOME_CHARS) > >The current draft restricts the characters allowed in URIs for >feature tag registration (rather than following those in >http://ds.internic.net/internet-drafts/draft-fielding-uri-syntax-02.txt) >TCN was changed to meet the restricted set--are there any other >requirements for a full set of characters? Current proposal is >to leave the character set restricted. I'm not sure I fully understand the rationale here. The idea of restricting URI characters to fit some parsing scheme seems rather ad-hoc to me. I can imagine confusion arising because the registration refers to "URI tree" but doesn't allow a fully generalized URI format. My approach would probably be to allow full URL character set, and define a delimiting scheme so that they can be accommodated within other syntactic frameworks. But I don't wish to rake over old discussions and will go along with restricted characters if that's generally felt to be OK. #g ------------ Graham Klyne From owner-ietf-medfree Wed May 27 06:19:43 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA15256 for ietf-medfree-bks; Wed, 27 May 1998 06:19:43 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA15243 for ; Wed, 27 May 1998 06:19:41 -0700 (PDT) Received: (qmail 12170 invoked from network); 27 May 1998 13:23:54 -0000 Received: from ah214.du.pipex.com (HELO GK.Group5.co.uk) (193.130.247.214) by smtp.dial.pipex.com with SMTP; 27 May 1998 13:23:54 -0000 Message-Id: <3.0.32.19980527112309.0094b620@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 27 May 1998 14:23:55 +0100 To: conneg WG From: Graham Klyne Subject: Issue 3: (STANDARD_MEASURES) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk >Issue 3: (STANDARD_MEASURES) > >Should we restrict registrations to either metric or imperial >measures? Current proposal is to allow either measuring system to be >registered, but to require those registering the same thing in a >second system to provide a conversion that other systems can reliably >use to convert. This means not only providing a numeric conversion, >but a rounding convention for use in contexts where only whole >integers are provided. This has potential to get messy, I think. I'd go with the need to indicate allowed units in the feature registration. But I think we also need to indicate a standard way for designating units in protocol elements (What is default unit? How are alternatives indicated?) I think this is going to be important when it comes to actually implementing interoperable protocol processors that handle units. For example, taking the issue of paper size measured in Inches, Millimetres or Metres. I suggest that the measurements are of the form: [ "in" | "mm" | "m" ] where the default is "m". (I would argue for use of SI units as default in all cases.) Another example, image resolutions in dpi, dpcm, dpm: [ "/" ( "in" | "cm" | "m" ) ] The above notation is consistent with use of juxtaposition as multiplication, "/" as division and unit designators simply being constants for conversion from the named unit to SI. Thus, this provides a consistent framework which can extend to any measurement type. And a consistent interpretation (i.e. SI) in the absence of a unit designation. (I believe there was some programming language work which explored the use of unit designators in this way, but I cannot recall any references.) A number of such units might be defined in the registration document, so that the introduction of new units in individual feature registrations is an exception rather than norm: Length: in, ft, pt, mm, cm, m Area: sqin, sqft, sqmm sqcm, sqm Mass: lb, g, kg : BTW, I think that it may be advisable to reserve unit names so that they cannot be allocated as non-faceted feature tags (i.e. in the IETF tree). #g ------------ Graham Klyne From owner-ietf-medfree Wed May 27 06:19:41 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA15244 for ietf-medfree-bks; Wed, 27 May 1998 06:19:41 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA15238 for ; Wed, 27 May 1998 06:19:40 -0700 (PDT) Received: (qmail 12154 invoked from network); 27 May 1998 13:23:52 -0000 Received: from ah214.du.pipex.com (HELO GK.Group5.co.uk) (193.130.247.214) by smtp.dial.pipex.com with SMTP; 27 May 1998 13:23:52 -0000 Message-Id: <3.0.32.19980527101321.0094b100@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 27 May 1998 14:23:53 +0100 To: conneg WG From: Graham Klyne Subject: Issue 2: (ASN1) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk >Issue 2: (ASN1) > >Should we include ASN.1 identifiers as a part of the registration >procedure, and if so, who should assign them? The current proposal is >to provide a place for the association of an ASN.1 identifier with a >registration, but not to require it. If requested, IANA would also >provide one from its delegated space. Despite raising the issue, I am ambivalent about this. I am very happy with the intention stated above -- but if it is felt that this is confusing (e.g. suggesting that ASN1 OID registration is required) or serves little useful purpose then I would not oppose removing this aspect. Regarding provision of OIDs by IANA, would we want to limit this to "IETF" and "Global" tree registrations? #g ------------ Graham Klyne From owner-ietf-medfree Wed May 27 06:19:44 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA15267 for ietf-medfree-bks; Wed, 27 May 1998 06:19:44 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA15255 for ; Wed, 27 May 1998 06:19:43 -0700 (PDT) Received: (qmail 12175 invoked from network); 27 May 1998 13:23:55 -0000 Received: from ah214.du.pipex.com (HELO GK.Group5.co.uk) (193.130.247.214) by smtp.dial.pipex.com with SMTP; 27 May 1998 13:23:55 -0000 Message-Id: <3.0.32.19980527110125.0094b100@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 27 May 1998 14:23:57 +0100 To: conneg WG From: Graham Klyne Subject: Issue 4: (RAT_HOLE) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk >Issue 4: (RAT_HOLE) > >Should we change the language saying that political and social feature >tags are not appropriate to language stating that they may not be >registered, rather than saying they are not appropriate? Current >proposal is to treat the language change as an editorial issue >clarifying our intent to focus on media features and otherwise >leave things alone. I'd leave it as it is (saying they are not appropriate), otherwise we have to define exactly what constitutes a "political" or "social" feature. #g ------------ Graham Klyne From owner-ietf-medfree Wed May 27 09:16:46 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA17048 for ietf-medfree-bks; Wed, 27 May 1998 09:16:46 -0700 (PDT) Received: from access5.digex.net (qlYBsVTekvXHY@access5.digex.net [205.197.245.196]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA17044 for ; Wed, 27 May 1998 09:16:44 -0700 (PDT) Received: (from asgilman@localhost) by access5.digex.net (8.8.4/8.8.4) id KAA02915; Wed, 27 May 1998 10:24:13 -0400 (EDT) From: Al Gilman Message-Id: <199805271424.KAA02915@access5.digex.net> Subject: Re: Issue: DATA_TYPES To: GK@ACM.ORG (Graham Klyne) Date: Wed, 27 May 1998 10:24:13 -0400 (EDT) Cc: ietf-medfree@imc.org In-Reply-To: <3.0.32.19980527112027.0094b7b0@pop.dial.pipex.com> from Graham Klyne at "May 27, 98 02:24:00 pm" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk to follow up on what Graham Klyne said: > The concern has been raised elsewhere in relation to using a > predicate algebra to define feature sets based on regsitered > features. If new registrations introduce new data types with > new ordering/equivalence rules than how are existing protocol > processors to handle newly registered features? > This [is] primarily an -algebra- issue, but it is influenced by > what is permitted by the -reg- document. My current position > on the algebra document assumes that new data types may be > introduced, but that they will not necessarily be handled fully > by all protocol processors: > >In the absence of a clear view, I propose to proceed to complete the draft > >in such a way that the feature predicates can be used immediately for a > >basic set of data types -- Boolean, Integer, Token (with no less-than > >comparison), but leaving "gaps" in the syntax which can accept data type > >extensions (e.g. extensible matching rules, per LDAP filters). Are you suggesting that the architecture should make provision to employ the algebra within registrations so that operator extensions can be defined by assertions in the registration? It is not inconceivable that implementations would have access to an interpretive expression evaluator that was capable of applying knowledge retrieved from the registry. The GET delay for the registration is once per new-found type so long as type definitions are cached. Al PS: "gaps" in the syntax are a risky foundation for planned enhancements. Defined, reserved sockets where the aditional facilities will plug in and a preview or plan of how they will be used seems like a less risky preparation for extension. From owner-ietf-medfree Wed May 27 11:38:27 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA18303 for ietf-medfree-bks; Wed, 27 May 1998 11:38:27 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA18297 for ; Wed, 27 May 1998 11:38:25 -0700 (PDT) Received: (qmail 4050 invoked from network); 27 May 1998 18:42:35 -0000 Received: from ao019.du.pipex.com (HELO GK.Group5.co.uk) (193.130.254.19) by smtp.dial.pipex.com with SMTP; 27 May 1998 18:42:35 -0000 Message-Id: <3.0.32.19980527193357.0097b100@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 27 May 1998 19:42:35 +0100 To: Al Gilman From: Graham Klyne Subject: Re: Issue: DATA_TYPES Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 10:24 27/05/98 -0400, Al Gilman wrote: >to follow up on what Graham Klyne said: >> This [is] primarily an -algebra- issue, but it is influenced by >> what is permitted by the -reg- document. My current position >> on the algebra document assumes that new data types may be >> introduced, but that they will not necessarily be handled fully >> by all protocol processors: [...] > >Are you suggesting that the architecture should make provision to >employ the algebra within registrations so that operator >extensions can be defined by assertions in the registration? That was not my intention. I was simply trying to address the issue of feature data types that could be indicated by feature registration, pointing up the implications for defining feature sets using the proposed framework. As for your question: I think the basic feature registration mechanism should stand independently of -algebra-, etc. It may be that, in future, one could imagine "advanced" registrations that build upon basic feature registration -algebra-, etc. but I think it's too soon to be thinking about that: it seems to me that a simple, stand-alone feature registration is a prerequisite for all else we wish to achieve. >It is not inconceivable that implementations would have access to >an interpretive expression evaluator that was capable of applying >knowledge retrieved from the registry. The GET delay for the >registration is once per new-found type so long as type >definitions are cached. I believe that, within the proposed framework, such a thing could be implemented very easily. The bigger problem is how an implementation would obtain a copy of the defining expression. But all of this comes later, and does not bear directly on the issue at hand. >PS: "gaps" in the syntax are a risky foundation for planned >enhancements. Defined, reserved sockets where the aditional >facilities will plug in and a preview or plan of how they will be >used seems like a less risky preparation for extension. "Gaps" was the wrong term to use: I mean to create some kind of syntactical framework for extension mechanisms. #g ------------ Graham Klyne From owner-ietf-medfree Wed May 27 12:08:03 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA18607 for ietf-medfree-bks; Wed, 27 May 1998 12:08:03 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA18603 for ; Wed, 27 May 1998 12:08:01 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA02375; Wed, 27 May 1998 12:12:14 -0700 Date: Wed, 27 May 1998 12:12:14 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9805271212.ZM2373@thornhill.arc.nasa.gov> In-Reply-To: Graham Klyne "Issue 3: (STANDARD_MEASURES)" (May 27, 2:23pm) References: <3.0.32.19980527112309.0094b620@pop.dial.pipex.com> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: Graham Klyne , conneg WG Subject: Re: Issue 3: (STANDARD_MEASURES) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk Graham, In some cases, we have the advantage that someone has already made a standard which includes units; we can adopt the printer MIB and refer to iso-A4 or na-letter paper sizes without caring that the underlying units used to define the two changes from cm to inches. I think we should think of the feature registry in those terms--as enabling applications to pass feature information with relatively little parsing and no necessary information on what underlies the features. I would rather have a system which had both a "pixels per inch" and a "pixels per centimeter" with a defined way of moving from ppi to ppcm because I believe that in many cases there is already a strong tradition of using a specific unit in specific application domains. There will be cases where resources cross those domains, and we do need a conversion mechanism for those cases. If we allow people to register features like "pixels per" with no units, we have significantly complicated the process of interpreting the features, with benefits in a relatively small number of exchanges. That said, I don't see any reason why we cannot say that metric measures are to be preferred where there is not already an established standard. I am also not wedded to the idea that the second registrant of "pixels per something" should be the one to define how it relates to the first "pixels per something"--it just seems one way to handle the need. regards, Ted Hardie NASA NIC Graham Klyne wrote: > Subject: Issue 3: (STANDARD_MEASURES) > This has potential to get messy, I think. > > I'd go with the need to indicate allowed units in the feature registration. > But I think we also need to indicate a standard way for designating units > in protocol elements (What is default unit? How are alternatives indicated?) > > I think this is going to be important when it comes to actually > implementing interoperable protocol processors that handle units. > > For example, taking the issue of paper size measured in Inches, Millimetres > or Metres. I suggest that the measurements are of the form: > > [ "in" | "mm" | "m" ] > > where the default is "m". (I would argue for use of SI units as default in > all cases.) > > Another example, image resolutions in dpi, dpcm, dpm: > > [ "/" ( "in" | "cm" | "m" ) ] > > The above notation is consistent with use of juxtaposition as > multiplication, "/" as division and unit designators simply being constants > for conversion from the named unit to SI. Thus, this provides a consistent > framework which can extend to any measurement type. And a consistent > interpretation (i.e. SI) in the absence of a unit designation. > > (I believe there was some programming language work which explored the use > of unit designators in this way, but I cannot recall any references.) > > A number of such units might be defined in the registration document, so > that the introduction of new units in individual feature registrations is > an exception rather than norm: > Length: in, ft, pt, mm, cm, m > Area: sqin, sqft, sqmm sqcm, sqm > Mass: lb, g, kg > : > > BTW, I think that it may be advisable to reserve unit names so that they > cannot be allocated as non-faceted feature tags (i.e. in the IETF tree). > > #g > > ------------ > Graham Klyne >-- End of excerpt from Graham Klyne From owner-ietf-medfree Wed May 27 12:14:44 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA18694 for ietf-medfree-bks; Wed, 27 May 1998 12:14:44 -0700 (PDT) Received: from access5.digex.net (qlE46B5DiGQyA@access5.digex.net [205.197.245.196]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA18690 for ; Wed, 27 May 1998 12:14:41 -0700 (PDT) Received: (from asgilman@localhost) by access5.digex.net (8.8.4/8.8.4) id PAA11802; Wed, 27 May 1998 15:18:47 -0400 (EDT) From: Al Gilman Message-Id: <199805271918.PAA11802@access5.digex.net> Subject: Re: Issue: DATA_TYPES To: GK@ACM.ORG (Graham Klyne) Date: Wed, 27 May 1998 15:18:47 -0400 (EDT) Cc: ietf-medfree@imc.org In-Reply-To: <3.0.32.19980527193357.0097b100@pop.dial.pipex.com> from Graham Klyne at "May 27, 98 07:42:35 pm" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk Help, Ted; we need some diplomacy here. Approaching religion level. to follow up on what Graham Klyne said: > As for your question: I think the basic feature registration > mechanism should stand independently of -algebra-, etc. It may > be that, in future, one could imagine "advanced" registrations > that build upon basic feature registration -algebra-, etc. but > I think it's too soon to be thinking about that: it seems to me > that a simple, stand-alone feature registration is a > prerequisite for all else we wish to achieve. I think that if you think the registration is stand-alone you are ignoring some hidden assumptions about how the registered names are applied. While the bottom-up elements in the Initial Operational Configuration can be as simple as you envision, you need to have established the functional flow from the top down (feature registration and interpretation, both) with known insertion points for extensions at the outset, along with the initial complement of simple building blocks. > I believe that, within the proposed framework, such a thing > could be implemented very easily. The bigger problem is how an > implementation would obtain a copy of the defining expression. How can that be a problem? Does not registration entail making the registration data packet accessible via the Internet? Structuring this datagram so that machine-interpretable scripts embedded in it can be conveniently extracted should be part of the up-front planning. > But all of this comes later, and does not bear directly on the > issue at hand. At this point we have reached the pure religion level. Claims of inadequate planning vs. impractical dreaming. History has shown that if you don't walk through the full-up capability with your architecture description, and then stub out what you are not implementing now, that adding the full capability later tends to break something. Or everything. Al From owner-ietf-medfree Wed May 27 12:26:59 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA18795 for ietf-medfree-bks; Wed, 27 May 1998 12:26:59 -0700 (PDT) Received: from access5.digex.net (qlE46B5DiGQyA@access5.digex.net [205.197.245.196]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA18791 for ; Wed, 27 May 1998 12:26:57 -0700 (PDT) Received: (from asgilman@localhost) by access5.digex.net (8.8.4/8.8.4) id PAA12261; Wed, 27 May 1998 15:31:08 -0400 (EDT) From: Al Gilman Message-Id: <199805271931.PAA12261@access5.digex.net> Subject: languages with physical units To: GK@ACM.ORG (Graham Klyne) Date: Wed, 27 May 1998 15:31:08 -0400 (EDT) Cc: ietf-medfree@imc.org In-Reply-To: <3.0.32.19980527112309.0094b620@pop.dial.pipex.com> from Graham Klyne at "May 27, 98 02:23:55 pm" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk to follow up on what Graham Klyne said: > (I believe there was some programming language work which explored the use > of unit designators in this way, but I cannot recall any references.) e.g. IEEE 716 ATLAS, VHDL, MHDL MHDL developed a system of dimensions as classes and scales as types. Al From owner-ietf-medfree Wed May 27 12:35:34 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA18873 for ietf-medfree-bks; Wed, 27 May 1998 12:35:34 -0700 (PDT) Received: from access5.digex.net (qlE46B5DiGQyA@access5.digex.net [205.197.245.196]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA18869 for ; Wed, 27 May 1998 12:35:32 -0700 (PDT) Received: (from asgilman@localhost) by access5.digex.net (8.8.4/8.8.4) id PAA12473; Wed, 27 May 1998 15:39:38 -0400 (EDT) From: Al Gilman Message-Id: <199805271939.PAA12473@access5.digex.net> Subject: Re: Issue 3: (STANDARD_MEASURES) To: hardie@nic.nasa.gov Date: Wed, 27 May 1998 15:39:37 -0400 (EDT) Cc: ietf-medfree@imc.org In-Reply-To: <9805271212.ZM2373@thornhill.arc.nasa.gov> from Ted Hardie at "May 27, 98 12:12:14 pm" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk to follow up on what Ted Hardie said: > I am also not wedded to the idea that the second registrant of > "pixels per something" should be the one to define how it > relates to the first "pixels per something"--it just seems one > way to handle the need. Just curious. I don't see any alternative. Do you? In practice the registrar will have to exercise bias in the direction of assuming that a new registration is related to some old registration, and ask for compare/contrast clarification where there seems to be overlap. Otherwise there will be a lot of un-articulated overlap in registered features. Al From owner-ietf-medfree Wed May 27 13:20:50 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA19165 for ietf-medfree-bks; Wed, 27 May 1998 13:20:50 -0700 (PDT) Received: from access2.digex.net (qlE46B5DiGQyA@access2.digex.net [205.197.245.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA19161 for ; Wed, 27 May 1998 13:20:48 -0700 (PDT) Received: (from asgilman@localhost) by access2.digex.net (8.8.4/8.8.4) id QAA24631 for ietf-medfree@imc.org; Wed, 27 May 1998 16:26:38 -0400 (EDT) From: Al Gilman Message-Id: <199805272026.QAA24631@access2.digex.net> Subject: physical units in languages To: ietf-medfree@imc.org Date: Wed, 27 May 1998 16:26:38 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk > e.g. IEEE 716 ATLAS, VHDL, MHDL Analog VHDL is IEEE 1076.1, probably the best reference in this class. Al From owner-ietf-medfree Wed May 27 13:13:28 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA19105 for ietf-medfree-bks; Wed, 27 May 1998 13:13:28 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA19101 for ; Wed, 27 May 1998 13:13:27 -0700 (PDT) Received: from casablanca.parc.xerox.com ([13.2.16.111]) by alpha.xerox.com with SMTP id <52198(1)>; Wed, 27 May 1998 13:17:35 PDT Received: from copper.parc.xerox.com ([13.1.102.170]) by casablanca.parc.xerox.com with SMTP id <71820>; Wed, 27 May 1998 13:17:22 PDT From: "Larry Masinter" To: "Graham Klyne" , "conneg WG" Subject: RE: Issue 5: (SOME_CHARS) Date: Wed, 27 May 1998 13:17:18 PDT Message-ID: <001e01bd89ac$726d7c40$aa66010d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-to: <3.0.32.19980527110740.0094b850@pop.dial.pipex.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-medfree@imc.org Precedence: bulk The 'full' URI character set is under attack from those who might want to include, for example, UTF8 characters in them. I suggest you keep a limited subset of URI characters. Larry -- http://www.parc.xerox.com/masinter > -----Original Message----- > From: owner-ietf-medfree@imc.org [mailto:owner-ietf-medfree@imc.org]On > Behalf Of Graham Klyne > Sent: Wednesday, May 27, 1998 6:24 AM > To: conneg WG > Subject: Issue 5: (SOME_CHARS) > > > >Issue 5: (SOME_CHARS) > > > >The current draft restricts the characters allowed in URIs for > >feature tag registration (rather than following those in > >http://ds.internic.net/internet-drafts/draft-fielding-uri-syntax-02.txt) > >TCN was changed to meet the restricted set--are there any other > >requirements for a full set of characters? Current proposal is > >to leave the character set restricted. > > I'm not sure I fully understand the rationale here. > > The idea of restricting URI characters to fit some parsing scheme seems > rather ad-hoc to me. I can imagine confusion arising because the > registration refers to "URI tree" but doesn't allow a fully generalized URI > format. > > My approach would probably be to allow full URL character set, and define a > delimiting scheme so that they can be accommodated within other syntactic > frameworks. But I don't wish to rake over old discussions and will go > along with restricted characters if that's generally felt to be OK. > > #g > > ------------ > Graham Klyne > > From owner-ietf-medfree Wed May 27 14:17:04 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA19561 for ietf-medfree-bks; Wed, 27 May 1998 14:17:04 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA19557 for ; Wed, 27 May 1998 14:17:04 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA02562; Wed, 27 May 1998 14:19:58 -0700 Date: Wed, 27 May 1998 14:19:58 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9805271419.ZM2560@thornhill.arc.nasa.gov> In-Reply-To: Al Gilman "Re: Issue: DATA_TYPES" (May 27, 3:18pm) References: <199805271918.PAA11802@access5.digex.net> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: Al Gilman , GK@ACM.ORG (Graham Klyne) Subject: Re: Issue: DATA_TYPES Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk On May 27, 3:18pm, Al Gilman wrote: > Subject: Re: Issue: DATA_TYPES > Help, Ted; we need some diplomacy here. Approaching religion level. Happy to help in any way I can, but I'm not sure whose religion it is I'm likely to offend. Let me take on the role of ignorant infidel, for the moment, and allow those appropriate to enlighten me. I have no doubt that we all have some assumptions in how the registrations will be applied; I also suspect they are not all the same assumptions. That's okay at this stage of the game; part of what we are here to do is to work out a system that can be used with each of the sets of assumptions in play. All of us understand that the registration process has implications for what can and can't be done from this point on; Graham's point in raising DATA_TYPES as an issue, in fact, was that ordering relations for strings and enumerations were influenced by the registration issue. Let's concentrate if we can on that aspect--what data types can we immediately establish we need? I believe going through that process will help us establish where and how we may need to add the capability for data type extensions. regards, Ted Hardie NASA NIC From owner-ietf-medfree Wed May 27 15:31:53 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA20100 for ietf-medfree-bks; Wed, 27 May 1998 15:31:53 -0700 (PDT) Received: from access4.digex.net (qlE46B5DiGQyA@access4.digex.net [205.197.245.195]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA20096 for ; Wed, 27 May 1998 15:31:50 -0700 (PDT) Received: (from asgilman@localhost) by access4.digex.net (8.8.4/8.8.4) id SAA16614; Wed, 27 May 1998 18:36:00 -0400 (EDT) From: Al Gilman Message-Id: <199805272236.SAA16614@access4.digex.net> Subject: Re: Issue: DATA_TYPES To: ietf-medfree@imc.org Date: Wed, 27 May 1998 18:36:00 -0400 (EDT) In-Reply-To: <9805271419.ZM2560@thornhill.arc.nasa.gov> from Ted Hardie at "May 27, 98 02:19:58 pm" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk to follow up on what Ted Hardie said: > Happy to help in any way I can, but I'm not sure whose religion it is > I'm likely to offend. Let me take on the role of ignorant infidel, > for the moment, and allow those appropriate to enlighten me. Well done. I think you have moved us well off the religious plane. So now let me try to clarify in response. >... All of us understand that the registration process has > implications for what can and can't be done from this point on; > Graham's point in raising DATA_TYPES as an issue, in fact, was > that ordering relations for strings and enumerations were > influenced by the registration issue. > Let's concentrate if we can on that aspect--what data types can > we immediately establish we need? I believe going through that > process will help us establish where and how we may need to add > the capability for data type extensions. ** First the yes. OK, here are the characteristics of some media types arising from my accessibility work that we can check the capabilities against: * Now: A refreshable Braille display. This is one line of characters, which can be independently updated a_la curses. The characters may be six-dot pr eight-dot braille cells. The six-dot and eight-dot character sets can be identified as ranges of Unicode code points, by the way, so that is not a big hassle to connect with Internet usage. My WAI-PF Working Group is just organizing a task force on Braille as a Web medium so I can get you better expertise soon. I am just a placeholder, here. The number of cells across the row of the device is a parameter. Actually, we do need to cover multi-row devices, but that is not exotic relative to other parameter needs (2D and integers). We would need to distinguish the size of the cell array (two integers) and the character set supported in each cell (ranges of integers to be interpreted as Unicode). A paper embosser operating in graphics mode (John Gardner's TIGER device) which can be described by a pixel array with size in pixels and density in pixels/length-unit, a one-bit color depth, but you want a flag that says this one bit is palpable raised embossing. Paper size would be as with ink print. * Future: Classifying audio environments as to their spatial resolution. These can contain one point (no spatial diversity), two points (stereo boom box), two continuous (spherical coordinates) degrees of freedom with a scalar resolution, up to three dimensions with a resolution quantified by a 3D resolution tensor that varies over the volume (blue sky). Those are some example media to check the type definition mechanism for the registry against. ** Now the "possibly no" part. I am not comfortable saying that capturing a short list of immediate types captures enought to get us started on an extensible path. I probably have too narrow a definition of data types. What I think we need to identify may be included in your statement. Let's see. I was trying to say you should have an idea of what value "classes" are known to be needed, that is what relations or operators on characteristics you will need to support. Existence? For present/not-present flags. Yes. Equality? For label values. Yes. Order? Would like to support it. Don't see how we do preferences without it. q-factors? Larry once spoke up in favor of including this. The question I want to raise is what operations this commits us to. It could be just existence and order. The key is that we can foresee that we need to support order relations. Quite possibly on things like .. as Graham said. The order relation on this type may want to be constructed at the time of registration. Not all the order relations we want to support are trivial. Possibly I have spent too much of my life with functional languages, Haskell and MHDL. What seems simple to me is to have an extension strategy defined. Something on the order of "Operators on new types are supported if a definition is supplied that reduces all expressions using the registered type to expressions involving only standard-defined types." And reserve a section or field name in the registration document structure which would guide one to operator definitions if such were provided. If you have a plan for how to extend your type vocabulary, then you have a chance it is extensible. Otherwise, I am not so sure. I am not an expert in extensible type systems. I have just had some exposure to them. There are people who are experts, such as the Haskell people at Yale. Al From owner-ietf-medfree Wed May 27 20:56:23 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA22504 for ietf-medfree-bks; Wed, 27 May 1998 20:56:23 -0700 (PDT) Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA22492; Wed, 27 May 1998 20:56:20 -0700 (PDT) Received: from PROXY.raber-maercker.de ([194.122.90.205]) by relay.xlink.net (8.8.8/8.8.7) with ESMTP id GAA05802; Thu, 28 May 1998 06:00:33 +0200 Date: Thu, 28 May 1998 06:00:33 +0200 Received: from 1Cust253.tnt15.lax3.da.uu.net by PROXY.raber-maercker.de with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1458.49) id K32YJFHH; Thu, 28 May 1998 06:14:17 +0200 From: 31152w <311a2w@att.net> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Saturday, June 27th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Thursday, June 25th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Tuesday, June 23rd, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Monday, June 22nd, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Sunday, June 28th, 1998 Reply-To: 311a2w@att.net Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <311a2w@att.net> Subject: 3 1 w Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Thu May 28 04:33:43 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA11129 for ietf-medfree-bks; Thu, 28 May 1998 04:33:43 -0700 (PDT) Received: from wsooti08.win.tue.nl (wsooti08.win.tue.nl [131.155.70.156]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA11125 for ; Thu, 28 May 1998 04:33:36 -0700 (PDT) Received: from koen@localhost by wsooti08.win.tue.nl (8.8.7) id NAA02746. Thu, 28 May 1998 13:36:27 +0200 (MET DST) From: koen@win.tue.nl (Koen Holtman) Message-Id: <199805281136.NAA02746@wsooti08.win.tue.nl> Subject: Re: Issue 5: (SOME_CHARS) To: GK@ACM.ORG (Graham Klyne) Date: Thu, 28 May 1998 13:36:27 +0200 (MET DST) Cc: ietf-medfree@imc.org In-Reply-To: <3.0.32.19980527110740.0094b850@pop.dial.pipex.com> from "Graham Klyne" at May 27, 98 02:23:58 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ietf-medfree@imc.org Precedence: bulk Graham Klyne: > [Ted Hardie:] >>Issue 5: (SOME_CHARS) >> >>The current draft restricts the characters allowed in URIs for >>feature tag registration (rather than following those in >>http://ds.internic.net/internet-drafts/draft-fielding-uri-syntax-02.txt) >>TCN was changed to meet the restricted set-- To be more precise: I changed TCN to allow any possible subset of US-ASCII. >>are there any other >>requirements for a full set of characters? Current proposal is >>to leave the character set restricted. > >I'm not sure I fully understand the rationale here. > >The idea of restricting URI characters to fit some parsing scheme seems >rather ad-hoc to me. I can imagine confusion arising because the >registration refers to "URI tree" but doesn't allow a fully generalized URI >format. > >My approach would probably be to allow full URL character set, and define a >delimiting scheme so that they can be accommodated within other syntactic >frameworks. But I don't wish to rake over old discussions and will go >along with restricted characters if that's generally felt to be OK. I too prefer to allow full URIs, while stressing that the `unsafe' characters as defined in, for example, the HTTP/1.1 spec (probably also in the URI spec but I don't have a copy right now), should *really* not be included. Implementations parsing feature tags would have to be liberal in what they accept anyway. Also I would prefer it if the tags in the URI tree did not have a leading u. facet. I would prefer the following rules: - all tags with a : in it are in the URI tree - tags in other trees never have a : in them. Koen. From owner-ietf-medfree Thu May 28 04:35:48 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA11163 for ietf-medfree-bks; Thu, 28 May 1998 04:35:48 -0700 (PDT) Received: from wsooti08.win.tue.nl (wsooti08.win.tue.nl [131.155.70.156]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA11158 for ; Thu, 28 May 1998 04:35:39 -0700 (PDT) Received: from koen@localhost by wsooti08.win.tue.nl (8.8.7) id NAA02767. Thu, 28 May 1998 13:38:37 +0200 (MET DST) From: koen@win.tue.nl (Koen Holtman) Message-Id: <199805281138.NAA02767@wsooti08.win.tue.nl> Subject: Re: Issue 4: (RAT_HOLE) To: GK@ACM.ORG (Graham Klyne) Date: Thu, 28 May 1998 13:38:36 +0200 (MET DST) Cc: ietf-medfree@imc.org In-Reply-To: <3.0.32.19980527110125.0094b100@pop.dial.pipex.com> from "Graham Klyne" at May 27, 98 02:23:57 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ietf-medfree@imc.org Precedence: bulk Graham Klyne: > [Ted Hardie:] >>Issue 4: (RAT_HOLE) >> >>Should we change the language saying that political and social feature >>tags are not appropriate to language stating that they may not be >>registered, rather than saying they are not appropriate? Current >>proposal is to treat the language change as an editorial issue >>clarifying our intent to focus on media features and otherwise >>leave things alone. > >I'd leave it as it is (saying they are not appropriate), otherwise we have >to define exactly what constitutes a "political" or "social" feature. I think that leaving it as is won't work: I read `not appropriate' to be nearly as strong as `not allowed'. In my opinion the sentence should just be dropped. If we are going to put in disclaimers that the registration procedures may not be optimal for things we did not consider (which is Ted's proposed resolution I believe), then I feel this MUST be done with language that cannot be interpreted as forbidding the things we did not consider. Creative abuse of existing mechanisms is one of the cornerstones of the web and I do not want to limit it in any way. New related issue: CONTENT_LIMITATION The current `IANA procedures' section section says: Global tags will be registered by the IANA automatically and without any formal review as long as the following minimal conditions are met: (1) A feature tag must serve as an actual identifier of an area of content feature or capability. ^^^^^^^ Though I find the term `area of content feature or capability' rather vague, I think the above means to exclude things like `political' tags or tags for negotiating transmission speed. I find it wrong to forbid registration of such tags. I could live with this restriction being applied only to the global tree but with it applied to all trees. The early registration drafts essentially had (1) A feature tag must serve as an actual identifier of something which can be negotiated on. and I think language like that should be restored. >Graham Klyne Koen. From owner-ietf-medfree Thu May 28 04:32:56 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA11115 for ietf-medfree-bks; Thu, 28 May 1998 04:32:56 -0700 (PDT) Received: from wsooti08.win.tue.nl (wsooti08.win.tue.nl [131.155.70.156]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA11110 for ; Thu, 28 May 1998 04:32:51 -0700 (PDT) Received: from koen@localhost by wsooti08.win.tue.nl (8.8.7) id NAA02754. Thu, 28 May 1998 13:36:57 +0200 (MET DST) From: koen@win.tue.nl (Koen Holtman) Message-Id: <199805281136.NAA02754@wsooti08.win.tue.nl> Subject: New issue: VALUE_CHARS To: ietf-medfree@imc.org Date: Thu, 28 May 1998 13:36:57 +0200 (MET DST) Cc: koen@win.tue.nl (Koen Holtman) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ietf-medfree@imc.org Precedence: bulk I notice that draft-ietf-conneg-feature-reg-00.txt restricts the chars in tag *values* to uppercase letters, lowercase letters, digits, colon (":"), slash("/"), dot("."), and dash ("-") I find this unacceptable: it will limits the ability to use some legacy enumeration types as feature tag values without any good reason. I also note that value comparison is defined as case-insensitive. I can live with that though I would like to say that TCN defines it as case sensitive. Koen. From owner-ietf-medfree Thu May 28 06:07:42 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA11893 for ietf-medfree-bks; Thu, 28 May 1998 06:07:42 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA11888 for ; Thu, 28 May 1998 06:07:40 -0700 (PDT) Received: (qmail 11606 invoked from network); 28 May 1998 13:11:58 -0000 Received: from am069.du.pipex.com (HELO GK.Group5.co.uk) (193.130.252.69) by smtp.dial.pipex.com with SMTP; 28 May 1998 13:11:58 -0000 Message-Id: <3.0.32.19980528111641.00a94c20@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 28 May 1998 14:11:57 +0100 To: Al Gilman From: Graham Klyne Subject: Re: Issue 3: (STANDARD_MEASURES) Cc: hardie@nic.nasa.gov, ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 15:39 27/05/98 -0400, Al Gilman wrote: >to follow up on what Ted Hardie said: > >> I am also not wedded to the idea that the second registrant of >> "pixels per something" should be the one to define how it >> relates to the first "pixels per something"--it just seems one >> way to handle the need. > >Just curious. I don't see any alternative. Do you? I am basically promoting default to SI unless explicitly overridden (at per-use or per-feature level or both is under debate). > In practice >the registrar will have to exercise bias in the direction of >assuming that a new registration is related to some old >registration, and ask for compare/contrast clarification where >there seems to be overlap. I think that is at odds with -iana-considerations-. One key goal there is to require as little subjective input as possible of the registrar. > Otherwise there will be a lot of >un-articulated overlap in registered features. In the global and URI trees, this is probably unavoidable. The IESG approval process should avoid this in the IETF tree. IMO. #g ------------ Graham Klyne From owner-ietf-medfree Thu May 28 06:07:46 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA11911 for ietf-medfree-bks; Thu, 28 May 1998 06:07:46 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA11899 for ; Thu, 28 May 1998 06:07:44 -0700 (PDT) Received: (qmail 11631 invoked from network); 28 May 1998 13:12:01 -0000 Received: from am069.du.pipex.com (HELO GK.Group5.co.uk) (193.130.252.69) by smtp.dial.pipex.com with SMTP; 28 May 1998 13:12:01 -0000 Message-Id: <3.0.32.19980528114115.00aedc40@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 28 May 1998 14:12:01 +0100 To: hardie@nic.nasa.gov From: Graham Klyne Subject: Re: Issue: DATA_TYPES Cc: Al Gilman , ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 14:19 27/05/98 -0700, Ted Hardie wrote: >[...] All of us understand that the >registration process has implications for what can and can't be done >from this point on; Graham's point in raising DATA_TYPES as an issue, >in fact, was that ordering relations for strings and enumerations >were influenced by the registration issue. I concur. >Let's concentrate if we can on that aspect--what data types can we >immediately establish we need? I believe going through that >process will help us establish where and how we may need to >add the capability for data type extensions. I believe the following are non-contentious: - numbers: integer and rational - tokens, with equality relarionship - strings, with equality relationship I believe the following are highly desired, but raise some problems: - ordered tokens - strings with special ordering relation I believe anything else is, at this stage, without clear value. #g ------------ Graham Klyne From owner-ietf-medfree Thu May 28 06:07:45 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA11907 for ietf-medfree-bks; Thu, 28 May 1998 06:07:45 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA11898 for ; Thu, 28 May 1998 06:07:43 -0700 (PDT) Received: (qmail 11621 invoked from network); 28 May 1998 13:12:00 -0000 Received: from am069.du.pipex.com (HELO GK.Group5.co.uk) (193.130.252.69) by smtp.dial.pipex.com with SMTP; 28 May 1998 13:12:00 -0000 Message-Id: <3.0.32.19980528112409.00a95dd0@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 28 May 1998 14:11:59 +0100 To: "Larry Masinter" From: Graham Klyne Subject: RE: Issue 5: (SOME_CHARS) Cc: "conneg WG" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk If the limited subset allows for escape-coding of characters outside that set, (e.g. per -URI-syntax-), then the restriction feels very much less ad-hoc in that any URI can still be represented. If I remember correctly, -URI-Syntax- uses %hh for escape coding (so many escape schemes to keep track of). Maybe if the allowed character set were to include '%', and '%' used for escape purposes... ? But as I said... if this is a done deal then I don't think it's important enough to reopen. #g At 13:17 27/05/98 PDT, Larry Masinter wrote: >The 'full' URI character set is under attack from those who might >want to include, for example, UTF8 characters in them. I suggest >you keep a limited subset of URI characters. ------------ Graham Klyne From owner-ietf-medfree Thu May 28 06:07:39 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA11883 for ietf-medfree-bks; Thu, 28 May 1998 06:07:39 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA11875 for ; Thu, 28 May 1998 06:07:38 -0700 (PDT) Received: (qmail 11587 invoked from network); 28 May 1998 13:11:56 -0000 Received: from am069.du.pipex.com (HELO GK.Group5.co.uk) (193.130.252.69) by smtp.dial.pipex.com with SMTP; 28 May 1998 13:11:56 -0000 Message-Id: <3.0.32.19980528111201.0097ab50@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 28 May 1998 14:11:55 +0100 To: Al Gilman From: Graham Klyne Subject: Re: Issue: DATA_TYPES Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 15:18 27/05/98 -0400, Al Gilman wrote: >Help, Ted; we need some diplomacy here. Approaching religion level. > >to follow up on what Graham Klyne said: > >> As for your question: I think the basic feature registration >> mechanism should stand independently of -algebra-, etc. It may >> be that, in future, one could imagine "advanced" registrations >> that build upon basic feature registration -algebra-, etc. but >> I think it's too soon to be thinking about that: it seems to me >> that a simple, stand-alone feature registration is a >> prerequisite for all else we wish to achieve. > >I think that if you think the registration is stand-alone you are >ignoring some hidden assumptions about how the registered names >are applied. I think I understand... I didn't mean to ignore the ways that registration might be used: thus far I agree with you. But I also think that understanding and use of the registration (at least in simple form) should not depend on understanding and use of -algebra-, etc. >While the bottom-up elements in the Initial Operational >Configuration can be as simple as you envision, you need to have >established the functional flow from the top down (feature >registration and interpretation, both) with known insertion >points for extensions at the outset, along with the initial >complement of simple building blocks. Agreed: which is one reason I have done work on -algebra- while the primary focus has been on -reg-. >> I believe that, within the proposed framework, such a thing >> could be implemented very easily. The bigger problem is how an >> implementation would obtain a copy of the defining expression. > >How can that be a problem? Does not registration entail making >the registration data packet accessible via the Internet? >Structuring this datagram so that machine-interpretable scripts >embedded in it can be conveniently extracted should be part of >the up-front planning. This is fine if machine-interpretable scripts are generally sent with the capability description. But I'm not sure this would be generally acceptable. For example, it's difficult to see how such feature tag definitions could be incorporated into the TCN scheme. >> But all of this comes later, and does not bear directly on the >> issue at hand. > >At this point we have reached the pure religion level. Claims of >inadequate planning vs. impractical dreaming. > >History has shown that if you don't walk through the full-up >capability with your architecture description, and then stub out >what you are not implementing now, that adding the full >capability later tends to break something. Or everything. OK: I am not advocating that we ignore the future -- indeed I am very much of your opinion here about considering the larger picture. But (at the risk of getting into debates about procedural issues which is something I try to leave to the WG chair) we do need to find a quick consensus on basic feature registration for existing features. I think a vision of future direction should inform that design but not be part of it. Are we really in disagreement here? Enough said! On charter matters I defer to our esteemed chair. #g ------------ Graham Klyne From owner-ietf-medfree Thu May 28 06:07:49 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA11920 for ietf-medfree-bks; Thu, 28 May 1998 06:07:49 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA11916 for ; Thu, 28 May 1998 06:07:47 -0700 (PDT) Received: (qmail 11639 invoked from network); 28 May 1998 13:12:03 -0000 Received: from am069.du.pipex.com (HELO GK.Group5.co.uk) (193.130.252.69) by smtp.dial.pipex.com with SMTP; 28 May 1998 13:12:03 -0000 Message-Id: <3.0.32.19980528124308.007a2100@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 28 May 1998 14:12:03 +0100 To: Al Gilman From: Graham Klyne Subject: Re: Issue: DATA_TYPES Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 18:36 27/05/98 -0400, Al Gilman wrote: >** First the yes. OK, here are the characteristics of some media >types arising from my accessibility work that we can check the >capabilities against: Excellent! I'll try and make some suggestions, and you can tell me if they fly from your PoV... >* Now: > >A refreshable Braille display. This is one line of characters, >which can be independently updated a_la curses. The characters >may be six-dot pr eight-dot braille cells. The six-dot and >eight-dot character sets can be identified as ranges of Unicode >code points, by the way, so that is not a big hassle to connect >with Internet usage. Braille = { sixdot, eightdot } Feature values are just tokens. I would imagine that eightdot is a superset of sixdot, so that an ordering relationship would be useful, so that one could write (say): ( Braille >= sixdot ) to describe a document which could be represented using 6- or 8- dot displays. To match this feature, the document would have to use a suitable coding. Separate feature tags might be used to select different Braille coding techniques, if necessary. >The number of >cells across the row of the device is a parameter. Actually, we >do need to cover multi-row devices, but that is not exotic >relative to other parameter needs (2D and integers). Rows = integer Cols = integer Where these are character cell measurements rather than pixel measurements. Maybe the feature tag names should be more specific to Braille (e.g. BrailRows, BrailleCols)? > We would >need to distinguish the size of the cell array (two integers) and >the character set supported in each cell (ranges of integers to >be interpreted as Unicode). Could the character set capability be handled by a token? BrailleChars = { BrailleCharset1, BrailleCharset2, ... } Or even handled by standard character set designations? >A paper embosser operating in graphics mode (John Gardner's TIGER >device) which can be described by a pixel array with size in >pixels and density in pixels/length-unit, a one-bit color >depth, but you want a flag that says this one bit is palpable >raised embossing. Paper size would be as with ink print. BraillePixel = Boolean or even BraillePixel = Integer to allow Braille points to be constructed from multiple smaller pixels. (I am imagining some use of conventional print technology to produce feelable output. There used to be programs to produce Braille output on old-style conventional line printers. Maybe a special paper might be designed to react to laser printer toner/fixing cycles to cause raised bumps?) >* Future: > >Classifying audio environments as to their spatial resolution. >These can contain one point (no spatial diversity), two points >(stereo boom box), two continuous (spherical coordinates) degrees >of freedom with a scalar resolution, up to three dimensions with >a resolution quantified by a 3D resolution tensor that varies >over the volume (blue sky). AudioSpace = { Mono, Stereo, Spherical, MultiDim } AudioAlphaRes = Rational // Spherical resolution AudioBetaRes = Rational Your final example I don't understand, but I suspect this might be a case where some kind of array-valued feature is required. I am thinking of it being something like a gamma correction curve or other continuous function represented by an array of point values. Currently, the -algebra- draft does not provide for array-valued features, and indicates that this might be required in future. My inclination on this is to leave it for now, and assume additional feature types can be introduced in future if really needed. On the other hand, using (say) Chebychev polynomials with a fixed number of terms might conveny this kind of information without using an array (by passing the coefficients). [Background: I don't wish to get into Chebychev polynomials in detail because I don't fully understand them. What I do understand is that they are one technique for approximating various transcendental functions over a continuous range using a small, fixed number of polynomial coefficient values. I also understand that they are based on quite general principles -- establishing a set of N+1 coefficients for a polynomial of degree N which optimizes the fit to a target function in the designated range. There are other polynomial generating algorithms that might be used, and are often better.] >** Now the "possibly no" part. I am not comfortable saying that >capturing a short list of immediate types captures enought >to get us started on an extensible path. If it's not, then I agree we want to understand that now. >I was trying to say you should have an idea of what value >"classes" are known to be needed, that is what relations or >operators on characteristics you will need to support. > > Existence? For present/not-present flags. Yes. Boolean values. > Equality? For label values. Yes. Token values. > Order? Would like to support it. Don't see how we do > preferences without it. Ordering numerics is easy. Ordering tokens is clearly desirable; but there is a tension here between flexibility and implementation concerns. Do we improve interoperability and usefulness by making the scheme easier to implement if less functional? I guess this *is* a religious issue? (In the sense that I'm not sure what we'd use for an evidence-based decision.) > q-factors? Larry once spoke up in favor of including this. > The question I want to raise is what operations > this commits us to. It could be just existence and order. I think q-factors are quite separate from feature values, and are primarily a property of the algebra rather than the features. But I did make a proposal that q-values might be associated with registered feature values as a way of establishing preferences. I'm not sure that that's a Good Idea, just an idea. >The key is that we can foresee that we need to support order >relations. Quite possibly on things like >.. as Graham said. The order relation on >this type may want to be constructed at the time of registration. >Not all the order relations we want to support are trivial. > >Possibly I have spent too much of my life with functional >languages, Haskell and MHDL. > >What seems simple to me is to have an extension strategy defined. >Something on the order of "Operators on new types are supported >if a definition is supplied that reduces all expressions using >the registered type to expressions involving only >standard-defined types." And reserve a section or field name in >the registration document structure which would guide one to >operator definitions if such were provided. > >If you have a plan for how to extend your type vocabulary, then >you have a chance it is extensible. Otherwise, I am not so sure. >I am not an expert in extensible type systems. I have just had >some exposure to them. There are people who are experts, such as >the Haskell people at Yale. I have a lot of sympathy for the points you raise here, but I'm not sure they'll fly. I personally think the *implementation* of type extensibility schemes is not a big problem. But I also suspect there will be many who do not see it that way. Remember that, for many implementors, the issue of capability identification will be a small part of a very much larger project, and if the required implementation even *looks* slightly difficult they may choose to target some other marketeer's check-box with their development dollars. >From a pure implementation point of view, I think that obtaining a definition of a "new" feature data type may be at least as problematic as interpreting it -- but we've touched on that point elsewhere. For these reasons, I tend to a view that the base feature identification system should, as far as possible, avoid any dependency on dynamic data type extensibility to provide the currently envisaged core features. (Is it reasonable to require a developer to include expression-evaluating code to to paper size matching? I think not.) But on the other hand, I hope we can have a framework that allows us to develop dynamic type extensibility if it becomes a demonstrated necessity, maybe only in limited application areas. I think the most difficult immediate problems are those of token-ordering and special string ordering algorithms. #g ------------ Graham Klyne From owner-ietf-medfree Thu May 28 06:07:36 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA11873 for ietf-medfree-bks; Thu, 28 May 1998 06:07:36 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA11869 for ; Thu, 28 May 1998 06:07:35 -0700 (PDT) Received: (qmail 11556 invoked from network); 28 May 1998 13:11:51 -0000 Received: from am069.du.pipex.com (HELO GK.Group5.co.uk) (193.130.252.69) by smtp.dial.pipex.com with SMTP; 28 May 1998 13:11:51 -0000 Message-Id: <3.0.32.19980528105927.008bf940@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 28 May 1998 14:11:51 +0100 To: hardie@nic.nasa.gov From: Graham Klyne Subject: Re: Issue 3: (STANDARD_MEASURES) Cc: conneg WG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 12:12 27/05/98 -0700, Ted Hardie wrote: >Graham, > In some cases, we have the advantage that >someone has already made a standard which includes >units; we can adopt the printer MIB and refer to iso-A4 >or na-letter paper sizes without caring that the >underlying units used to define the two changes from cm >to inches. I agree, but don't think these have bearing on this issue because they are tokens with defined meanings. A token is not a number, and hence does not raise conversion issues. (Unless one introduces a previously not-considered comparison option: to compare a token value with a numeric value. I suppose one might consider the token to be a unit in its own right. I don't think we really want to get into this stuff right now, do we?) >I think we should think of the feature >registry in those terms--as enabling applications to >pass feature information with relatively little parsing >and no necessary information on what underlies the >features. Again, I agree. I think this issue is raised precisely because it threatens to frustrate that goal. > I would rather have a system which had both a >"pixels per inch" and a "pixels per centimeter" with a >defined way of moving from ppi to ppcm because I believe >that in many cases there is already a strong tradition >of using a specific unit in specific application >domains. There will be cases where resources cross >those domains, and we do need a conversion mechanism for >those cases. If we allow people to register features >like "pixels per" with no units, we have significantly >complicated the process of interpreting the features, >with benefits in a relatively small number of exchanges. Again, I agree. The "units" approach was an attempt to achieve this. The only difference I perceive from what you say was that I was not suggesting that "strong tradition" (maybe reflected in the registration) be used to define the default unit for any particular feature. But on the other hand: why not? If the registration is required to state default units (with authors encouraged to use SI units) then the absence of an explicit unit is regarded as equivalent to specifying the default. It would still be possible to regard all unit values as constants for conversion to SI (which is not the same as saying that implementations would be required to perform such conversion: it would just provide a consistent framework for interpreting such values.) Do you think the units approach exceeds the "relatively little parsing" goal? > That said, I don't see any reason why we cannot >say that metric measures are to be preferred where there >is not already an established standard. I am also not >wedded to the idea that the second registrant of "pixels >per something" should be the one to define how it >relates to the first "pixels per something"--it just >seems one way to handle the need. Your second sentence I agree with wholeheartedly. Indeed, I think that way lies madness. >Graham Klyne wrote: >> Subject: Issue 3: (STANDARD_MEASURES) >> This has potential to get messy, I think. >> >> I'd go with the need to indicate allowed units in the feature registration. >> But I think we also need to indicate a standard way for designating units >> in protocol elements (What is default unit? How are alternatives indicated?) >> >> I think this is going to be important when it comes to actually >> implementing interoperable protocol processors that handle units. >> >> For example, taking the issue of paper size measured in Inches, Millimetres >> or Metres. I suggest that the measurements are of the form: >> >> [ "in" | "mm" | "m" ] >> >> where the default is "m". (I would argue for use of SI units as default in >> all cases.) >> >> Another example, image resolutions in dpi, dpcm, dpm: >> >> [ "/" ( "in" | "cm" | "m" ) ] >> >> The above notation is consistent with use of juxtaposition as >> multiplication, "/" as division and unit designators simply being constants >> for conversion from the named unit to SI. Thus, this provides a consistent >> framework which can extend to any measurement type. And a consistent >> interpretation (i.e. SI) in the absence of a unit designation. >> >> (I believe there was some programming language work which explored the use >> of unit designators in this way, but I cannot recall any references.) >> >> A number of such units might be defined in the registration document, so >> that the introduction of new units in individual feature registrations is >> an exception rather than norm: >> Length: in, ft, pt, mm, cm, m >> Area: sqin, sqft, sqmm sqcm, sqm >> Mass: lb, g, kg >> : >> >> BTW, I think that it may be advisable to reserve unit names so that they >> cannot be allocated as non-faceted feature tags (i.e. in the IETF tree). >> >> #g >> >> ------------ >> Graham Klyne >>-- End of excerpt from Graham Klyne > > > ------------ Graham Klyne From owner-ietf-medfree Thu May 28 07:45:25 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA12676 for ietf-medfree-bks; Thu, 28 May 1998 07:45:25 -0700 (PDT) Received: from access4.digex.net (qlE46B5DiGQyA@access4.digex.net [205.197.245.195]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA12672 for ; Thu, 28 May 1998 07:45:24 -0700 (PDT) Received: (from asgilman@localhost) by access4.digex.net (8.8.4/8.8.4) id KAA00973 for ietf-medfree@imc.org; Thu, 28 May 1998 10:49:37 -0400 (EDT) From: Al Gilman Message-Id: <199805281449.KAA00973@access4.digex.net> Subject: Re: Issue 3: (STANDARD_MEASURES) To: ietf-medfree@imc.org Date: Thu, 28 May 1998 10:49:37 -0400 (EDT) In-Reply-To: <3.0.32.19980528105927.008bf940@pop.dial.pipex.com> from Graham Klyne at "May 28, 98 02:11:51 pm" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk to follow up on what Graham Klyne said: > At 12:12 27/05/98 -0700, Ted Hardie wrote: > >Graham, > > In some cases, we have the advantage that > >someone has already made a standard which includes > >units; we can adopt the printer MIB and refer to iso-A4 > >or na-letter paper sizes without caring that the > >underlying units used to define the two changes from cm > >to inches. > > I agree, but don't think these have bearing on this issue because they are > tokens with defined meanings. A token is not a number, and hence does not > raise conversion issues. > > (Unless one introduces a previously not-considered comparison option: to > compare a token value with a numeric value. I suppose one might consider > the token to be a unit in its own right. I don't think we really want to > get into this stuff right now, do we?) This provides an excellent example to discuss. The A4 token is not just a token, it is a paper size. A paper size is a planar shape. The print area required by an image is a planar shape. I claim that the following query has standing that this group should consider how it would be answered: "Which is the nearest printer on the net which can print this image on one sheet of paper?" This requires that the application know how to compare bounding boxes computed from image size as an integer rectangle of pixel counts and printer resolution in pixels/length-unit and paper size expressed as a standard-sheet token. > >I think we should think of the feature > >registry in those terms--as enabling applications to > >pass feature information with relatively little parsing > >and no necessary information on what underlies the > >features. > > Again, I agree. I think this issue is raised precisely because it > threatens to frustrate that goal. And I beg to differ. You are thinking about defining the registry in terms of its initial contents, but I think you need to think about the registry in terms of its next layer of contents: the features that were not in widespread use before they were registered. You are confusing apples and oranges. The language of the registry can either make it possible or impossible to express the conversion from paper tokens to planar areas. Making it possible to express this in the language of the registry does not add one CPU instruction to the equality test for paper tokens. That is still the same. The list of recognized paper-size tokens is fixed and compiled in. I am not going to claim that the registry needs to contain the physical dimensions of A4 paper. That relationship can be trusted, not defined in machine-comprehensible scripts. The RFC which defines the initial feature set is not a result of the registry process. And it will cite [perhaps indirectly] in natural language the natural language document which defines the physical measurements of A4 paper. But the registry is not just to catch up with what is already common parlance. If that is its mission, we don't need it. When people come to the registry with novel characteristic names or tokens, there has to be some back-pressure by which it is discovered that, at the bottom of it all, paper size tokens and image sizes can be compared if you know the resolution and the unprintable margin of the printer. The structure of the registry is not for the features that get grandfathered in at the outset. Dealing with the grandfathered properties is necessary but not sufficient for the registry. Al From owner-ietf-medfree Thu May 28 07:59:42 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA12789 for ietf-medfree-bks; Thu, 28 May 1998 07:59:42 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA12781 for ; Thu, 28 May 1998 07:59:40 -0700 (PDT) Received: (qmail 12846 invoked from network); 28 May 1998 15:03:56 -0000 Received: from ag097.du.pipex.com (HELO GK.Group5.co.uk) (193.130.246.97) by smtp.dial.pipex.com with SMTP; 28 May 1998 15:03:56 -0000 Message-Id: <3.0.32.19980528141920.00ac1890@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 28 May 1998 16:03:55 +0100 To: koen@win.tue.nl (Koen Holtman) From: Graham Klyne Subject: Re: New issue: VALUE_CHARS Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 13:36 28/05/98 +0200, Koen Holtman wrote: > >I notice that draft-ietf-conneg-feature-reg-00.txt restricts the >chars in tag *values* to > > uppercase letters, lowercase letters, > digits, colon (":"), slash("/"), dot("."), and dash ("-") > >I find this unacceptable: it will limits the ability to use some >legacy enumeration types as feature tag values without any good >reason. > >I also note that value comparison is defined as case-insensitive. I >can live with that though I would like to say that TCN defines it as >case sensitive. I missed that when I read it. I had thought there was a also a quoted-string form for a tag value which would allow any other characters (for string-values features rather than token-values features). I would expect tokens to have case insensitive matching, but quoted strings to be case sensitive. #g ------------ Graham Klyne From owner-ietf-medfree Thu May 28 07:59:42 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA12790 for ietf-medfree-bks; Thu, 28 May 1998 07:59:42 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA12782 for ; Thu, 28 May 1998 07:59:40 -0700 (PDT) Received: (qmail 12854 invoked from network); 28 May 1998 15:03:58 -0000 Received: from ag097.du.pipex.com (HELO GK.Group5.co.uk) (193.130.246.97) by smtp.dial.pipex.com with SMTP; 28 May 1998 15:03:58 -0000 Message-Id: <3.0.32.19980528142205.00a95d50@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 28 May 1998 16:03:57 +0100 To: koen@win.tue.nl (Koen Holtman) From: Graham Klyne Subject: Re: Issue 5: (SOME_CHARS) Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 13:36 28/05/98 +0200, Koen Holtman wrote: >Also I would prefer it if the tags in the URI tree did not have a >leading u. facet. I would prefer the following rules: > - all tags with a : in it are in the URI tree > - tags in other trees never have a : in them. I queried that, and there was a good reason not to do it. I think it was a requirement to permit relative URIs? #g ------------ Graham Klyne From owner-ietf-medfree Thu May 28 08:19:13 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA12995 for ietf-medfree-bks; Thu, 28 May 1998 08:19:13 -0700 (PDT) Received: from access4.digex.net (qlE46B5DiGQyA@access4.digex.net [205.197.245.195]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA12991 for ; Thu, 28 May 1998 08:19:12 -0700 (PDT) Received: (from asgilman@localhost) by access4.digex.net (8.8.4/8.8.4) id LAA01466; Thu, 28 May 1998 11:15:12 -0400 (EDT) From: Al Gilman Message-Id: <199805281515.LAA01466@access4.digex.net> Subject: Re: Issue: DATA_TYPES To: GK@ACM.ORG (Graham Klyne) Date: Thu, 28 May 1998 11:15:12 -0400 (EDT) Cc: ietf-medfree@imc.org In-Reply-To: <3.0.32.19980528111201.0097ab50@pop.dial.pipex.com> from Graham Klyne at "May 28, 98 02:11:55 pm" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk to follow up on what Graham Klyne said: > > >> I believe that, within the proposed framework, such a thing > >> could be implemented very easily. The bigger problem is how an > >> implementation would obtain a copy of the defining expression. > > > >How can that be a problem? Does not registration entail making > >the registration data packet accessible via the Internet? > >Structuring this datagram so that machine-interpretable scripts > >embedded in it can be conveniently extracted should be part of > >the up-front planning. > > This is fine if machine-interpretable scripts are generally sent with the > capability description. But I'm not sure this would be generally > acceptable. For example, it's difficult to see how such feature tag > definitions could be incorporated into the TCN scheme. Let me explain a little more what I see as a possible architecture, here. I would assume that machine-interpretable definition scripts are normally _not_ sent in capability descriptions. Capability descriptions are expressed in the syntax of the current protocol. They do happen in the context of some communciation, so there is some communication path. The registry provides a namespace and some capability for defining features. It is also a reference database served by one or more protocols over the Internet. Each registered name serves as a sufficient key to isolate a unique definition. The protocol implementation of negotiation includes a binding from protocol syntax to canonical registry syntax for the names. This must preserve the integrity of the namespace created by the registry -- references in the protocol must be resolvable to a unique registered name. The registered dictionary of features is served on the Internet by one or more protocols. The protocol used to exchange queries to get definitions from the registry and the protocol in which the feature name is mentioned are totally independent. Let us talk about the current protocol as the protocol in which the capability property is used and the reference protocol as the protocol used for asynchronous access of the registry. Clients of the current protocol will be of three classes, distinguished by currency w.r.t. the registry: Those that only implement the properties in an RFC. Those that implement properties registered prior to a fixed date, by compilation. Those that implement properties registered with machine interpretable methods prior to the date of the negotiation exchange, by interpretation. [by exception. compiling in optimizations for properties known in the registry at compile date.] The Working Group may project that the third class of clients will be so small during the service life of this registry that you don't need to worry about it. But that limits the registry to properties for which the registry has limited value added. Alternative methods of propagating the property definitions will probably serve well enough. Clients that wish to implement the third level of currency will have not trouble building in the reference protocol for registry accesses. Al From owner-ietf-medfree Thu May 28 09:03:33 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA13443 for ietf-medfree-bks; Thu, 28 May 1998 09:03:33 -0700 (PDT) Received: from access1.digex.net (qlE46B5DiGQyA@access1.digex.net [205.197.245.192]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA13438 for ; Thu, 28 May 1998 09:03:23 -0700 (PDT) Received: (from asgilman@localhost) by access1.digex.net (8.8.4/8.8.4) id MAA21409 for ietf-medfree@imc.org; Thu, 28 May 1998 12:07:25 -0400 (EDT) From: Al Gilman Message-Id: <199805281607.MAA21409@access1.digex.net> Subject: Re: Issue 4: (RAT_HOLE) To: ietf-medfree@imc.org Date: Thu, 28 May 1998 12:07:24 -0400 (EDT) In-Reply-To: <199805281138.NAA02767@wsooti08.win.tue.nl> from Koen Holtman at "May 28, 98 01:38:36 pm" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk to follow up on what Koen Holtman said: > > New related issue: CONTENT_LIMITATION > >... The early registration drafts essentially had > > (1) A feature tag must serve as an actual identifier of something > which can be negotiated on. > > and I think language like that should be restored. Second the motion. Maybe the language should be more like "A feature tag must convey information that bears on a negotiable decision." The point of the language in the initial document is just to lay the grounds for a challenge to a registration, and possible rejection. The answer to the challenge to a registration is a scenario explaining the benefit of this tag in some negotiation. The point is that the registration authority does have some latitude to reject registrations that are not germane. I am a little nervous about the use of the term "identifier" which some might take to exclude "qualifiers" which are clearly germane. Al From owner-ietf-medfree Thu May 28 10:32:24 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA14206 for ietf-medfree-bks; Thu, 28 May 1998 10:32:24 -0700 (PDT) Received: from access1.digex.net (qlE46B5DiGQyA@access1.digex.net [205.197.245.192]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA14202 for ; Thu, 28 May 1998 10:32:22 -0700 (PDT) Received: (from asgilman@localhost) by access1.digex.net (8.8.4/8.8.4) id NAA24624; Thu, 28 May 1998 13:35:27 -0400 (EDT) From: Al Gilman Message-Id: <199805281735.NAA24624@access1.digex.net> Subject: Re: Issue: DATA_TYPES To: GK@ACM.ORG (Graham Klyne) Date: Thu, 28 May 1998 13:35:26 -0400 (EDT) Cc: ietf-medfree@imc.org In-Reply-To: <3.0.32.19980528124308.007a2100@pop.dial.pipex.com> from Graham Klyne at "May 28, 98 02:12:03 pm" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk to follow up on what Graham Klyne said: > Excellent! I'll try and make some suggestions, and you can > tell me if they fly from your PoV... Great! [example in this message, generics follow] > > >* Now: > > > >A refreshable Braille display. This is one line of characters, > >which can be independently updated a_la curses. The characters > >may be six-dot pr eight-dot braille cells. The six-dot and > >eight-dot character sets can be identified as ranges of Unicode > >code points, by the way, so that is not a big hassle to connect > >with Internet usage. > > Braille = { sixdot, eightdot } > > Feature values are just tokens. I would imagine that eightdot is a Taking "Feature values are just tokens" literally, you would get a severe argument. But I don't think that is what you mean. Here is an echo of what I can say "yea, verily" to: This can be handled within the current vocuabulary of feature classes as either a Boolean attribute Braille-cell = { sixdot, eightdot } Or an integer attribute Braille-cell-dots = Number'{ 6 , 8 } > superset of sixdot, so that an ordering relationship would be useful, so > that one could write (say): > > ( Braille >= sixdot ) Yes, eight-dot devices are usable for six-dot literature so this is valuable knowledge. If we go with the integer attribute, we get this for free. I need room for my subcommittee to come up with a choice of the information model, but I don't see a problem because the choice of boolean or integer covers what I think is enough room to get the job done. > >The number of > >cells across the row of the device is a parameter. Actually, we > >do need to cover multi-row devices, but that is not exotic > >relative to other parameter needs (2D and integers). > > Rows = integer > Cols = integer > > Where these are character cell measurements rather than pixel measurements. > Maybe the feature tag names should be more specific to Braille (e.g. > BrailRows, BrailleCols)? That gets political. I need to defer to the duly constituted team. The option of using a parameter shared, for example, with the description of the curses screen should be kept open. But it doesn't affect the issue of what values we need. These things are counting numbers (Integers > 0) if they are valid. > > > We would > >need to distinguish the size of the cell array (two integers) and > >the character set supported in each cell (ranges of integers to > >be interpreted as Unicode). > > Could the character set capability be handled by a token? > > BrailleChars = { BrailleCharset1, BrailleCharset2, ... } Not very good. > Or even handled by standard character set designations? Yes. This should be able to be handled by text-conventions metadata compatible with the emerging internationalization usage. See the recent internationalization literature for why "charsets" may not be the best answer, strictly. I defer to Larry. The scenario with the most requirments for intelligence in the headers is the one where the document is translated to Braille characters at the server, but using an encoding level chosen based on preferences expressed by the user. This will either be a registered token or a URI. That is yet to be determined. But if you cover token, string, and URI I think we are set. > >A paper embosser operating in graphics mode (John Gardner's TIGER > >device) which can be described by a pixel array with size in > >pixels and density in pixels/length-unit, a one-bit color > >depth, but you want a flag that says this one bit is palpable > >raised embossing. Paper size would be as with ink print. > > BraillePixel = Boolean > > or even > > BraillePixel = Integer > > to allow Braille points to be constructed from multiple smaller pixels. (I > am imagining some use of conventional print technology to produce feelable > output. There used to be programs to produce Braille output on old-style > conventional line printers. Maybe a special paper might be designed to > react to laser printer toner/fixing cycles to cause raised bumps?) This gets back to "the schema is TBD in the hands of the subcommittee." With the caveat that sharing array size parameters between print pixels, screen pixels, and tactile bump-iles must be one of the feasible options available to them. There is almost certain to be a simple attribute, however, that asserts that the point of this medium is raised embossing one can feel with the fingers. There won't be a 3D pattern registered for this, just a name. > >* Future: > > > >Classifying audio environments as to their spatial resolution. > >These can contain one point (no spatial diversity), two points > >(stereo boom box), two continuous (spherical coordinates) degrees > >of freedom with a scalar resolution, up to three dimensions with > >a resolution quantified by a 3D resolution tensor that varies > >over the volume (blue sky). > > AudioSpace = { Mono, Stereo, Spherical, MultiDim } > > AudioAlphaRes = Rational // Spherical resolution > AudioBetaRes = Rational > > Your final example I don't understand, but I suspect this might be a case > where some kind of array-valued feature is required. I am thinking of it > being something like a gamma correction curve or other continuous function > represented by an array of point values. Well, sample value-pairs as data and an interpolation method by name. Since I don't know how this is done in VRML in practice, I am not going take a lot of your time with specifics. The basic repertory including signed integers and rationals handles everything until we try to show a space-varying resolution, which is far out and is along the lines that you said. > Currently, the -algebra- draft does not provide for array-valued features, > and indicates that this might be required in future. My inclination on > this is to leave it for now, and assume additional feature types can be > introduced in future if really needed. Somehow we want to take account of the fact that there are relations that need to be exchanged in the negotiation. I am not sure we can hide that entirely in the algebra, or maybe the architecture says that the algebra is there because there is a need to communicate relations. The poster child of relations is the correspondence between q-factors and feature sets. > [Background: I don't wish to get into Chebychev polynomials in detail Agreed. I think that the relevant question is whether there is a way to escape to e.g. VRML to convey a world model that pertains. Is this by URI? Is there an inline option? Al From owner-ietf-medfree Thu May 28 11:06:32 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA14532 for ietf-medfree-bks; Thu, 28 May 1998 11:06:32 -0700 (PDT) Received: from wsooti08.win.tue.nl (wsooti08.win.tue.nl [131.155.70.156]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA14528 for ; Thu, 28 May 1998 11:06:31 -0700 (PDT) Received: from koen@localhost by wsooti08.win.tue.nl (8.8.7) id UAA03643. Thu, 28 May 1998 20:10:40 +0200 (MET DST) From: koen@win.tue.nl (Koen Holtman) Message-Id: <199805281810.UAA03643@wsooti08.win.tue.nl> Subject: New issue: TERMINOLOGY_FIX To: hardie@nic.nasa.gov Date: Thu, 28 May 1998 20:10:40 +0200 (MET DST) Cc: ietf-medfree@imc.org In-Reply-To: <9805261534.ZM1261@thornhill.arc.nasa.gov> from "Ted Hardie" at May 26, 98 03:34:30 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ietf-medfree@imc.org Precedence: bulk I would like to propose the following (editorial) issue: TERMINOLOGY_FIX : go over draft and make sure that all terms are used consistently. I believe that subsequent editing passes have caused some terminoloy drift, but not all uses of a term have drifted the same way! For example, on reading the draft I encountered terms like: Content Feature Tag content feature description content feature identification content feature dimension of feature capability feature tag dimension of characteristic which all seem to be descendants from the term `feature tag' which was used in TCN. I agree with renaming 'feature tag' to 'content feature tag', but the new name should be used consistently. Koen. From owner-ietf-medfree Thu May 28 11:59:27 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA15032 for ietf-medfree-bks; Thu, 28 May 1998 11:59:27 -0700 (PDT) Received: from access2.digex.net (qlE46B5DiGQyA@access2.digex.net [205.197.245.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA15028 for ; Thu, 28 May 1998 11:59:26 -0700 (PDT) Received: (from asgilman@localhost) by access2.digex.net (8.8.4/8.8.4) id PAA20846 for ietf-medfree@imc.org; Thu, 28 May 1998 15:05:35 -0400 (EDT) From: Al Gilman Message-Id: <199805281905.PAA20846@access2.digex.net> Subject: Re: Issue: DATA_TYPES To: ietf-medfree@imc.org Date: Thu, 28 May 1998 15:05:35 -0400 (EDT) In-Reply-To: <3.0.32.19980528114115.00aedc40@pop.dial.pipex.com> from Graham Klyne at "May 28, 98 02:12:01 pm" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk to follow up on what Graham Klyne said: > >Let's concentrate if we can on that aspect--what data types can we > >immediately establish we need? I believe going through that > >process will help us establish where and how we may need to > >add the capability for data type extensions. > > I believe the following are non-contentious: > > - numbers: integer and rational > - tokens, with equality relarionship > - strings, with equality relationship > > I believe the following are highly desired, but raise some problems: > > - ordered tokens > - strings with special ordering relation > > I believe anything else is, at this stage, without clear value. I don't claim to have a complete list. You might want to think about the following issues regarding that list: Do you contemplate treating all URI references as string values? It may be worth considering the role of URIs as feature values as distinct from strings. Are you assuming that the "number" type incorporates physical dimensions and units and their usage? What about sets of values drawn from the above, including ranges? It might be more helpful to discuss the pros and cons of quantities subject to tolerances as opposed to dismissing them out of hand. Even equality on strings requires some care in definition. The applicability of relations in feature definitions in addition to their use in message meta-expressions bears looking into. The registry needs to be designed for additions to the feature dictionary, not just the initial set of features. Al From owner-ietf-medfree Thu May 28 12:18:50 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA15383 for ietf-medfree-bks; Thu, 28 May 1998 12:18:50 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA15379 for ; Thu, 28 May 1998 12:18:49 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA03978 for ietf-medfree@imc.org; Thu, 28 May 1998 12:23:09 -0700 Date: Thu, 28 May 1998 12:23:09 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9805281223.ZM3976@thornhill.arc.nasa.gov> In-Reply-To: Al Gilman "Re: Issue 4: (RAT_HOLE)" (May 28, 12:07pm) References: <199805281607.MAA21409@access1.digex.net> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: ietf-medfree@imc.org Subject: Re: Issue 4: (RAT_HOLE) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk On May 28, 12:07pm, Al Gilman wrote: > Subject: Re: Issue 4: (RAT_HOLE) > >... The early registration drafts essentially had > > > > > (1) A feature tag must serve as an actual identifier of something > > which can be negotiated on. > > > > and I think language like that should be restored. > > Second the motion. Maybe the language should be more like "A > feature tag must convey information that bears on a negotiable > decision." Language like this would get shot down by the A-Ds, who want to make sure that the registry has some bounds to it. You might well want to negotiate the delivery based on content, rather than presentation, but that is clearly out of scope for the registry. Remember that we have been tasked to create a registry on media features (or presentation characteristics, if you want something without the word media in it). The negotiation steps beyond the creation of the registry should take into account the idea that other types of negotiation may occur with the same mechanisms, but the features registered should be clearly bounded. (There was a reason I named this issue RAT_HOLE....) regards, Ted Hardie NASA NIC From owner-ietf-medfree Thu May 28 12:25:52 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA15467 for ietf-medfree-bks; Thu, 28 May 1998 12:25:52 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA15462 for ; Thu, 28 May 1998 12:25:51 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA03991 for ietf-medfree@imc.org; Thu, 28 May 1998 12:30:12 -0700 Date: Thu, 28 May 1998 12:30:12 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9805281230.ZM3989@thornhill.arc.nasa.gov> In-Reply-To: Al Gilman "Re: Issue 3: (STANDARD_MEASURES)" (May 27, 3:39pm) References: <199805271939.PAA12473@access5.digex.net> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: ietf-medfree@imc.org Subject: Re: Issue 3: (STANDARD_MEASURES) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk On May 27, 3:39pm, Al Gilman wrote: > Subject: Re: Issue 3: (STANDARD_MEASURES) > to follow up on what Ted Hardie said: > > > I am also not wedded to the idea that the second registrant of > > "pixels per something" should be the one to define how it > > relates to the first "pixels per something"--it just seems one > > way to handle the need. > > Just curious. I don't see any alternative. Do you? In practice > the registrar will have to exercise bias in the direction of > assuming that a new registration is related to some old > registration, and ask for compare/contrast clarification where > there seems to be overlap. Otherwise there will be a lot of > un-articulated overlap in registered features. > > Al >-- End of excerpt from Al Gilman If the "per something" choice is the choice between metric and imperial units, we can say something like "registration units should be in metric units unless there is a strong tradition for the use of imperial units; in those cases, the registering party should indicate how to convert to metric units, including the rounding policy for applications which require integers". This puts the onus on the non-metric users, rather than the second user. This may be a better idea in any case. regards, Ted Hardie NASA NIC From owner-ietf-medfree Thu May 28 13:48:10 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA16563 for ietf-medfree-bks; Thu, 28 May 1998 13:48:10 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA16559 for ; Thu, 28 May 1998 13:48:09 -0700 (PDT) Received: from casablanca.parc.xerox.com ([13.2.16.111]) by alpha.xerox.com with SMTP id <52440(4)>; Thu, 28 May 1998 13:52:24 PDT Received: from copper.parc.xerox.com ([13.1.102.170]) by casablanca.parc.xerox.com with SMTP id <71820>; Thu, 28 May 1998 13:50:47 PDT From: "Larry Masinter" To: "Graham Klyne" Cc: "conneg WG" Subject: RE: Issue 5: (SOME_CHARS) Date: Thu, 28 May 1998 13:50:47 PDT Message-ID: <000d01bd8a7a$4a2c43a0$aa66010d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <3.0.32.19980528112409.00a95dd0@pop.dial.pipex.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-medfree@imc.org Precedence: bulk > If I remember correctly, -URI-Syntax- uses %hh for escape coding (so many > escape schemes to keep track of). Maybe if the allowed character set were > to include '%', and '%' used for escape purposes... ? It would be good to include '%' in the allowed set, but not so good to go into depth about what '%' is used for, since the escaping is not a simple task of converting any disallowed character. From owner-ietf-medfree Thu May 28 15:43:46 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA17684 for ietf-medfree-bks; Thu, 28 May 1998 15:43:46 -0700 (PDT) Received: from access2.digex.net (qlYBsVTekvXHY@access2.digex.net [205.197.245.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA17680 for ; Thu, 28 May 1998 15:43:45 -0700 (PDT) Received: (from asgilman@localhost) by access2.digex.net (8.8.4/8.8.4) id RAA24380; Thu, 28 May 1998 17:35:09 -0400 (EDT) From: Al Gilman Message-Id: <199805282135.RAA24380@access2.digex.net> Subject: Re: Issue 3: (STANDARD_MEASURES) To: hardie@nic.nasa.gov Date: Thu, 28 May 1998 17:35:09 -0400 (EDT) Cc: ietf-medfree@imc.org In-Reply-To: <9805281230.ZM3989@thornhill.arc.nasa.gov> from Ted Hardie at "May 28, 98 12:30:12 pm" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk to follow up on what Ted Hardie said: > If the "per something" choice is the choice between metric and > imperial units, we can say something like "registration units > should be in metric units unless there is a strong tradition > for the use of imperial units; in those cases, the registering > party should indicate how to convert to metric units, including > the rounding policy for applications which require integers". > This puts the onus on the non-metric users, rather than the > second user. This may be a better idea in any case. Got it. Recognize SI units up front. Even before any features are registered, there is a precedent regarding units. Al From owner-ietf-medfree Fri May 29 04:23:40 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA07552 for ietf-medfree-bks; Fri, 29 May 1998 04:23:40 -0700 (PDT) Received: from wsooti08.win.tue.nl (wsooti08.win.tue.nl [131.155.70.156]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA07548 for ; Fri, 29 May 1998 04:23:38 -0700 (PDT) Received: from koen@localhost by wsooti08.win.tue.nl (8.8.7) id NAA05152. Fri, 29 May 1998 13:27:47 +0200 (MET DST) From: koen@win.tue.nl (Koen Holtman) Message-Id: <199805291127.NAA05152@wsooti08.win.tue.nl> Subject: Re: Issue 4: (RAT_HOLE) To: hardie@nic.nasa.gov Date: Fri, 29 May 1998 13:27:46 +0200 (MET DST) Cc: ietf-medfree@imc.org In-Reply-To: <9805281223.ZM3976@thornhill.arc.nasa.gov> from "Ted Hardie" at May 28, 98 12:23:09 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ietf-medfree@imc.org Precedence: bulk Ted Hardie: > >On May 28, 12:07pm, Al Gilman wrote: >> Subject: Re: Issue 4: (RAT_HOLE) > >> >... The early registration drafts essentially had >> >> > >> > (1) A feature tag must serve as an actual identifier of something >> > which can be negotiated on. >> > >> > and I think language like that should be restored. >> >> Second the motion. Maybe the language should be more like "A >> feature tag must convey information that bears on a negotiable >> decision." > >Language like this would get shot down by the A-Ds, who want >to make sure that the registry has some bounds to it. I could understand the AD's wanting the charter to be bound, but I am a bit confused by a requirement that the registry is bound. Could you cite relevant text/conversations? Koen. From owner-ietf-medfree Fri May 29 04:30:16 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA07592 for ietf-medfree-bks; Fri, 29 May 1998 04:30:16 -0700 (PDT) Received: from wsooti08.win.tue.nl (wsooti08.win.tue.nl [131.155.70.156]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA07588 for ; Fri, 29 May 1998 04:30:14 -0700 (PDT) Received: from koen@localhost by wsooti08.win.tue.nl (8.8.7) id NAA05165. Fri, 29 May 1998 13:34:33 +0200 (MET DST) From: koen@win.tue.nl (Koen Holtman) Message-Id: <199805291134.NAA05165@wsooti08.win.tue.nl> Subject: Re: Issue 5: (SOME_CHARS) To: GK@ACM.ORG (Graham Klyne) Date: Fri, 29 May 1998 13:34:32 +0200 (MET DST) Cc: koen@win.tue.nl, ietf-medfree@imc.org In-Reply-To: <3.0.32.19980528142205.00a95d50@pop.dial.pipex.com> from "Graham Klyne" at May 28, 98 04:03:57 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ietf-medfree@imc.org Precedence: bulk Graham Klyne: > >At 13:36 28/05/98 +0200, Koen Holtman wrote: >>Also I would prefer it if the tags in the URI tree did not have a >>leading u. facet. I would prefer the following rules: >> - all tags with a : in it are in the URI tree >> - tags in other trees never have a : in them. > >I queried that, and there was a good reason not to do it. I think it was a >requirement to permit relative URIs? Eek! I hope no one is seriously considering using relative URIs (at least not without also adding a definition of what they are relative to). Éf that is the reason I do not think it is a good one. Question to the editors: what is the current rationale for u. ? >#g Koen. From owner-ietf-medfree Fri May 29 08:51:05 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA09147 for ietf-medfree-bks; Fri, 29 May 1998 08:51:05 -0700 (PDT) Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA09143 for ; Fri, 29 May 1998 08:51:03 -0700 (PDT) Received: from hplaef.cup.hp.com (hplaef.cup.hp.com [15.0.90.185]) by palrel3.hp.com (8.8.5/8.8.5tis) with ESMTP id IAA08361; Fri, 29 May 1998 08:55:27 -0700 (PDT) Received: from neutrino (neutrino.cup.hp.com [15.0.90.201]) by hplaef.cup.hp.com with SMTP (8.7.1/8.7.3 TIS Messaging 5.0) id JAA20580; Fri, 29 May 1998 09:04:22 -0700 (PDT) From: "Andrew Mutz" To: "Koen Holtman" , "Graham Klyne" Cc: Subject: RE: Issue 5: (SOME_CHARS) Date: Fri, 29 May 1998 08:52:30 -0700 Message-ID: <000001bd8b19$c955d250$c95a000f@neutrino.cup.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <199805291134.NAA05165@wsooti08.win.tue.nl> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-medfree@imc.org Precedence: bulk The rational for the u. facet was to clarify quickly whether a feature was a URI or a global IETF feature. Without a defined facet, we would have to restrict use of ":" to URIs as you point out. Since we started out (from TCN) using facets, it seemed a straightforward approach. Use of relative URIs was also discussed for local applications, but I agree with Koen's view that relative URIs are likely to be unpredictable. Andy --------------------------------------------------- Andrew Mutz email andy_mutz@hp.com Internet Imaging Operation phone +1 408 447 4439 Hewlett-Packard Company fax +1 408 447 2842 11000 Wolfe Road 42UO radio KF6FUT Cupertino, CA 95014, USA --------------------------------------------------- -----Original Message----- From: owner-ietf-medfree@imc.org [mailto:owner-ietf-medfree@imc.org]On Behalf Of Koen Holtman Sent: Friday, May 29, 1998 4:35 AM To: Graham Klyne Cc: koen@win.tue.nl; ietf-medfree@imc.org Subject: Re: Issue 5: (SOME_CHARS) Graham Klyne: > >At 13:36 28/05/98 +0200, Koen Holtman wrote: >>Also I would prefer it if the tags in the URI tree did not have a >>leading u. facet. I would prefer the following rules: >> - all tags with a : in it are in the URI tree >> - tags in other trees never have a : in them. > >I queried that, and there was a good reason not to do it. I think it was a >requirement to permit relative URIs? Eek! I hope no one is seriously considering using relative URIs (at least not without also adding a definition of what they are relative to). Éf that is the reason I do not think it is a good one. Question to the editors: what is the current rationale for u. ? >#g Koen. From owner-ietf-medfree Fri May 29 22:51:07 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA19050 for ietf-medfree-bks; Fri, 29 May 1998 22:51:07 -0700 (PDT) Received: from relay.unican.es (relay.unican.es [130.206.5.45]) by mail.proper.com (8.8.8/8.8.5) with SMTP id WAA18984; Fri, 29 May 1998 22:50:56 -0700 (PDT) Received: from 01-044.015.popsite.net by relay.unican.es with SMTP (1.37.109.4/16.2) id AA06822; Sat, 30 May 98 07:59:12 +0100 Date: Sat, 30 May 98 07:59:12 +0100 From: 584bds <584bds@att.net> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Wednesday, July 1st, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Monday, June 29th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Saturday, June 27th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Friday, June 26th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Thursday, July 2nd, 1998 Reply-To: 584bds@att.net Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <584bds@att.net> Subject: 5 8 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Sun May 31 19:24:58 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA23472 for ietf-medfree-bks; Sun, 31 May 1998 19:24:58 -0700 (PDT) Received: from is00pr02.kepco.co.jp (smtp1.kepco.co.jp [210.173.67.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA23468 for ; Sun, 31 May 1998 19:24:56 -0700 (PDT) Date: Sun, 31 May 1998 19:24:56 -0700 (PDT) Received: from default ([207.240.250.62]) by is00pr02.kepco.co.jp (Netscape Mail Server v2.02) with SMTP id AAC11506; Mon, 1 Jun 1998 11:28:54 +0900 From: 6hh2w3 <6hh2w3@mci.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Saturday, July 4th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Thursday, July 2nd, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Tuesday, June 30th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Monday, June 29th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Sunday, July 5th, 1998 Reply-To: 6hh2w3@mci.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <6hh2w3@mci.com> Subject: 6hh Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Mon Jun 1 09:37:21 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA13768 for ietf-medfree-bks; Mon, 1 Jun 1998 09:37:21 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA13764 for ; Mon, 1 Jun 1998 09:37:20 -0700 (PDT) Received: (qmail 16638 invoked from network); 1 Jun 1998 16:41:55 -0000 Received: from an012.du.pipex.com (HELO GK.Group5.co.uk) (193.130.253.12) by smtp.dial.pipex.com with SMTP; 1 Jun 1998 16:41:55 -0000 Message-Id: <3.0.32.19980601151944.0097a9a0@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 01 Jun 1998 17:41:54 +0100 To: Al Gilman From: Graham Klyne Subject: Re: Issue: DATA_TYPES Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 13:35 28/05/98 -0400, Al Gilman wrote: >to follow up on what Graham Klyne said: > >> Excellent! I'll try and make some suggestions, and you can >> tell me if they fly from your PoV... > >Great! > >[example in this message, generics follow] Without going into detail, I get the impression that the simple data model proposed stands up pretty well to the simple cases. Things like "gamma correction curves", etc, seem to be on the edge but maybe do-able. It's not clear to me whether or not more will be needed in the future, but it does seem that it's way to soon to be trying to specify anything more detailed at this stage. #g ------------ Graham Klyne From owner-ietf-medfree Mon Jun 1 09:36:44 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA13730 for ietf-medfree-bks; Mon, 1 Jun 1998 09:36:44 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA13723 for ; Mon, 1 Jun 1998 09:36:43 -0700 (PDT) Received: (qmail 16470 invoked from network); 1 Jun 1998 16:41:20 -0000 Received: from an012.du.pipex.com (HELO GK.Group5.co.uk) (193.130.253.12) by smtp.dial.pipex.com with SMTP; 1 Jun 1998 16:41:20 -0000 Message-Id: <3.0.32.19980601145008.007a24d0@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 01 Jun 1998 17:41:18 +0100 To: hardie@nic.nasa.gov From: Graham Klyne Subject: Re: Issue 3: (STANDARD_MEASURES) Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 12:30 28/05/98 -0700, Ted Hardie wrote: >If the "per something" choice is the choice between metric >and imperial units, we can say something like "registration >units should be in metric units unless there is a strong >tradition for the use of imperial units; in those cases, the >registering party should indicate how to convert to metric >units, including the rounding policy for applications which >require integers". This puts the onus on the non-metric >users, rather than the second user. This may be a better >idea in any case. A nit: I distinguish between "metric" and "SI" units. "SI" refers to a specific system of units using "m", Kg" and "s". "Metric", as far as I can recall, does not refer to precisely to a single system of units but may be taken to refer to the "CGS" system using "cm", "g", "s". #g ------------ Graham Klyne From owner-ietf-medfree Mon Jun 1 09:36:52 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA13740 for ietf-medfree-bks; Mon, 1 Jun 1998 09:36:52 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA13736 for ; Mon, 1 Jun 1998 09:36:51 -0700 (PDT) Received: (qmail 16504 invoked from network); 1 Jun 1998 16:41:28 -0000 Received: from an012.du.pipex.com (HELO GK.Group5.co.uk) (193.130.253.12) by smtp.dial.pipex.com with SMTP; 1 Jun 1998 16:41:28 -0000 Message-Id: <3.0.32.19980601145200.0080fb70@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 01 Jun 1998 17:41:26 +0100 To: "Larry Masinter" From: Graham Klyne Subject: RE: Issue 5: (SOME_CHARS) Cc: "conneg WG" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 13:50 28/05/98 PDT, Larry Masinter wrote: >> If I remember correctly, -URI-Syntax- uses %hh for escape coding (so many >> escape schemes to keep track of). Maybe if the allowed character set were >> to include '%', and '%' used for escape purposes... ? > >It would be good to include '%' in the allowed set, but not so good to >go into depth about what '%' is used for, since the escaping is not a simple >task of converting any disallowed character. I agree (still assuming that the general consensus is to avoid allowing arbitrary characters in feature tags). #g ------------ Graham Klyne From owner-ietf-medfree Mon Jun 1 09:37:28 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA13778 for ietf-medfree-bks; Mon, 1 Jun 1998 09:37:28 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA13774 for ; Mon, 1 Jun 1998 09:37:26 -0700 (PDT) Received: (qmail 16662 invoked from network); 1 Jun 1998 16:42:03 -0000 Received: from an012.du.pipex.com (HELO GK.Group5.co.uk) (193.130.253.12) by smtp.dial.pipex.com with SMTP; 1 Jun 1998 16:42:03 -0000 Message-Id: <3.0.32.19980601152237.0080fb00@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 01 Jun 1998 17:42:02 +0100 To: Al Gilman From: Graham Klyne Subject: Re: Issue 4: (RAT_HOLE) Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 12:07 28/05/98 -0400, Al Gilman wrote: >> (1) A feature tag must serve as an actual identifier of something >> which can be negotiated on. >I am a little nervous about the use of the term "identifier" >which some might take to exclude "qualifiers" which are clearly >germane. ? I think the term "identifer" is exactly right here. Can you elucidate your concern? (Note, this is the "feature tag" not the "feature value".) #g ------------ Graham Klyne From owner-ietf-medfree Mon Jun 1 09:36:37 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA13721 for ietf-medfree-bks; Mon, 1 Jun 1998 09:36:37 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA13717 for ; Mon, 1 Jun 1998 09:36:35 -0700 (PDT) Received: (qmail 16442 invoked from network); 1 Jun 1998 16:41:12 -0000 Received: from an012.du.pipex.com (HELO GK.Group5.co.uk) (193.130.253.12) by smtp.dial.pipex.com with SMTP; 1 Jun 1998 16:41:12 -0000 Message-Id: <3.0.32.19980601144343.0080f740@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 01 Jun 1998 17:41:11 +0100 To: koen@win.tue.nl (Koen Holtman) From: Graham Klyne Subject: Re: Issue 4: (RAT_HOLE) Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 13:38 28/05/98 +0200, Koen Holtman wrote: >[...] The early registration drafts essentially had > > (1) A feature tag must serve as an actual identifier of something > which can be negotiated on. > >and I think language like that should be restored. > Personally, I prefer such wording. But I understand there is a desire to avoid getting drawn into less clear issues (as evidenced by the WG charter). #g ------------ Graham Klyne From owner-ietf-medfree Mon Jun 1 09:37:12 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA13759 for ietf-medfree-bks; Mon, 1 Jun 1998 09:37:12 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA13755 for ; Mon, 1 Jun 1998 09:37:11 -0700 (PDT) Received: (qmail 16601 invoked from network); 1 Jun 1998 16:41:46 -0000 Received: from an012.du.pipex.com (HELO GK.Group5.co.uk) (193.130.253.12) by smtp.dial.pipex.com with SMTP; 1 Jun 1998 16:41:46 -0000 Message-Id: <3.0.32.19980601151311.0097a970@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 01 Jun 1998 17:41:45 +0100 To: Al Gilman From: Graham Klyne Subject: Re: Issue: DATA_TYPES Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk Al, from your comment below there is a possible misunderstanding I would like to clarify, and see if we really do agree: At 13:35 28/05/98 -0400, Al Gilman wrote: >Taking "Feature values are just tokens" literally, you would get a >severe argument. But I don't think that is what you mean. I really mean that feature values that are entirely represented by a token. The actual meaning of the token, and any values associated with it, are assumed to be implicit knowledge of many program which can process documents containing that feature. Consider: "Braille = sixdot". A negotiation protocol. processor would knoiw nothing more than the feature tag "Braille" and the token "sixdot" and maybe that "sixdot" is considered to precede "eightdot" in an ordering of "Braille" values. Thus, to the featurte protocol processor, the statement "feature values are just tokens" does hold true. But, a program that renders or processes Braille documents clearly needs to know that the feature value represents far more. In another message, you refer to a similar issue regarding paper sizes (I haven't read that message in detail yet -- I'll make further comment in another response if I decide I've missed your point here.) Yes, of course, "A4" and "US-Letter" and the rest define shapes. But for a negotiation protocol processor they are still just tokens. I believe that this provides a simple generic way for document providers/carriers/users to exchange relevant information about the document while hiding details of docu8ment content from the communication protocol processor. I think this is a key goal of 'conneg'. Does this help? #g ------------ Graham Klyne From owner-ietf-medfree Mon Jun 1 09:37:38 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA13789 for ietf-medfree-bks; Mon, 1 Jun 1998 09:37:38 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA13785 for ; Mon, 1 Jun 1998 09:37:36 -0700 (PDT) Received: (qmail 16708 invoked from network); 1 Jun 1998 16:42:12 -0000 Received: from an012.du.pipex.com (HELO GK.Group5.co.uk) (193.130.253.12) by smtp.dial.pipex.com with SMTP; 1 Jun 1998 16:42:12 -0000 Message-Id: <3.0.32.19980601154756.0097acb0@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 01 Jun 1998 17:42:10 +0100 To: Al Gilman From: Graham Klyne Subject: Re: Issue 3: (STANDARD_MEASURES) Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 10:49 28/05/98 -0400, Al Gilman wrote: >to follow up on what Graham Klyne said: > >> At 12:12 27/05/98 -0700, Ted Hardie wrote: >> >Graham, >> > In some cases, we have the advantage that >> >someone has already made a standard which includes >> >units; we can adopt the printer MIB and refer to iso-A4 >> >or na-letter paper sizes without caring that the >> >underlying units used to define the two changes from cm >> >to inches. >> >> I agree, but don't think these have bearing on this issue because they are >> tokens with defined meanings. A token is not a number, and hence does not >> raise conversion issues. >> >> (Unless one introduces a previously not-considered comparison option: to >> compare a token value with a numeric value. I suppose one might consider >> the token to be a unit in its own right. I don't think we really want to >> get into this stuff right now, do we?) > >This provides an excellent example to discuss. > >The A4 token is not just a token, it is a paper size. A paper size >is a planar shape. The print area required by an image is a planar >shape. I claim that the following query has standing that this group >should consider how it would be answered: "Which is the nearest >printer on the net which can print this image on one sheet of paper?" > >This requires that the application know how to compare bounding boxes >computed from image size as an integer rectangle of pixel counts and >printer resolution in pixels/length-unit and paper size expressed as >a standard-sheet token. Or simply that there is a partial ordering on the token values. (Now, the idea of a partial ordering is one that has not thus far been considered: do we need it?) >> >I think we should think of the feature >> >registry in those terms--as enabling applications to >> >pass feature information with relatively little parsing >> >and no necessary information on what underlies the >> >features. >> >> Again, I agree. I think this issue is raised precisely because it >> threatens to frustrate that goal. > >And I beg to differ. You are thinking about defining the >registry in terms of its initial contents, but I think you need >to think about the registry in terms of its next layer of >contents: the features that were not in widespread use before >they were registered. I generally agree with all you say. I certainly think the registry should not be closed off to future information of the type you suggest. Where we seem to differ is how much of this is to be defined in the first instance. If we recognize that the registry may be extended to incorporate more complex information in future, do we need more for now. My fear is that over-specification of the initial registry may obscure its immediate value. Maybe we do need to consider (now) how the registry might be extended, without attempting to write those considerations into the specification? My vision is something like this: (1) Feature registry (for "simple-valued" features) (2) -> Algebra (3) -> [ Algebra extensions -> ] Feature set registry (4) -> [ Algebra extensions -> ] Feature value type registry That is, more complex feature values and feature value types can be defined using (1), (2) plus possible algebra extensions and added into the feature registry. By basing the registry extension mechanism on that used to perform feature set matching, the implementation load for (3) and (4) can be kept modest. (I'm going to break one of my rules here, and discuss charter/consensus-related matters, something I normally leave to the Chair, but here it underpins the approach I'm taking...) I believe there is a clear consensus here for (1): the charter says so. There seems to be some consensus that (2) could be needed to describe or circumscribe collections of features. As yet, I sense no group consensus to pursue (3) or (4). But in any case, I see (1) and (2) as prerequisites and having immediate value. So, with a longer-term vision and a near-term goal it seems productive on all counts to pursue (1) and (2). #g ------------ Graham Klyne From owner-ietf-medfree Mon Jun 1 09:37:02 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA13750 for ietf-medfree-bks; Mon, 1 Jun 1998 09:37:02 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA13745 for ; Mon, 1 Jun 1998 09:37:01 -0700 (PDT) Received: (qmail 16556 invoked from network); 1 Jun 1998 16:41:36 -0000 Received: from an012.du.pipex.com (HELO GK.Group5.co.uk) (193.130.253.12) by smtp.dial.pipex.com with SMTP; 1 Jun 1998 16:41:36 -0000 Message-Id: <3.0.32.19980601150146.007a24d0@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 01 Jun 1998 17:41:34 +0100 To: Al Gilman From: Graham Klyne Subject: Re: Issue: DATA_TYPES Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 15:05 28/05/98 -0400, Al Gilman wrote: >> I believe the following are non-contentious: >> >> - numbers: integer and rational >> - tokens, with equality relarionship >> - strings, with equality relationship >> >> I believe the following are highly desired, but raise some problems: >> >> - ordered tokens >> - strings with special ordering relation >> >> I believe anything else is, at this stage, without clear value. > >I don't claim to have a complete list. You might want to think >about the following issues regarding that list: > >Do you contemplate treating all URI references as string values? No. I assume that (with data types limited as above) the type can be inferred from the value given. >It may be worth considering the role of URIs as feature values as >distinct from strings. Oh! you mean URIs as *values* (not tags as I assumed above). What specific purpose is served by treating them as more than strings? >Are you assuming that the "number" type incorporates physical >dimensions and units and their usage? What about sets of values >drawn from the above, including ranges? For now, I am not. Units are being addressed as a separate issue. But you are correct that the two do interact in fundamental ways. I belive the units case is simpler than the more general data type case. >It might be more helpful to discuss the pros and cons of >quantities subject to tolerances as opposed to dismissing them >out of hand. I did not mean to dismiss them out of hand. I would say that tolerance might be viewed as a property of a numeric value. I think this could be handled within the discussion on Units. >Even equality on strings requires some care in definition. It may. I had assumed a simple byte-by-byte (or character-by-character) comparison. This does miss some kinds of equivalence, but I had assumed that the application would provide some level of canonicalization. > > >The applicability of relations in feature definitions in addition >to their use in message meta-expressions bears looking into. I agree, but I also believe this can be tackled once a set of "primitive" feature types has been established. I am assuming that relationships might be used to define things like, for example, a tag that indicates a square aspect ratio display by imposing the relationship: (Res-x=Res-y) Maybe you have something deeper in mind? >The registry needs to be designed for additions to the feature >dictionary, not just the initial set of features. Of course. #g ------------ Graham Klyne From owner-ietf-medfree Mon Jun 1 19:20:08 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA25310 for ietf-medfree-bks; Mon, 1 Jun 1998 19:20:08 -0700 (PDT) Received: from gate-xlink.asknet.de (root@gate-xlink.asknet.de [194.122.226.51]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA25306 for ; Mon, 1 Jun 1998 19:20:07 -0700 (PDT) Received: from jj3dw3.q3q3665f.com (pool-207-205-159-145.lsan.grid.net [207.205.159.145]) by gate-xlink.asknet.de (8.8.5/8.8.5) with SMTP id EAA26494; Tue, 2 Jun 1998 04:18:03 +0200 Date: Tue, 2 Jun 1998 04:18:03 +0200 From: 1qq2w3 <1qq2w3@ix.netcom.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Monday, July 6th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Saturday, July 4th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Thursday, July 2nd, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Wednesday, July 1st, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Tuesday, July 7th, 1998 Reply-To: 1qq2w3@ix.netcom.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <1qq2w3@ix.netcom.com> Subject: 1 q Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Tue Jun 2 09:22:13 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA15580 for ietf-medfree-bks; Tue, 2 Jun 1998 09:22:13 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA15576 for ; Tue, 2 Jun 1998 09:22:11 -0700 (PDT) Received: (qmail 6113 invoked from network); 2 Jun 1998 16:26:55 -0000 Received: from unknown (HELO GK.Group5.co.uk) (193.128.238.237) by smtp.dial.pipex.com with SMTP; 2 Jun 1998 16:26:55 -0000 Message-Id: <3.0.32.19980602154844.007a9770@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 02 Jun 1998 17:26:54 +0100 To: conneg WG From: Graham Klyne Subject: Re: Issue 3: (STANDARD_MEASURES) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk [Resend to list - address was still wrong!] Al, I basically agree with what you say. Especially the final paragraph. I am copying your entire message to the list because I don't think it got there first time because of a typo in the address, tho it was clearly intended to. #g At 12:34 28/05/98 -0400, Al Gilman wrote: >to follow up on what Graham Klyne said: > >> I am basically promoting default to SI unless explicitly >> overridden (at per-use or per-feature level or both is under >> debate). > >You may be happier with the results if a bare number for a >feature whose registration (or protocol binding) did not assert a >default unit is an error. > >There are two qualitatively different error modes here. In >one the setter of the attribute does not understand the SI default >and the reader of the attribute receives erroneous information. >In the other there is a processing error at some point, but not >the undetected exchange of bad information. > >This is a judgement call. > >To use SI units as the default, the registration would have to >declare the dimension of the quantity anyway. (length vs. mass >vs....). People are more likely to give you a unit than a >dimension, in practice. > >Al > > ------------ Graham Klyne From owner-ietf-medfree Tue Jun 2 10:54:41 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA16455 for ietf-medfree-bks; Tue, 2 Jun 1998 10:54:41 -0700 (PDT) Received: from wsooti08.win.tue.nl (wsooti08.win.tue.nl [131.155.70.156]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA16451 for ; Tue, 2 Jun 1998 10:54:40 -0700 (PDT) Received: from koen@localhost by wsooti08.win.tue.nl (8.8.7) id TAA09573. Tue, 2 Jun 1998 19:59:03 +0200 (MET DST) From: koen@win.tue.nl (Koen Holtman) Message-Id: <199806021759.TAA09573@wsooti08.win.tue.nl> Subject: Re: Issue 5: (SOME_CHARS) To: masinter@parc.xerox.com (Larry Masinter) Date: Tue, 2 Jun 1998 19:59:03 +0200 (MET DST) Cc: GK@ACM.ORG, ietf-medfree@imc.org In-Reply-To: <000d01bd8a7a$4a2c43a0$aa66010d@copper.parc.xerox.com> from "Larry Masinter" at May 28, 98 01:50:47 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ietf-medfree@imc.org Precedence: bulk Larry Masinter: > >> If I remember correctly, -URI-Syntax- uses %hh for escape coding (so many >> escape schemes to keep track of). Maybe if the allowed character set were >> to include '%', and '%' used for escape purposes... ? > >It would be good to include '%' in the allowed set, but not so good to >go into depth about what '%' is used for, since the escaping is not a simple >task of converting any disallowed character. I strongly disagree. The most important requirement on tags is that they have an unambiguous equality comparison function. If % is included, the spec *must* state exactly how it is used. Koen. From owner-ietf-medfree Tue Jun 2 11:16:11 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA16689 for ietf-medfree-bks; Tue, 2 Jun 1998 11:16:11 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA16685 for ; Tue, 2 Jun 1998 11:16:11 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA09794; Tue, 2 Jun 1998 11:20:54 -0700 Date: Tue, 2 Jun 1998 11:20:54 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9806021120.ZM9792@thornhill.arc.nasa.gov> In-Reply-To: Graham Klyne "Re: Issue 3: (STANDARD_MEASURES)" (Jun 2, 5:26pm) References: <3.0.32.19980602154844.007a9770@pop.dial.pipex.com> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: Graham Klyne , conneg WG Subject: Re: Issue 3: (STANDARD_MEASURES) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk I would like to hear a bit more about why we should default to SI, rather than metric, in this context. Given the ease of conversion among metric units of the same type, limiting the metric units to just the "base" units of meters, kg, s, doesn't seem to be a big win. There are already a number of systems which would seem to prefer things like ppcm , and I don't quite understand yet why we should make it less intuitive for those users. I raise it in this specific context, because the text below seems to go back to the idea of "pixels per" with a unit assignment of meters/centimeters/inches at the time of use. I strongly prefer a single assignment at registration, but I'm not sure if I follow the arguments below on how that would affect when an error condition is produced. In particular, I don't understand when someone would want to register something with indicating a default unit; are there examples for us to chew on? regards, Ted Hardie NASA NIC ---End of forwarded mail from Chris Yarnell > Al, > > I basically agree with what you say. Especially the final paragraph. > > I am copying your entire message to the list because I don't think it got > there first time because of a typo in the address, tho it was clearly > intended to. > > #g > > At 12:34 28/05/98 -0400, Al Gilman wrote: > >to follow up on what Graham Klyne said: > > > >> I am basically promoting default to SI unless explicitly > >> overridden (at per-use or per-feature level or both is under > >> debate). > > > >You may be happier with the results if a bare number for a > >feature whose registration (or protocol binding) did not assert a > >default unit is an error. > > > >There are two qualitatively different error modes here. In > >one the setter of the attribute does not understand the SI default > >and the reader of the attribute receives erroneous information. > >In the other there is a processing error at some point, but not > >the undetected exchange of bad information. > > > >This is a judgement call. > > > >To use SI units as the default, the registration would have to > >declare the dimension of the quantity anyway. (length vs. mass > >vs....). People are more likely to give you a unit than a > >dimension, in practice. > > > >Al > > > > > ------------ > Graham Klyne >-- End of excerpt from Graham Klyne From owner-ietf-medfree Tue Jun 2 11:39:49 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA16844 for ietf-medfree-bks; Tue, 2 Jun 1998 11:39:49 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA16840 for ; Tue, 2 Jun 1998 11:39:47 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA09823 for ietf-medfree@imc.org; Tue, 2 Jun 1998 11:44:27 -0700 Date: Tue, 2 Jun 1998 11:44:27 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9806021144.ZM9821@thornhill.arc.nasa.gov> In-Reply-To: koen@win.tue.nl (Koen Holtman) "Re: Issue 5: (SOME_CHARS)" (Jun 2, 7:59pm) References: <199806021759.TAA09573@wsooti08.win.tue.nl> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: ietf-medfree@imc.org Subject: Re: Issue 5: (SOME_CHARS) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk Koen, Perhaps I misunderstood Larry here, but my assumption was that we would indicate that URIs could include % in the allowed set, but defer the specification on how %-encoding works to the URI groups. However that is specified, the URIs would have an unambiguous equality comparison as tags because the comparison would be against the %-encoded forms. regards, Ted Hardie NASA NIC On Jun 2, 7:59pm, Koen Holtman wrote: > Subject: Re: Issue 5: (SOME_CHARS) > Larry Masinter: > >It would be good to include '%' in the allowed set, but not so good to > >go into depth about what '%' is used for, since the escaping is not a simple > >task of converting any disallowed character. > > I strongly disagree. The most important requirement on tags is that > they have an unambiguous equality comparison function. If % is > included, the spec *must* state exactly how it is used. > > Koen. >-- End of excerpt from Koen Holtman From owner-ietf-medfree Tue Jun 2 12:23:30 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA17156 for ietf-medfree-bks; Tue, 2 Jun 1998 12:23:30 -0700 (PDT) Received: from wsooti08.win.tue.nl (wsooti08.win.tue.nl [131.155.70.156]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA17152 for ; Tue, 2 Jun 1998 12:23:26 -0700 (PDT) Received: from koen@localhost by wsooti08.win.tue.nl (8.8.7) id VAA09600. Tue, 2 Jun 1998 21:28:04 +0200 (MET DST) From: koen@win.tue.nl (Koen Holtman) Message-Id: <199806021928.VAA09600@wsooti08.win.tue.nl> Subject: Re: Issue 5: (SOME_CHARS) To: hardie@nic.nasa.gov Date: Tue, 2 Jun 1998 21:28:04 +0200 (MET DST) Cc: ietf-medfree@imc.org In-Reply-To: <9806021144.ZM9821@thornhill.arc.nasa.gov> from "Ted Hardie" at Jun 2, 98 11:44:27 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ietf-medfree@imc.org Precedence: bulk Ted Hardie: > >Koen, > Perhaps I misunderstood Larry here, but my >assumption was that we would indicate that URIs could >include % in the allowed set, but defer the specification >on how %-encoding works to the URI groups. That would work if these URI groups specify canonical forms, so that we can require use of these canonical forms in any protocol message. But there is no canonical form for http:// URIs for a start and I don't believe anyone is working on one (the issue of whether or not to encode ~ should be contentious enough for a start). If we are to have support for non-ascii characters in feature names (and I think we should not, by the way), I would take the inverse approach and specify that % HEX HEX decoding and octet-by-octet comparison MUST be used in equality comparisons. This may leave some URI schemes with other types of escape mechanisms out in the cold but I don't believe that is a major concern. Koen. From owner-ietf-medfree Tue Jun 2 15:13:38 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA18319 for ietf-medfree-bks; Tue, 2 Jun 1998 15:13:38 -0700 (PDT) Received: from access2.digex.net (qlE46B5DiGQyA@access2.digex.net [205.197.245.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA18315 for ; Tue, 2 Jun 1998 15:13:37 -0700 (PDT) Received: (from asgilman@localhost) by access2.digex.net (8.8.4/8.8.4) id SAA02877; Tue, 2 Jun 1998 18:18:21 -0400 (EDT) From: Al Gilman Message-Id: <199806022218.SAA02877@access2.digex.net> Subject: Re: Issues: DATA_TYPES, STANDARD_MEASURES D To: ietf-medfree@imc.org Date: Tue, 2 Jun 1998 18:18:20 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk Since I see one set of type definition principles governing the definition of predefined data types, pre-registered units of measure, and the extension of the type system by later registrations, I am answering several of Graham's messages at once, here. The major point is what to do at this time to ensure the eventual extensibility of the registry and negotiation practice. The rest is details of specific types. Let me address the extensibility point first. In what follows, AG: is my earlier posts, GK: is Graham's latest on a given topic, and AG2: is new as of this message. -- extensibility insurance: GK: Where we seem to differ is how much of this is to be defined in the first instance. If we recognize that the registry may be extended to incorporate more complex information in future, do we need more for now. My fear is that over-specification of the initial registry may obscure its immediate value. Maybe we do need to consider (now) how the registry might be extended, without attempting to write those considerations into the specification? AG2: I don't think we differ as much as it sounds. I want the working group to convince themselves that they have a workable plan for extension and in the context of that plan see what if any hooks need to be inserted in the initial specification so that the extension can be introduced into the spec later without tearing up established practice that has grown up in the period of applicability of the initial document. GK: My vision is something like this: (1) Feature registry (for "simple-valued" features) (2) -> Algebra (3) -> [ Algebra extensions -> ] Feature set registry (4) -> [ Algebra extensions -> ] Feature value type registry That is, more complex feature values and feature value types can be defined using (1), (2) plus possible algebra extensions and added into the feature registry. By basing the registry extension mechanism on that used to perform feature set matching, the implementation load for (3) and (4) can be kept modest. AG2: I do think we are very close. My current idea of what may need to be in the registry spec is some sort of a notion that the registration datagram should be able to assert a normative reference or annex for a formal script which defines additional knowledge about the registered name. If, where you have said "feature set matching" you had said "feature set comparison" I think we would have reached an agreement in principle. I think that the result of the communication [in a negotiation] is the definition of a set of feasible options and a record of any applicable basis for preferring one of the options. The preference order on the options is better viewed as a relation across options than as a set of properties of the individual options. Some of what either party to the negotiation says will include preference order across options, or across feature values which can be deductively transferred to the options. The final order will be some sort of rollup of across-option relations expressed by the parties. That is why the "relation" structure class seems to me to be in the required schema. Now, on to the laundry list of detailed points: -- String equality: AG: >Even equality on strings requires some care in definition. GK: It may. I had assumed a simple byte-by-byte (or character-by-character) comparison. This does miss some kinds of equivalence, but I had assumed that the application would provide some level of canonicalization. AG2: I didn't mean to get creative. Just that in the i18n world there are current conventions for comparing UniCode strings and that a precise definition should be included in the feature definition framework specfication. -- feature takes URI vs. feature takes string (see also recent discussion on SOME_CHARS) AG: >It may be worth considering the role of URIs as feature values as >distinct from strings. GK: Oh! you mean URIs as *values* (not tags as I assumed above). What specific purpose is served by treating them as more than strings? AG2: Bottom-up example: case insensitivity. http: URLs are case-insensitive in some of their parts such as DNS node paths. But other parts are case-sensitive. Equality tests for http: URLs are not done right by a simple string compare, and we cannot in general assume that all participating applications have subscribed to a normal form when URL usage is unnormalized in HTTP headers. We should not assume that the registry will get people to have http: URLs which are sent from the client and URLs from the persistent data at the server to be in one canonicalization vis-a-vis case unless the URL spec already standardizes the normal form. Top-Down example: semantics. In some protocol bindings of the property dictionary, an application may be required to ensure that a URI value is a valid URI (that the name or location is valid) before transmitting a string as a URI value. -- What types are required? AG: >Are you assuming that the "number" type incorporates physical >dimensions and units and their usage? What about sets of values >drawn from the above, including ranges? GK: For now, I am not. Units are being addressed as a separate issue. But you are correct that the two do interact in fundamental ways. I belive the units case is simpler than the more general data type case. AG2: In my type theory, units are a special class of token that is part of the grammar for properties which are physical quantities, and physical quantities are handled by applying the type-definition capability of the language. This is perhaps a hangover from VHDL and MHDL. The main point is that you did not mean to exclude physical quantities from the capabilities of the registry. AG: >It might be more helpful to discuss the pros and cons of >quantities subject to tolerances as opposed to dismissing them >out of hand. GK: I did not mean to dismiss them out of hand. I would say that tolerance might be viewed as a property of a numeric value. I think this could be handled within the discussion on Units. AG2: Fine. I just wanted to know if they were in the plan somewhere. Maybe tolerances and physical measures can both be done later, but it would be best to make the solutions independent, i.e. tolerancing does not depend on the units status of the property and vice versa. My experience working on MHDL is that to do units right you need enough definitional tools so that you wind up with an extremely powerful type extension framework. Physical units include issues of tensor geometry, and physical dimensions are a good example of why a classes are worth identifying as well as types. [ dimension : scale :: class : type ] That is not to say that we may not be able to define simple syntax and compare rules that handle the immediately-necessary value expressions for values of physical measures. -- Some but not all features are just tokens. GK: from your comment below there is a possible misunderstanding I would like to clarify, and see if we really do agree: AG: >Taking "Feature values are just tokens" literally, you would get a >severe argument. But I don't think that is what you mean. GK: I really mean that feature values that are entirely represented by a token. AG2: I think we agree. But I am going to be careful, too. If what you mean is I really mean [those] feature values that are entirely represented by a token. and it is clear that some feature values have registry-normalized semantics beyond token semantics, then we have reached closure and agree. GK: The actual meaning of the token, and any values associated with it, are assumed to be implicit knowledge of many program which can process documents containing that feature. AG2: In most cases the negotiation will complete without needing to access methods beyond the token-class methods of test-for-presence and test-for-equality. You yourself have pointed out that some negotiations will involve test-for-preference-order. Even where the registry defines deeper semantics, actual negotiations may not get into that if there is a clear winner by applying just the token operations. But not all negotiations, as illustrated by the image-size vs. paper-size comparison scenario. -- Image size vs. paper size comparison scenario: GK: In another message, you refer to a similar issue regarding paper sizes (I haven't read that message in detail yet -- I'll make further comment in another response if I decide I've missed your point here.) Yes, of course, "A4" and "US-Letter" and the rest define shapes. But for a negotiation protocol processor they are still just tokens. I believe that this provides a simple generic way for document providers/carriers/users to exchange relevant information about the document while hiding details of document content from the communication protocol processor. I think this is a key goal of 'conneg'. AG2: I agree that we want to treat as tokens the tokens that handle the vast majority of cases. AG: >The A4 token is not just a token, it is a paper size. A paper size >is a planar shape. The print area required by an image is a planar >shape. I claim that the following query has standing that this group >should consider how it would be answered: "Which is the nearest >printer on the net which can print this image on one sheet of paper?" > >This requires that the application know how to compare bounding boxes >computed from image size as an integer rectangle of pixel counts and >printer resolution in pixels/length-unit and paper size expressed as >a standard-sheet token. Or simply that there is a partial ordering on the token values. (Now, the idea of a partial ordering is one that has not thus far been considered: do we need it?) AG2: Let me expand a bit. The "can you print this image on one sheet?" scenario was my attempt to show a negotiation where token operations are insufficient to close the negotiation. And partial orderings do not fill the gap in a practical sense. In this scenario an image is known in integer pixel height and width. The printing equipment is known in resolution capability, pixels per linear measure. The paper sizes are not fixed by the equipment as shipped but by the field-configurable set of installed feed trays. So the paper size repertory of a given network node depends on network management data that is relatively real-time. The network management database could even know about empty trays in a high-end scenario. The printer daemon that has to answer "yes I can print your image on one sheet" wants the registry to contain enough dimensional analysis so that it can process a resolution and image size into something that compares with a paper size. A simple or partial ordering on the tokens of paper size does not suffice because the image as scaled by resolution is not a paper size on the standard list. You don't want to reserve enough tokens for the as-printed image sizes of all possible images. You want to break this down into separate tests for "the height is enough" and "the width is enough." -- Much text about small differences. Al From owner-ietf-medfree Tue Jun 2 23:42:01 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA03061 for ietf-medfree-bks; Tue, 2 Jun 1998 23:42:01 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA03055 for ; Tue, 2 Jun 1998 23:42:00 -0700 (PDT) Received: from casablanca.parc.xerox.com ([13.2.16.111]) by alpha.xerox.com with SMTP id <53280(5)>; Tue, 2 Jun 1998 23:46:42 PDT Received: from copper-208.parc.xerox.com ([13.0.208.21]) by casablanca.parc.xerox.com with SMTP id <71816>; Tue, 2 Jun 1998 23:46:09 PDT From: "Larry Masinter" To: , Subject: RE: Issue 5: (SOME_CHARS) Date: Tue, 2 Jun 1998 23:46:08 PDT Message-ID: <000c01bd8ebb$4a0c71c0$15d0000d@copper-208.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-to: <9806021144.ZM9821@thornhill.arc.nasa.gov> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-medfree@imc.org Precedence: bulk Yes, I don't think you should ever specify any equivalence for URL-tags other than exact equality or (shudder) case insensitive matching. And certainly it shouldn't be a choice whether particular characters are encoded or not. Larry -- http://www.parc.xerox.com/masinter > Koen, > Perhaps I misunderstood Larry here, but my > assumption was that we would indicate that URIs could > include % in the allowed set, but defer the specification > on how %-encoding works to the URI groups. However that > is specified, the URIs would have an unambiguous equality > comparison as tags because the comparison would be against > the %-encoded forms. From owner-ietf-medfree Wed Jun 3 09:22:23 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA09689 for ietf-medfree-bks; Wed, 3 Jun 1998 09:22:23 -0700 (PDT) Received: from wsooti08.win.tue.nl (wsooti08.win.tue.nl [131.155.70.156]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA09685 for ; Wed, 3 Jun 1998 09:22:20 -0700 (PDT) Received: from koen@localhost by wsooti08.win.tue.nl (8.8.7) id SAA11081. Wed, 3 Jun 1998 18:26:39 +0200 (MET DST) From: koen@win.tue.nl (Koen Holtman) Message-Id: <199806031626.SAA11081@wsooti08.win.tue.nl> Subject: Re: Issue 5: (SOME_CHARS) To: masinter@parc.xerox.com (Larry Masinter) Date: Wed, 3 Jun 1998 18:26:39 +0200 (MET DST) Cc: hardie@nic.nasa.gov, ietf-medfree@imc.org In-Reply-To: <000c01bd8ebb$4a0c71c0$15d0000d@copper-208.parc.xerox.com> from "Larry Masinter" at Jun 2, 98 11:46:08 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ietf-medfree@imc.org Precedence: bulk Larry Masinter: > >Yes, I don't think you should ever specify any equivalence for >URL-tags other than exact equality or (shudder) case insensitive >matching. And certainly it shouldn't be a choice whether particular >characters are encoded or not. So you basically want to define equality comparison on tags as simple octet-by-octet? I could live with that, as long as the draft is clear enough about it. >Larry Koen. From owner-ietf-medfree Wed Jun 3 10:07:34 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA10058 for ietf-medfree-bks; Wed, 3 Jun 1998 10:07:34 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA10054 for ; Wed, 3 Jun 1998 10:07:32 -0700 (PDT) Received: (qmail 16375 invoked from network); 3 Jun 1998 17:12:08 -0000 Received: from ao093.du.pipex.com (HELO GK.Group5.co.uk) (193.130.254.93) by smtp.dial.pipex.com with SMTP; 3 Jun 1998 17:12:08 -0000 Message-Id: <3.0.32.19980603171635.007a88d0@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 03 Jun 1998 18:12:05 +0100 To: hardie@nic.nasa.gov From: Graham Klyne Subject: Re: Issue 3: (STANDARD_MEASURES) Cc: conneg WG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 11:20 02/06/98 -0700, Ted Hardie wrote: >I would like to hear a bit more about why we should default >to SI, rather than metric, in this context. Given the ease >of conversion among metric units of the same type, >limiting the metric units to just the "base" units of meters, >kg, s, doesn't seem to be a big win. There are already a number >of systems which would seem to prefer things like ppcm , >and I don't quite understand yet why we should make it less >intuitive for those users. I am not certain that there is a *system of units* called "metric". There are a number of units of measurement which are commonly described as "metric" units. SI is a consistent system of units, based on the earlier MKS system. An even earlier "metric" system of units was CGS (I don't guarantee the chronology, but I hope you get the idea). In SI, all basic units are derived consistently from the units of the basic dimensions -- the differences between SI and MKS are, I think, only apparent when one looks at values like energy and power. The reason that I favour SI as the reference system is because it does define a *consistent* system of units, therefore shouldn't spring any nasty surprises in the future. The issue of using derivatives (e.g. "mm", "cm" instead of "m") is really the same as the "cm" vs "inches" issure, but without the rounding error difficulties. I.e. if we have a mechanism to cope with metric and imperial measures, then we should certainly be able to handle integral subdivisions/multiples of the standard unit. Thus, I don't particularly advocate measuring resolution in units of "/m" (per metre) where "/cm" (per cm) is generally more meaningful. What I do very much advocate is using SI as the common point of reference for defining all the other unit values. BUT: all this assumes that we are going to provide for unit conversions. I think the real question is: do we register features with implicit units, or do we allow units to be specified as part of a feature value? If the former, conversions are not possible so the issue doesn't arise. If the latter then I think we need some point of reference (for which I favour SI). I quite like the idea of allowing units, but that does add complexity which may not add any real value. [A middle path may be to define "parallel features" that have equivalent meanings but are expressed in different units. In such cases, a conversion factor between the features would be needed. This would be simpler, but a protocol processor would need special knowledge to match the features *or* there would be a need for a feature definition mechanism that expresses such relationships to a generic processor. It's the same problem coming back at us in a slightly different form.] >I raise it in this specific context, because the text below >seems to go back to the idea of "pixels per" with a unit >assignment of meters/centimeters/inches at the time >of use. I strongly prefer a single assignment at registration, >but I'm not sure if I follow the arguments below on how >that would affect when an error condition is produced. In >particular, I don't understand when someone would >want to register something with indicating a default >unit; are there examples for us to chew on? The only concrete example we have to date is the desire to express pixel resolutions per inch *or* per cm, because of different established usage in US and Japan (I think). But we don't know if, in time, there will be other similar cases. #g ------------ Graham Klyne From owner-ietf-medfree Wed Jun 3 10:07:23 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA10052 for ietf-medfree-bks; Wed, 3 Jun 1998 10:07:23 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA10048 for ; Wed, 3 Jun 1998 10:07:22 -0700 (PDT) Received: (qmail 16392 invoked from network); 3 Jun 1998 17:12:10 -0000 Received: from ao093.du.pipex.com (HELO GK.Group5.co.uk) (193.130.254.93) by smtp.dial.pipex.com with SMTP; 3 Jun 1998 17:12:10 -0000 Message-Id: <3.0.32.19980603175950.009c41f0@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 03 Jun 1998 18:12:07 +0100 To: Al Gilman From: Graham Klyne Subject: Woods and trees Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 18:18 02/06/98 -0400, Al Gilman wrote: [...] >Much text about small differences. I think so. I think you and I both love to think about type handling systems, etc. But I think the group needs to decide: (1) do feature _values_ include units (or are the units *always* implicit)? (2) do we need a mechanism to defining ordering in token values? (3) do we need a mechanism to define alternative string comparison rules? I think a "yes" answer to any of these adds complexity to a generic protocol processor for capability matching. I fear we may lose any support for what we are developing. (The word "over-engineering" springs to mind.) I also think it is too early to tell if there is a real desire for the additional functionality that comes with a "yes" answer. So what are the consequences of "no" answers: (1) do feature values include units? NO => There is no provision for unit conversion. Generic protocol processors will have no way to know that "resolution_dpi=100" is practically the same as "resolution_dpcm=39". Is this truly a one-off special case (for the near-term future)? I think that if registrations are clear about the units to be used, future developments to allow unit values will be possible if per-feature unit defaults are part of that development. (2) do we need a mechanism to defining ordering in token values? NO => All sorts of useful comparisons might be prevented. Examples: - Papersize ("does it fit" type of comparisons) - TIFF-FX subsets (fax "modes") - Braille=(sixdot,eightdot) If we don't provide a mechanism for ordering tokens, then feature tag registrations cannot rely upon any implicit ordering of tokens. This does look like a real loss of useful functionality to me, but workarounds are possible (the most obvious being to code the token values as numbers). Again, I don't think this would preclude future developments that define ways to specify token ordering. Such a development would probably be part of a more generic (3) do we need a mechanism to define alternative string comparison rules? NO => In the short term, I don't see any great loss if string comparison is limited to simple character-by-character equality test. As for ordering comparisons, the example that springs to mind is version number strings (e.g. "x.x.x"). It might be possible to define an ordering rule that operates by tokenizing the string in some way so that digit substrings are compared as numbers rather than strings. But this would be an ad-hoc rule and might break future developments. I think my preference would be to do nothing. IN ALL CASES Later developments that introduce new constructs or constructs that previously had no interpretation could break earlier protocol processors unless some basic syntax and handling rules are laid out (and adhered to by later developments), or if the later developments are constrained to be applicable only to new protocol processors. #g ------------ Graham Klyne From owner-ietf-medfree Wed Jun 3 16:16:41 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA13047 for ietf-medfree-bks; Wed, 3 Jun 1998 16:16:41 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA13043 for ; Wed, 3 Jun 1998 16:16:40 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA11624; Wed, 3 Jun 1998 16:21:23 -0700 Date: Wed, 3 Jun 1998 16:21:23 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9806031621.ZM11622@thornhill.arc.nasa.gov> In-Reply-To: Graham Klyne "Woods and trees" (Jun 3, 6:12pm) References: <3.0.32.19980603175950.009c41f0@pop.dial.pipex.com> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: Graham Klyne , Al Gilman Subject: Re: Woods and trees Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk Graham, I've made my responses in the text below; please note that I am not speaking as working group chair here, just expressing my own preferences. regards, Ted Hardie On Jun 3, 6:12pm, Graham Klyne wrote: > Subject: Woods and trees > At 18:18 02/06/98 -0400, Al Gilman wrote: > > [...] > >Much text about small differences. > > I think so. I think you and I both love to think about type handling > systems, etc. > > But I think the group needs to decide: > > (1) do feature _values_ include units (or are the units *always* implicit)? I would prefer that the units always be implicit. I believe that negotiation within specific domains will be the most common case, and that this is made much easier with implicit units. I believe that it should be possible to register parallel feature-tags with different units, as you note below, provided that either a) the second registrant notes how to convert to the first type and the third registrant notes how to convert to one and two etc. or b) all registered entries must provide a conversion scheme into a set system, where their implicit unit is not in that system. With that in place, I believe those systems which will need to negotiate between domains with well-established (contrary) units will be able to do so. If I need to establish a planar size from the A4 token, I can refer to the registry for the sizes involved, and if I do it a lot, I should have the conversions built in. > (2) do we need a mechanism to defining ordering in token values? I think there are really two questions here: a) Do we need to allow registrants to define how tokens are ordered? b) Do we need to provide a mechanism that allows negotiators to indicate token orderings? I would say yes to a. If a registrant wishes to register Kif Mode Z as a superset of Kif Mode W, that should be possible. I am inclined to say that the only mechanism we should provide for b) is a preference mechanism. So someone should be able to say: I prefer Kif Mode W to Kif Mode Z, despite the fact that Z is a superset of W and the fact that I *can* do Z. They should not be able toredefine Kif Mode W as a superset of Kif Mode Z. > (3) do we need a mechanism to define alternative string comparison rules? This has a big, blinking "not our job" sign on it to me. I believe that a character-by-character equality test does what we need it to do for right now. > > I think a "yes" answer to any of these adds complexity to a generic > protocol processor for capability matching. I fear we may lose any support > for what we are developing. (The word "over-engineering" springs to mind.) > > I also think it is too early to tell if there is a real desire for the > additional functionality that comes with a "yes" answer. > > So what are the consequences of "no" answers: > > (1) do feature values include units? > > NO => > > There is no provision for unit conversion. Generic protocol processors > will have no way to know that "resolution_dpi=100" is practically the same > as "resolution_dpcm=39". Is this truly a one-off special case (for the > near-term future)? > > I think that if registrations are clear about the units to be used, future > developments to allow unit values will be possible if per-feature unit > defaults are part of that development. > > (2) do we need a mechanism to defining ordering in token values? > > NO => > > All sorts of useful comparisons might be prevented. Examples: > - Papersize ("does it fit" type of comparisons) > - TIFF-FX subsets (fax "modes") > - Braille=(sixdot,eightdot) > > If we don't provide a mechanism for ordering tokens, then feature tag > registrations cannot rely upon any implicit ordering of tokens. This does > look like a real loss of useful functionality to me, but workarounds are > possible (the most obvious being to code the token values as numbers). > > Again, I don't think this would preclude future developments that define > ways to specify token ordering. Such a development would probably be part > of a more generic > > (3) do we need a mechanism to define alternative string comparison rules? > > NO => > > In the short term, I don't see any great loss if string comparison is > limited to simple character-by-character equality test. > > As for ordering comparisons, the example that springs to mind is version > number strings (e.g. "x.x.x"). It might be possible to define an ordering > rule that operates by tokenizing the string in some way so that digit > substrings are compared as numbers rather than strings. But this would be > an ad-hoc rule and might break future developments. I think my preference > would be to do nothing. > > > IN ALL CASES > > Later developments that introduce new constructs or constructs that > previously had no interpretation could break earlier protocol processors > unless some basic syntax and handling rules are laid out (and adhered to by > later developments), or if the later developments are constrained to be > applicable only to new protocol processors. > > #g > > > ------------ > Graham Klyne >-- End of excerpt from Graham Klyne From owner-ietf-medfree Wed Jun 3 16:22:12 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA13076 for ietf-medfree-bks; Wed, 3 Jun 1998 16:22:12 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA13072 for ; Wed, 3 Jun 1998 16:22:12 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA11632; Wed, 3 Jun 1998 16:27:01 -0700 Date: Wed, 3 Jun 1998 16:27:01 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9806031627.ZM11630@thornhill.arc.nasa.gov> In-Reply-To: Graham Klyne "Re: Issue 3: (STANDARD_MEASURES)" (Jun 3, 6:12pm) References: <3.0.32.19980603171635.007a88d0@pop.dial.pipex.com> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: Graham Klyne , hardie@nic.nasa.gov Subject: Re: Issue 3: (STANDARD_MEASURES) Cc: conneg WG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk > I am not certain that there is a *system of units* called "metric". There > are a number of units of measurement which are commonly described as > "metric" units. I suspect this is a definition by opposition thing for Americans. It's easy for me to identify "metric" units, because they are the ones we don't use, if you see what I mean. Provided a registrant can come in and say something like "My feature tag's name is ppcm, and it is measured in centimeters, which are hundredths of the SI base unit meter", I'm fine. I just don't want to say you have to define the unit as "ppm", just to keep to SI units. There are rounding issues here as well, but you are right that they are very much the same as those in the conversion from Imperial to metric (er, SI) units. > > SI is a consistent system of units, based on the earlier MKS system. An > even earlier "metric" system of units was CGS (I don't guarantee the > chronology, but I hope you get the idea). In SI, all basic units are > derived consistently from the units of the basic dimensions -- the > differences between SI and MKS are, I think, only apparent when one looks > at values like energy and power. > > The reason that I favour SI as the reference system is because it does > define a *consistent* system of units, therefore shouldn't spring any nasty > surprises in the future. > > The issue of using derivatives (e.g. "mm", "cm" instead of "m") is really > the same as the "cm" vs "inches" issure, but without the rounding error > difficulties. I.e. if we have a mechanism to cope with metric and imperial > measures, then we should certainly be able to handle integral > subdivisions/multiples of the standard unit. > > Thus, I don't particularly advocate measuring resolution in units of "/m" > (per metre) where "/cm" (per cm) is generally more meaningful. What I do > very much advocate is using SI as the common point of reference for > defining all the other unit values. > > > BUT: all this assumes that we are going to provide for unit conversions. I > think the real question is: do we register features with implicit units, > or do we allow units to be specified as part of a feature value? If the > former, conversions are not possible so the issue doesn't arise. If the > latter then I think we need some point of reference (for which I favour SI). > > I quite like the idea of allowing units, but that does add complexity which > may not add any real value. > > [A middle path may be to define "parallel features" that have equivalent > meanings but are expressed in different units. In such cases, a conversion > factor between the features would be needed. This would be simpler, but a > protocol processor would need special knowledge to match the features *or* > there would be a need for a feature definition mechanism that expresses > such relationships to a generic processor. It's the same problem coming > back at us in a slightly different form.] > > >I raise it in this specific context, because the text below > >seems to go back to the idea of "pixels per" with a unit > >assignment of meters/centimeters/inches at the time > >of use. I strongly prefer a single assignment at registration, > >but I'm not sure if I follow the arguments below on how > >that would affect when an error condition is produced. In > >particular, I don't understand when someone would > >want to register something with indicating a default > >unit; are there examples for us to chew on? > > The only concrete example we have to date is the desire to express pixel > resolutions per inch *or* per cm, because of different established usage in > US and Japan (I think). But we don't know if, in time, there will be other > similar cases. > > #g > > ------------ > Graham Klyne >-- End of excerpt from Graham Klyne From owner-ietf-medfree Wed Jun 3 17:57:57 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA13540 for ietf-medfree-bks; Wed, 3 Jun 1998 17:57:57 -0700 (PDT) Received: from mail.hg-prt.co.jp (departure.hg-prt.co.jp [210.129.185.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA13536 for ; Wed, 3 Jun 1998 17:57:55 -0700 (PDT) Received: from default (1Cust17.tnt1.malibu.ca.da.uu.net [208.254.22.17]) by mail.hg-prt.co.jp (8.8.5/3.4W4-9802271028) with SMTP id JAA10797; Thu, 4 Jun 1998 09:57:30 +0900 (JST) Date: Thu, 4 Jun 1998 09:57:30 +0900 (JST) From: t77121 To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Thursday, July 9th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Tuesday, July 7th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Sunday, July 5th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Saturday, July 4th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Friday, July 10th, 1998 Reply-To: t77121@sprint.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is Subject: t77 1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Thu Jun 4 17:23:22 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA07787 for ietf-medfree-bks; Thu, 4 Jun 1998 17:23:22 -0700 (PDT) Received: from www.arquired.es (WWW.arquired.es [194.179.41.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA07783 for ; Thu, 4 Jun 1998 17:23:21 -0700 (PDT) Date: Thu, 4 Jun 1998 17:23:21 -0700 (PDT) Received: from [208.254.22.82] by www.arquired.es (NTMail 3.03.0017/1.abcl) with ESMTP id da394163 for ; Fri, 5 Jun 1998 02:27:22 +0200 From: 9y9y4l <9y9y4l@mci.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Saturday, July 11th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Thursday, July 9th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Tuesday, July 7th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Monday, July 6th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Sunday, July 12th, 1998 Reply-To: 9y9y4l@mci.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <9y9y4l@mci.com> Subject: 9 y Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Fri, 5 Jun 1998 02:27:19 +0200 EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-427-5820 CALL FOR MORE INFORMATION 213-427-5820 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-427-5820 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Fri Jun 5 17:21:18 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA02746 for ietf-medfree-bks; Fri, 5 Jun 1998 17:21:18 -0700 (PDT) Received: from ns1.php.co.jp (ns1.php.co.jp [203.180.111.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA02718; Fri, 5 Jun 1998 17:20:25 -0700 (PDT) Date: Fri, 5 Jun 1998 17:20:25 -0700 (PDT) Received: from default ([208.254.22.221]) by ns1.php.co.jp (post.office MTA v1.9.3 ID# 0100111-34051) with SMTP id ABB58; Sat, 6 Jun 1998 09:29:41 +0900 From: z55821 To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Sunday, July 12th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Friday, July 10th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Wednesday, July 8th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Tuesday, July 7th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Monday, July 13th, 1998 Reply-To: z55821@sprint.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is Subject: z5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-427-5820 CALL FOR MORE INFORMATION 213-427-5820 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-427-5820 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Sat Jun 6 07:08:11 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22983 for ietf-medfree-bks; Sat, 6 Jun 1998 07:08:11 -0700 (PDT) Received: from mx1.landsraad.net (chusuk.arrakis.es [195.5.65.35]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22977 for ; Sat, 6 Jun 1998 07:05:33 -0700 (PDT) Received: from 10.0.1.1.inf (ig-191.arrakis.es [195.5.76.191]) by mx1.landsraad.net (8.8.6/8.7.3) with SMTP id QAA26418 for ietf-medfree@imc.org; Sat, 6 Jun 1998 16:07:06 +0200 (MET DST) Date: Sat, 6 Jun 1998 16:07:06 +0200 (MET DST) From: magickey To: ietf-medfree@imc.org Subject: ELECTRONICS ILLUSIONS FOR MAGICIANS Message-Id: Content-Type: TEXT/PLAIN charset=US-ASCII Sender: owner-ietf-medfree@imc.org Precedence: bulk 06 de junio de 1998 Dear : This letter is to present you my new catalogue, videocatalogue (VHS PAL videocassette) AND WEB http://www.arrakis.es/~eduher/export.htm of electronic equipment for magicians. I am looking forward to hearing from you with any questions you have. Yours faithfully Eduardo Hernando de Linán Director of La Llave Magica l Página 2 06 de junio de 1998 From owner-ietf-medfree Sat Jun 6 22:24:32 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA25698 for ietf-medfree-bks; Sat, 6 Jun 1998 22:24:32 -0700 (PDT) Received: from ssrc.hku.hk (ftp.ssrc.hku.hk [147.8.208.250]) by mail.proper.com (8.8.8/8.8.5) with SMTP id WAA25627; Sat, 6 Jun 1998 22:10:39 -0700 (PDT) Received: from [208.255.132.243] (HELO jj3dw3.q3q3665f.com) by ssrc.hku.hk (Stalker SMTP Server 1.6) with SMTP id S.0000019440; Sun, 07 Jun 1998 13:21:01 +0800 From: dh85338 To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Wednesday, April 15th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Monday, April 13th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Saturday, April 11th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Friday, April 10th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Thursday, April 16th, 1998 Reply-To: dh85338@att.net Date: Sun, 07 Jun 1998 13:21:07 +0800 Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is Subject: d h Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-969-4930 CALL FOR MORE INFORMATION 213-969-4930 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-969-4930 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Sun Jun 7 01:54:36 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA09816 for ietf-medfree-bks; Sun, 7 Jun 1998 01:54:36 -0700 (PDT) Received: from sever.mx1 (ppp-206-170-1-37.snfc21.pacbell.net [206.170.1.37]) by mail.proper.com (8.8.8/8.8.5) with SMTP id BAA09806 for ; Sun, 7 Jun 1998 01:54:28 -0700 (PDT) From: rsvpfr@highpro.com Message-Id: <199806070854.BAA09806@mail.proper.com> Date: Sun, 7 Jun 1998 01:53:21 To: Subject: The MasterKey For Your Financial Independence!!! Sender: owner-ietf-medfree@imc.org Precedence: bulk Hi, I wanted to tell you that a group of "self-made millionaires" are now willing to share the most amazing secret in the world to a few qualified individuals. It's the 'MasterKey" Now you can learn to expand your internal belief system to achieve the mind-set necessary to become a SELF-MADE MILLIONAIRE! The secret includes an incredible, never before thought of, marketing plan. All you have to do is listen and then give out a simple phone number. Follow this plan implicitly and religiously and YOU CAN EARN $1,426,180 over the next 12 months! Just take a few minutes to call it could change your life! SIncerely Rodger 1-800-322-6169 ext. 6281 24 hours Message center. P.S This is not a get-rich-quick scheme or a Multi-level. The rewards are a lifetime of the better things in life for you and your family while helping others to do the same. THIS MESSAGE WILL NOT BE SENT TO YOU AGAIN FROM THIS SOURCE. From owner-ietf-medfree Sun Jun 7 08:50:31 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA12777 for ietf-medfree-bks; Sun, 7 Jun 1998 08:50:31 -0700 (PDT) Received: from mx1.landsraad.net (chusuk.arrakis.es [195.5.65.35]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA12773 for ; Sun, 7 Jun 1998 08:50:27 -0700 (PDT) Received: from 10.0.1.1.inf (ig-32.arrakis.es [195.5.76.32]) by mx1.landsraad.net (8.8.6/8.7.3) with SMTP id RAA29210 for ietf-medfree@imc.org; Sun, 7 Jun 1998 17:53:29 +0200 (MET DST) Date: Sun, 7 Jun 1998 17:53:29 +0200 (MET DST) From: magickey To: ietf-medfree@imc.org Subject: HIGH TECH ILLUSIONS FOR MAGICIANS Message-Id: Content-Type: TEXT/PLAIN charset=US-ASCII Sender: owner-ietf-medfree@imc.org Precedence: bulk 07 de junio de 1998 Dear sir or madam, This letter is to present you my new catalogue, videocatalogue (VHS PAL videocassette) AND WEB http://www.arrakis.es/~eduher/export.htm of electronic equipment for magicians. I am looking forward to hearing from you with any questions you have. Yours faithfully Eduardo Hernando de Linán Director of La Llave Magica From owner-ietf-medfree Sun Jun 7 19:30:06 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA15074 for ietf-medfree-bks; Sun, 7 Jun 1998 19:30:06 -0700 (PDT) Received: from rexsw.rexsoft.co.kr (www.rexsoft.co.kr [210.112.57.123]) by mail.proper.com (8.8.8/8.8.5) with SMTP id TAA15061; Sun, 7 Jun 1998 19:29:44 -0700 (PDT) Date: Sun, 7 Jun 1998 19:29:44 -0700 (PDT) Received: from default (208.254.22.39) by rexsw.rexsoft.co.kr (EMWAC SMTPRS 0.81) with SMTP id ; Mon, 08 Jun 1998 11:38:32 +0900 From: 01q4d1 <01q4d1@att.net> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Thursday, May 7th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Tuesday, May 5th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Sunday, May 3rd, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Saturday, May 2nd, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Friday, May 8th, 1998 Reply-To: 01q4d1@att.net Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <01q4d1@att.net> Subject: 01 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-427-5820 CALL FOR MORE INFORMATION 213-427-5820 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-427-5820 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Mon Jun 8 11:35:15 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA05852 for ietf-medfree-bks; Mon, 8 Jun 1998 11:35:15 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA05848 for ; Mon, 8 Jun 1998 11:35:13 -0700 (PDT) Received: (qmail 19065 invoked from network); 8 Jun 1998 18:40:22 -0000 Received: from am157.du.pipex.com (HELO GK.Group5.co.uk) (193.130.252.157) by smtp.dial.pipex.com with SMTP; 8 Jun 1998 18:40:22 -0000 Message-Id: <3.0.32.19980608184746.007bb7e0@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 08 Jun 1998 19:40:18 +0100 To: hardie@nic.nasa.gov From: Graham Klyne Subject: Re: Woods and trees Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 16:21 03/06/98 -0700, Ted Hardie wrote: > I've made my responses in the text below; Ted, I think you have identified the minimum needed for onward progress, and as such that would seem to present a good initial goal to chase. I have a few comments below... >> (1) do feature _values_ include units (or are the units *always* implicit)? > >I would prefer that the units always be implicit. I believe that negotiation >within specific domains will be the most common case, and that this >is made much easier with implicit units. I believe that it should be possible >to register parallel feature-tags with different units, as you note below, >provided that either > >a) the second registrant notes how to convert to the >first type and the third registrant notes how to convert to one and two etc. > >or > >b) all registered entries must provide a conversion scheme into a set >system, where their implicit unit is not in that system. I would argue that conversion *to SI units* should be described (where appropriate) as part of the feature registration, so that individual registrations can stand independently, or any pair of registrations are independent of a third. (In this context, SI does not necessarily mean dots-per-metre, etc., as other measures are still legitimate. But the base units for all measures should be SI -- in the sense, for example, that a metre is the base unit for centimetres, etc. My reason for this preference is to avoid possible surprises if more exotic measures such as energy or power are ever used.) >With that in place, I believe those systems which will need to negotiate >between domains with well-established (contrary) units will be able >to do so. If I need to establish a planar size from the A4 token, I can >refer to the registry for the sizes involved, and if I do it a lot, I should >have the conversions built in. This is the kind of scenario where having some established reference units may be useful, I think. NOTE: I am agreeing with you about implicit units. I am just arguing for registry specifications to specify relationship to SI to ease conversion between parallel registrations. I'll even offer some text: "If the value specified by a feature registration represents some kind of physical quantity (e.g. length, resolution, speed, mass, etc.) then the registration should define a unit to be used for the feature, and also define a conversion between the that unit and a one based on the SI system of coherent units. For example a feature that measures distance in inches should indicate a conversion of, say, 25.4mm per inch. (SI units are metre, kilogram, second, radians, newton, joule, watt, etc.) Tokens which are used to represent specific physical measures (e.g. paper size) should be accompanied by their normal definition, and also a definition or conversion factors for measurements based on SI units. NOTE: it is intended that parallel registrations will be used where required for the same measure represented in different units, as in dots per inch and dots per centimetre. Specifying a conversion to SI units provides a basis for consistent conversion between any pair of such registrations, and provides values that should be used by protocol processors that perform such conversions" [[Question: should we list some common conversion factors; e.g. 25.4 mm = 1 inch 39.4 dpcm = 100 dpi etc. The idea is to encourage consistent use for common units.]] >> (2) do we need a mechanism to defining ordering in token values? > >I think there are really two questions here: a) Do we need to allow >registrants to define how tokens are ordered? b) Do we need to provide >a mechanism that allows negotiators to indicate token orderings? > >I would say yes to a. If a registrant wishes to register Kif Mode Z as >a superset of Kif Mode W, that should be possible. No argument there, as long as we are aware that not all implementations may be aware of the ordering. Hence we need to define the outcome if '<' or '>' is applied when the ordering relationship is unknown. [[Proposal: allow also that a feature may be partially ordered; i.e. an ordering relation is applicable bewteen some but not all pairs of values. A relation 'a < b' or 'b > a' is true iff the ordering is defined and a precedes b. Then, if the ordering relationship is unknown, there is no ordering between any pair of values and '<' and '>' always return false. I think this is an -algebra- issue rather than a -reg- issue.]] > ... I am inclined to >say that the only mechanism we should provide for b) is a preference >mechanism. So someone should be able to say: I prefer Kif Mode W >to Kif Mode Z, despite the fact that Z is a superset of W and the >fact that I *can* do Z. They should not be able toredefine Kif Mode W >as a superset of Kif Mode Z. This is probably the Right Way in many cases. Thinking of the -algebra- draft, does this mean that the use of q-factors should be able to define '<' and '>' comparisons? This is structly a type violation, and I suspect that it may turn out to cause more problems than it solves, and would prefer to keep preferences separate from comparisons. >> (3) do we need a mechanism to define alternative string comparison rules? > >This has a big, blinking "not our job" sign on it to me. I believe that >a character-by-character equality test does what we need it to >do for right now. I tend to agree. Do your comments about token ordering extend to string ordering (i.e. can be defined in registrations, but non-aware protocol processors may not be able to use them?). That way would seem consistent to me. >> I think a "yes" answer to any of these adds complexity to a generic >> protocol processor for capability matching. I fear we may lose any support >> for what we are developing. (The word "over-engineering" springs to mind.) >From your response, I guess you agree :-) If all agree that this is a reasonable approach (upon which further developments can be built later, if required) I think I have enough information (if not yet time ;-) to further develop the -algebra- draft. How are we doing on your issue list? #g ------------ Graham Klyne From owner-ietf-medfree Mon Jun 8 17:08:26 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA08273 for ietf-medfree-bks; Mon, 8 Jun 1998 17:08:26 -0700 (PDT) Received: from kef-gw.kankeiren.or.jp (kef-gw.kanreiren.or.jp [203.140.195.2] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA08263; Mon, 8 Jun 1998 17:08:16 -0700 (PDT) Received: by kef-gw.kankeiren.or.jp (1.0 (Berkeley 8.7) Build 341/3.3W-12/09/96) id JAA00214; Tue, 09 Jun 1998 09:04:50 -0700 Date: Tue, 09 Jun 1998 09:04:50 -0700 Received: from 1cust188.tnt21.lax3.da.uu.net(208.255.123.188) by kef-gw via smap id xma356af5bf; Tue, 09 Jun 98 08:54:07 -0700 From: 4a3te6t <4a3te6t@sprint.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Tuesday, April 21st, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Sunday, April 19th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Friday, April 17th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Thursday, April 16th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Wednesday, April 22nd, 1998 Reply-To: 4a3te6t@sprint.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <4a3te6t@sprint.com> Subject: 4a Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-969-4930 CALL FOR MORE INFORMATION 213-969-4930 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-969-4930 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Mon Jun 8 17:46:08 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA08518 for ietf-medfree-bks; Mon, 8 Jun 1998 17:46:08 -0700 (PDT) Received: from bsa2.athena.auth.gr (bsa2.athena.auth.gr [155.207.7.3]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA08507; Mon, 8 Jun 1998 17:45:34 -0700 (PDT) Received: from 1Cust69.tnt1.malibu.ca.da.uu.net by bsa2.athena.auth.gr with SMTP id AA03212; Tue, 9 Jun 1998 03:32:02 +0300 Date: Tue, 9 Jun 1998 03:32:02 +0300 From: 9xrf35t <9xrf35t@mci.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Friday, May 8th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Wednesday, May 6th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Monday, May 4th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Sunday, May 3rd, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Saturday, May 9th, 1998 Reply-To: 9xrf35t@mci.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <9xrf35t@mci.com> Subject: 9r Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: 7 Email address lists export in many different formats (HTML, Comma delimited, text file) 7 Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom 7 Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-427-5820 CALL FOR MORE INFORMATION 213-427-5820 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-427-5820 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Tue Jun 9 00:31:04 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA16996 for ietf-medfree-bks; Tue, 9 Jun 1998 00:31:04 -0700 (PDT) Received: from gate1.pcfax.com (gate3.pcfax.com [194.70.160.131]) by mail.proper.com (8.8.8/8.8.5) with SMTP id AAA16977 for ; Tue, 9 Jun 1998 00:30:59 -0700 (PDT) Received: from [194.70.160.50] by gate1.pcfax.com (NTMail 3.03.0017/1.ajos) with ESMTP id va021445 for ; Tue, 9 Jun 1998 08:38:14 +0100 Message-Id: <3.0.32.19980609082846.006ccb4c@mail.pcfax.com> X-Sender: mike@mail.pcfax.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 09 Jun 1998 08:36:49 +0100 To: ietf-medfree@imc.org From: Mike Lake Subject: Unsolicited Emails Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk Am I the only one getting a higher number of junk Emails than matters of substance from this reflector? The person who claims "Email advertising works" should be told - "only in annoying people!" How does one stop this sort of thing? Best regards Mike Lake Chairman/CEO Wordcraft International Business: http://www.wordcraft.co.uk Personal: http://www.homepages.pcfax.com/mlake From owner-ietf-medfree Tue Jun 9 10:50:04 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA29845 for ietf-medfree-bks; Tue, 9 Jun 1998 10:50:04 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA29841 for ; Tue, 9 Jun 1998 10:50:02 -0700 (PDT) Received: (qmail 1245 invoked from network); 9 Jun 1998 17:55:21 -0000 Received: from unknown (HELO GK.Group5.co.uk) (193.128.238.237) by smtp.dial.pipex.com with SMTP; 9 Jun 1998 17:55:21 -0000 Message-Id: <3.0.32.19980609092117.0086dbd0@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 09 Jun 1998 18:55:16 +0100 To: Mike Lake From: Graham Klyne Subject: Re: Unsolicited Emails Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk It's not just you :-( Unfortunately, as I understand it, the best thing to do is ignore them. I have a filter on my e-mail reader which automatically diverts those emails to the junk box. I hear that trying to talk to those people only encourages them. (Remember the old Inmac catalogue deluge in UK several years ago?) I'm intrigued why conneg seems to have a much higher spam rate than other mailing lists. #g At 08:36 09/06/98 +0100, Mike Lake wrote: >Am I the only one getting a higher number of junk Emails than matters of >substance from this reflector? The person who claims "Email advertising >works" should be told - "only in annoying people!" How does one stop this >sort of thing? > >Best regards > >Mike Lake >Chairman/CEO Wordcraft International >Business: http://www.wordcraft.co.uk >Personal: http://www.homepages.pcfax.com/mlake > ------------ Graham Klyne From owner-ietf-medfree Tue Jun 9 19:00:43 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA02675 for ietf-medfree-bks; Tue, 9 Jun 1998 19:00:43 -0700 (PDT) Received: from orange.ne.jp (u00070.orange.ne.jp [210.164.160.70]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA02671 for ; Tue, 9 Jun 1998 19:00:41 -0700 (PDT) Received: from jj3dw3.q3q3665f.com (1Cust66.tnt4.lax3.da.uu.net [153.37.64.66]) by orange.ne.jp (8.7.5+2.6Wbeta7/3.5Wbeta) with SMTP id KAA04438; Wed, 10 Jun 1998 10:58:57 +0900 (JST) Date: Wed, 10 Jun 1998 10:58:57 +0900 (JST) From: 77atsyh <77atsyh@sprint.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Wednesday, April 22nd, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Monday, April 20th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Saturday, April 18th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Friday, April 17th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Thursday, April 23rd, 1998 Reply-To: 77atsyh@sprint.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <77atsyh@sprint.com> Subject: 77 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-969-4930 CALL FOR MORE INFORMATION 213-969-4930 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-969-4930 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Wed Jun 10 11:18:56 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA25371 for ietf-medfree-bks; Wed, 10 Jun 1998 11:18:56 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA25367 for ; Wed, 10 Jun 1998 11:18:55 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA19907 for ietf-medfree@imc.org; Wed, 10 Jun 1998 11:24:08 -0700 Date: Wed, 10 Jun 1998 11:24:08 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9806101124.ZM19905@thornhill.arc.nasa.gov> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: ietf-medfree@imc.org Subject: Scheduling for Chicago Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk The scheduling for working groups for the next IETF has begun. I'd like to avoid scheduling CONNEG against any of the other groups interested in its work. The following is my current list; please send additions as soon as possible. HTTP-EXT IETF-FAX IPP URL-REG WEBDAV DASL regards, Ted Hardie NASA NIC From owner-ietf-medfree Wed Jun 10 16:33:24 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA28064 for ietf-medfree-bks; Wed, 10 Jun 1998 16:33:24 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA28060 for ; Wed, 10 Jun 1998 16:33:22 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA20395; Wed, 10 Jun 1998 16:38:39 -0700 Date: Wed, 10 Jun 1998 16:38:39 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9806101638.ZM20393@thornhill.arc.nasa.gov> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: ietf-medfree@imc.org Subject: Issues list Cc: hardie@nic.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk Below is an update of the issues list. I believe we are at consensus on all the major issues. There are some resolutions which require changes to the draft (either editorial or substantive). Once we have seen the draft with these changes, I plan to last call it. My aim is to have this last called within the working group in time to have it go into IETF last call before Chicago. Please send any comments on the issues to list as quickly as you can. regards, Ted Hardie NASA NIC 1) IANA_CONSIDERATIONS The URI tree will require no review and falls into the IANA consideration's category "private use". The Global tree will be "Designated Expert" with a mailing list to advise. The IETF tree will "IESG approval". 2) (ASN1) ASN.1 identifiers will not be required for registration, but a place to list them will be provided and the IANA will assign one from its delegated space on request. 3) (STANDARD_MEASURES) All registrations will include units. SI units are preferred and any unit not in the SI system must be associated with the appropriate conversion to an SI unit. Rounding conventions must be established for use in contexts where only whole integers are allowed. 4) (RAT_HOLE) The current language will be retained. 5) (SOME_CHARS) "%" will be added to the list of allowed chars, but the allowed group will remain a subgroup of the full uri syntax. 6) (TERMINOLOGY_FIX) Editorial. The draft should avoid synonyms for feature tag and feature collection, as they may introduce ambiguity. 7) (DATA_TYPES) The following data types will be primitive to the registry: - numbers: integer and rational - tokens, with equality relarionship - strings, with equality relationship - strings, with defined comparison (case insensitive, unicode) - ordered tokens For both ordered token and defined-comparison strings, the registration must include the information needed to compare (the order or the defintion of string comparison, as appropriate). From owner-ietf-medfree Wed Jun 10 18:15:00 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA28695 for ietf-medfree-bks; Wed, 10 Jun 1998 18:15:00 -0700 (PDT) Received: from svgproxy1.elfep.no (mail.elfep.no [194.19.127.35]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA28600; Wed, 10 Jun 1998 18:03:09 -0700 (PDT) Date: Wed, 10 Jun 1998 18:03:09 -0700 (PDT) Received: from jj3dw3.q3q3665f.com (unverified [208.196.122.130]) by svgproxy1.elfep.no (Integralis SMTPRS 2.04) with SMTP id ; Thu, 11 Jun 1998 03:01:48 +0200 From: 3rstyhd <3rstyhd@ix.netcom.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Thursday, April 23rd, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Tuesday, April 21st, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Sunday, April 19th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Saturday, April 18th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Friday, April 24th, 1998 Reply-To: 3rstyhd@ix.netcom.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <3rstyhd@ix.netcom.com> Subject: 3 g MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-969-4930 CALL FOR MORE INFORMATION 213-969-4930 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-969-4930 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Wed Jun 10 19:53:16 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA29356 for ietf-medfree-bks; Wed, 10 Jun 1998 19:53:16 -0700 (PDT) Received: from iaf.es ([194.179.110.20]) by mail.proper.com (8.8.8/8.8.5) with SMTP id TAA29317; Wed, 10 Jun 1998 19:51:38 -0700 (PDT) Date: Wed, 10 Jun 1998 19:51:38 -0700 (PDT) Received: from jj3dw3.q3q3665f.com by iaf.es (Lotus SMTP MTA v1.06 (346.8 3-18-1997)) with SMTP id C1256620.001028A9; Thu, 11 Jun 1998 04:57:13 +0200 From: 4n6n61 <4n6n61@sprint.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Thursday, April 23rd, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Tuesday, April 21st, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Sunday, April 19th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Saturday, April 18th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Friday, April 24th, 1998 Reply-To: 4n6n61@sprint.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <4n6n61@sprint.com> Subject: 44 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-969-4930 CALL FOR MORE INFORMATION 213-969-4930 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-969-4930 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Thu Jun 11 02:15:32 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA15626 for ietf-medfree-bks; Thu, 11 Jun 1998 02:15:32 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id CAA15618 for ; Thu, 11 Jun 1998 02:15:30 -0700 (PDT) Received: (qmail 5553 invoked from network); 11 Jun 1998 09:20:52 -0000 Received: from userb745.uk.uudial.com (HELO GK.Group5.co.uk) (193.149.83.220) by smtp.dial.pipex.com with SMTP; 11 Jun 1998 09:20:52 -0000 Message-Id: <3.0.32.19980611092439.009b95c0@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 11 Jun 1998 10:20:47 +0100 To: hardie@nic.nasa.gov From: Graham Klyne Subject: Re: Issues list Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 16:38 10/06/98 -0700, Ted Hardie wrote: >Below is an update of the issues list. I believe we are at consensus >on all the major issues. There are some resolutions which require >changes to the draft (either editorial or substantive). Once we have >seen the draft with these changes, I plan to last call it. My aim is >to have this last called within the working group in time to have it >go into IETF last call before Chicago. Please send any comments >on the issues to list as quickly as you can. > regards, > Ted Hardie > NASA NIC > > >1) IANA_CONSIDERATIONS > >The URI tree will require no review and falls into the IANA >consideration's category "private use". The Global tree will be >"Designated Expert" with a mailing list to advise. The IETF tree will >"IESG approval". OK by me. >2) (ASN1) > >ASN.1 identifiers will not be required for registration, but a place >to list them will be provided and the IANA will assign one from its >delegated space on request. OK by me. >3) (STANDARD_MEASURES) > >All registrations will include units. SI units are preferred and any >unit not in the SI system must be associated with the appropriate >conversion to an SI unit. Rounding conventions must be established >for use in contexts where only whole integers are allowed. OK by me. >4) (RAT_HOLE) > >The current language will be retained. OK by me. (As I recall, current language says "not appropriate for..." but does not absolutely prohibit "social" features, etc.) >5) (SOME_CHARS) > >"%" will be added to the list of allowed chars, but the allowed group >will remain a subgroup of the full uri syntax. OK by me. >6) (TERMINOLOGY_FIX) > >Editorial. The draft should avoid synonyms for feature tag and >feature collection, as they may introduce ambiguity. Should there be a master glossary anywhere for this work? If so, where? I believe the charter has that we shall move the -requirements- draft, which contains glossary, to informational. Are we actually agreed on terminology? Would glossary referral from -reg- count as normative? >7) (DATA_TYPES) > >The following data types will be primitive to the registry: > > >- numbers: integer and rational >- tokens, with equality relarionship >- strings, with equality relationship >- strings, with defined comparison (case insensitive, unicode) >- ordered tokens > >For both ordered token and defined-comparison strings, the >registration must include the information needed to compare >(the order or the defintion of string comparison, as appropriate). I would add a note that not all protocol processors should be expected to know about registry-defined ordering rules. There is also the issue of what results should be expected in those circumstances. (My proposal is that it's treated as a (very) partial ordering and 'false' is returned for '<' or '>' if no ordering rule is known.) Now, I realize I may be confusing -reg- and -algebra-... I think some reference needs to be made in -reg-, but the behavioural detail belongs in -algebra-. ? #g ------------ Graham Klyne From owner-ietf-medfree Thu Jun 11 02:15:34 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA15627 for ietf-medfree-bks; Thu, 11 Jun 1998 02:15:34 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id CAA15619 for ; Thu, 11 Jun 1998 02:15:30 -0700 (PDT) Received: (qmail 5544 invoked from network); 11 Jun 1998 09:20:50 -0000 Received: from userb745.uk.uudial.com (HELO GK.Group5.co.uk) (193.149.83.220) by smtp.dial.pipex.com with SMTP; 11 Jun 1998 09:20:50 -0000 Message-Id: <3.0.32.19980611091240.008cb100@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 11 Jun 1998 10:20:44 +0100 To: hardie@nic.nasa.gov From: Graham Klyne Subject: Re: Scheduling for Chicago Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 11:24 10/06/98 -0700, Ted Hardie wrote: >The scheduling for working groups for the next IETF has >begun. I'd like to avoid scheduling CONNEG against any >of the other groups interested in its work. The following >is my current list; please send additions as soon as >possible. > >HTTP-EXT >IETF-FAX >IPP >URL-REG >WEBDAV >DASL > I hear rumour there may be a message-tracking BOF. (msgtrk?) Anything e-mail related would be good to avoid, if possible. #g ------------ Graham Klyne From owner-ietf-medfree Thu Jun 11 14:00:44 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA22748 for ietf-medfree-bks; Thu, 11 Jun 1998 14:00:44 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA22744 for ; Thu, 11 Jun 1998 14:00:41 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA21511; Thu, 11 Jun 1998 14:06:04 -0700 Date: Thu, 11 Jun 1998 14:06:04 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9806111406.ZM21509@thornhill.arc.nasa.gov> In-Reply-To: Graham Klyne "Re: Scheduling for Chicago" (Jun 11, 10:20am) References: <3.0.32.19980611091240.008cb100@pop.dial.pipex.com> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: Graham Klyne Subject: Re: Scheduling for Chicago Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk > I hear rumour there may be a message-tracking BOF. (msgtrk?) > > Anything e-mail related would be good to avoid, if possible. > I've not been able to find anything about a message-tracking BOF on the current lists sent by the Secretariat's agenda manager. The BOF may still be in the pipeline; if so, we will need to ask them not to schedule against us, rather than asking not schedule against them. regards, Ted From owner-ietf-medfree Fri Jun 12 18:26:20 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA19127 for ietf-medfree-bks; Fri, 12 Jun 1998 18:26:20 -0700 (PDT) Received: from drw.darakwon.co.kr ([203.251.137.14]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA19123; Fri, 12 Jun 1998 18:26:18 -0700 (PDT) Date: Fri, 12 Jun 1998 18:26:18 -0700 (PDT) Received: from default (unverified [4.16.90.236]) by drw.darakwon.co.kr (EMWAC SMTPRS 0.83) with SMTP id ; Sat, 13 Jun 1998 10:42:04 +0900 From: 67l7jph <67l7jph@sprint.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Thursday, May 14th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Tuesday, May 12th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Sunday, May 10th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Saturday, May 9th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Friday, May 15th, 1998 Reply-To: 67l7jph@sprint.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <67l7jph@sprint.com> Subject: 6 7 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-427-5820 CALL FOR MORE INFORMATION 213-427-5820 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-427-5820 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Sat Jun 13 19:38:06 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA10443 for ietf-medfree-bks; Sat, 13 Jun 1998 19:38:06 -0700 (PDT) Received: from dns.manbow.co.jp (dns.manbow.co.jp [210.154.51.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA10432; Sat, 13 Jun 1998 19:38:04 -0700 (PDT) Received: from z7 (PPPa10-Resale_Los_Angeles1-1R1018.saturn.bbn.com [4.16.36.21]) by dns.manbow.co.jp (8.7.3 Version 1.1 Build 566/8.7.3) with SMTP id LAA00044; Sun, 14 Jun 1998 11:45:01 +0900 (JST) Date: Sun, 14 Jun 1998 11:45:01 +0900 (JST) From: 1919dd <1919dd@sprint.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Sunday, June 14th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Friday, June 12th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Wednesday, June 10th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Tuesday, June 9th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Monday, June 15th, 1998 Reply-To: 1919dd@sprint.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <1919dd@sprint.com> Subject: 1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-969-4930 CALL FOR MORE INFORMATION 213-969-4930 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-969-4930 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Mon Jun 15 19:19:27 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA00595 for ietf-medfree-bks; Mon, 15 Jun 1998 19:19:27 -0700 (PDT) Received: from ns.rally.or.jp (ns.rally.or.jp [210.160.90.114]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA00585; Mon, 15 Jun 1998 19:19:22 -0700 (PDT) Received: from jj3dw3.q3q3665f.com (PPPa10-Resale_Inglewood1-5R1045.saturn.bbn.com [4.16.90.213]) by ns.rally.or.jp (8.8.5/3.5Wpl7) with SMTP id LAA27974; Tue, 16 Jun 1998 11:21:28 +0900 (JST) Date: Tue, 16 Jun 1998 11:21:28 +0900 (JST) From: 2tj5uy <2tj5uy@sprint.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Friday, April 10th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Wednesday, April 8th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Monday, April 6th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Sunday, April 5th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Saturday, April 11th, 1998 Reply-To: 2tj5uy@sprint.com MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Transfer-Encoding: 8bit Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <2tj5uy@sprint.com> Subject: 2t Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-427-5820 CALL FOR MORE INFORMATION 213-427-5820 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-427-5820 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Tue Jun 16 10:02:02 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA22943 for ietf-medfree-bks; Tue, 16 Jun 1998 10:02:02 -0700 (PDT) Received: from wsooti08.win.tue.nl (wsooti08.win.tue.nl [131.155.70.156]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA22937 for ; Tue, 16 Jun 1998 10:02:00 -0700 (PDT) Received: from koen@localhost by wsooti08.win.tue.nl (8.8.7) id TAA07825. Tue, 16 Jun 1998 19:07:38 +0200 (MET DST) From: koen@win.tue.nl (Koen Holtman) Message-Id: <199806161707.TAA07825@wsooti08.win.tue.nl> Subject: Re: Issues list To: hardie@nic.nasa.gov Date: Tue, 16 Jun 1998 19:07:37 +0200 (MET DST) Cc: ietf-medfree@imc.org In-Reply-To: <9806101638.ZM20393@thornhill.arc.nasa.gov> from "Ted Hardie" at Jun 10, 98 04:38:39 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ietf-medfree@imc.org Precedence: bulk Ted Hardie: > [....] >4) (RAT_HOLE) > >The current language will be retained. Your previous proposal on this issue was: Current proposal is to treat the language change as an editorial issue clarifying our intent to focus on media features and otherwise leave things alone. I really would like to see an editorial clarification to the current language. I consider the current sentence Feature tags indicating political or social context are not appropriate. to be severely broken because I read 'not appropriate' as a normative statement, one what would require us to exactly define `political or social context' (as being disjoint from `presentation-related context' presumably). I believe that you mean the 'not apropriate' sentence to be read as a non-normative clarification of the sentence before it, not as an additional restriction. If you do mean it to be read as a clarification, then we have consensus about what the draft is supposed to say, and this issue is an editorial one. If you think that the 'not appropriate' sentence is important by itself, then we do not have consensus. Koen. From owner-ietf-medfree Tue Jun 16 16:06:19 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA25792 for ietf-medfree-bks; Tue, 16 Jun 1998 16:06:19 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA25788 for ; Tue, 16 Jun 1998 16:06:18 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA27503; Tue, 16 Jun 1998 16:12:01 -0700 Date: Tue, 16 Jun 1998 16:12:01 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9806161612.ZM27501@thornhill.arc.nasa.gov> In-Reply-To: koen@win.tue.nl (Koen Holtman) "Re: Issues list" (Jun 16, 7:07pm) References: <199806161707.TAA07825@wsooti08.win.tue.nl> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: koen@win.tue.nl (Koen Holtman), hardie@nic.nasa.gov Subject: Re: Issues list Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk Koen, Andy will be trying to issue a new draft in the next week; if he has an inspiration on how to make that clearer, he will. In the mean time, I have sent a message to IANA asking if they find the current language clear enough to allow them to do the work they need. If you have specific language to propose, please send it to Andy. regards, Ted Hardie On Jun 16, 7:07pm, Koen Holtman wrote: > Subject: Re: Issues list > Ted Hardie: > > > [....] > >4) (RAT_HOLE) > > > >The current language will be retained. > > Your previous proposal on this issue was: > Current > proposal is to treat the language change as an editorial issue > clarifying our intent to focus on media features and otherwise > leave things alone. > > I really would like to see an editorial clarification to the current > language. I consider the current sentence > > Feature tags > indicating political or social context are not appropriate. > > to be severely broken because I read 'not appropriate' as a normative > statement, one what would require us to exactly define `political or > social context' (as being disjoint from `presentation-related context' > presumably). > > I believe that you mean the 'not apropriate' sentence to be read as a > non-normative clarification of the sentence before it, not as an > additional restriction. If you do mean it to be read as a > clarification, then we have consensus about what the draft is supposed > to say, and this issue is an editorial one. If you think that the > 'not appropriate' sentence is important by itself, then we do not have > consensus. > > Koen. >-- End of excerpt from Koen Holtman From owner-ietf-medfree Tue Jun 16 19:37:35 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA28112 for ietf-medfree-bks; Tue, 16 Jun 1998 19:37:35 -0700 (PDT) Received: from firewall.korbiz.or.kr (www.korbiz.or.kr [210.107.14.253]) by mail.proper.com (8.8.8/8.8.5) with SMTP id TAA28007; Tue, 16 Jun 1998 19:22:58 -0700 (PDT) Date: Tue, 16 Jun 1998 19:22:58 -0700 (PDT) Received: from www.korbiz.or.kr [210.107.14.253] (HELO localhost) by firewall.korbiz.or.kr (AltaVista Mail V1.0/1.0 BL18 listener) id 0000_011e_3587_25e9_9a8b; Wed, 17 Jun 1998 11:11:53 +0900 Received: from TCG.46.COBRA.ICDC.COM by firewall (smtpxd); id XA00155 From: 4ta1ug <4ta1ug@att.net> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Tuesday, June 16th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Sunday, June 14th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Friday, June 12th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Thursday, June 11th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Wednesday, June 17th, 1998 Reply-To: 4ta1ug@att.net Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <4ta1ug@att.net> Subject: 4t Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-427-5820 CALL FOR MORE INFORMATION 213-427-5820 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-427-5820 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Wed Jun 17 10:31:57 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA20288 for ietf-medfree-bks; Wed, 17 Jun 1998 10:31:57 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA20284 for ; Wed, 17 Jun 1998 10:31:56 -0700 (PDT) Received: (qmail 17953 invoked from network); 17 Jun 1998 17:37:55 -0000 Received: from unknown (HELO GK.Group5.co.uk) (193.128.238.237) by smtp.dial.pipex.com with SMTP; 17 Jun 1998 17:37:55 -0000 Message-Id: <3.0.32.19980617183732.007b6270@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 17 Jun 1998 18:37:38 +0100 To: conneg WG From: Graham Klyne Subject: ITU "full mode" goals and schedule Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id KAA20285 Sender: owner-ietf-medfree@imc.org Precedence: bulk I'm cross-posting this because of the reference to "capabilities" in fax. Specifically, should we be aiming to defining a MIME type to carry capability information? #g >Date: Wed, 17 Jun 1998 14:35:37 +0200 >To: ietf-fax@imc.org >From: Dave Crocker >Subject: ITU "full mode" goals and schedule >Cc: Keith Moore , Patrik Fältström , > jrafferty@worldnet.att.net >Sender: owner-ietf-fax@imc.org > >Greetings from truly beautiful Geneva, > >This is an entirely unofficial -- that is, entirely personal -- note. An >"official" communique' is going through the approval cycle. James Rafferty >is also sending his own unofficial note, so we will benefit from >verification/correction of my own comments. > >ITU SG8/Q.4 T.37 enhancement efforts, to consider embellishing the simple >mode produced by the IETF, so as to bring the level of service essentially >up to full equivalence of telephone-based G3 fax, reviewed the work being >done by the IETF. > >I believe there are 3 important details to come out of the discussions: > >1. Full mode (probably best referred to as the EIFax, from IETF >perspective) must support an appropriate confirmation mechanism and an >ability for senders to obtain information about the capabilities of receivers. > >2. It appears reasonable and appropriate to use DSN for the confirmation >mechanism, but with a specific enhancement > >3. The formal ITU schedule makes it extremely important to try to complete >the IETF work (through the IESG) no later than the end of January, 1999. > > >Capabilities >------------ > >There wasn't any detailed discussion on this, due to time constraints. >Still, the requirement for capabilities was (pardon the pun) confirmed. My >own belief is that the IETF working group should define a MIME type for the >data, or specify a profile for an existing MIME type, perhaps such as >vcard. My guess is that we do not need to specify the means of conveying >that data, since MIME data can be transported in many ways, and it is the >transport mechanism which seems to be getting the most debate. > > [Rest of message chopped: see ietf-fax list for full message] ------------ Graham Klyne From owner-ietf-medfree Wed Jun 17 10:31:38 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA20269 for ietf-medfree-bks; Wed, 17 Jun 1998 10:31:38 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA20265 for ; Wed, 17 Jun 1998 10:31:37 -0700 (PDT) Received: (qmail 17896 invoked from network); 17 Jun 1998 17:37:36 -0000 Received: from unknown (HELO GK.Group5.co.uk) (193.128.238.237) by smtp.dial.pipex.com with SMTP; 17 Jun 1998 17:37:36 -0000 Message-Id: <3.0.32.19980617171010.008d2360@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 17 Jun 1998 18:37:18 +0100 To: koen@win.tue.nl (Koen Holtman) From: Graham Klyne Subject: Re: Issues list Cc: hardie@nic.nasa.gov, ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 19:07 16/06/98 +0200, Koen Holtman wrote: > Feature tags > indicating political or social context are not appropriate. > >to be severely broken because I read 'not appropriate' as a normative >statement, one what would require us to exactly define `political or >social context' (as being disjoint from `presentation-related context' >presumably). That's interesting. I was happy with this statement because I felt it was NOT normative, more indicative of intent. >I believe that you mean the 'not apropriate' sentence to be read as a >non-normative clarification of the sentence before it, not as an >additional restriction. If you do mean it to be read as a >clarification, then we have consensus about what the draft is supposed >to say, and this issue is an editorial one. I agree with this. If "not appropriate" is not consistently interpreted by readers then an alternative form of words would be helpful. How about: "Feature tags are not intended to be used for political or social contexts." #g ------------ Graham Klyne From owner-ietf-medfree Fri Jun 19 00:36:25 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA28996 for ietf-medfree-bks; Fri, 19 Jun 1998 00:36:25 -0700 (PDT) Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA28987 for ; Fri, 19 Jun 1998 00:36:23 -0700 (PDT) Received: from w3c.ifi.unizh.ch (ifimac21.ifi.unizh.ch [130.60.48.190]) by sh.w3.mag.keio.ac.jp (8.9.0/3.6W-W3C/Keio) with SMTP id QAA12079; Fri, 19 Jun 1998 16:42:06 +0900 (JST) Message-Id: <199806190742.QAA12079@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: Thu, 18 Jun 1998 20:49:29 +0900 To: hardie@nic.nasa.gov From: "Martin J. Duerst" Subject: Re: Issues list Cc: ietf-medfree@imc.org, hardie@nic.nasa.gov In-Reply-To: <9806101638.ZM20393@thornhill.arc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk Hello Ted, At 16:38 98/06/10 -0700, Ted Hardie wrote: > 7) (DATA_TYPES) > > The following data types will be primitive to the registry: > > > - numbers: integer and rational > - tokens, with equality relarionship > - strings, with equality relationship > - strings, with defined comparison (case insensitive, unicode) > - ordered tokens > > For both ordered token and defined-comparison strings, the > registration must include the information needed to compare > (the order or the defintion of string comparison, as appropriate). How exactly is case-insensitive defined? For ASCII only? So that it works for Turkish? There are quite a bit of things you can wrong there :-(. Regards, Martin. From owner-ietf-medfree Fri Jun 19 06:17:36 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA10027 for ietf-medfree-bks; Fri, 19 Jun 1998 06:17:36 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA10023 for ; Fri, 19 Jun 1998 06:17:35 -0700 (PDT) Received: (qmail 29197 invoked from network); 19 Jun 1998 13:23:43 -0000 Received: from userh383.uk.uudial.com (HELO GK.Group5.co.uk) (194.69.102.10) by smtp.dial.pipex.com with SMTP; 19 Jun 1998 13:23:43 -0000 Message-Id: <3.0.32.19980619100847.00804d60@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 19 Jun 1998 14:23:23 +0100 To: "Martin J. Duerst" From: Graham Klyne Subject: Re: Issues list Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 20:49 18/06/98 +0900, Martin J. Duerst wrote: >Hello Ted, > >At 16:38 98/06/10 -0700, Ted Hardie wrote: > >> 7) (DATA_TYPES) >> >> The following data types will be primitive to the registry: >> >> >> - numbers: integer and rational >> - tokens, with equality relarionship >> - strings, with equality relationship >> - strings, with defined comparison (case insensitive, unicode) >> - ordered tokens >> >> For both ordered token and defined-comparison strings, the >> registration must include the information needed to compare >> (the order or the defintion of string comparison, as appropriate). > >How exactly is case-insensitive defined? For ASCII only? So that >it works for Turkish? There are quite a bit of things you can >wrong there :-(. I think this means that for all comparisons other than standard exact equality (i.e. case sensitivity), it is the feature registration author's responsibility to define exactly what the comparison operation should be (e.g. exactly how case insensitive comparison might be performed). That was how I read it, anyway. #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-medfree Fri Jun 19 09:59:32 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA11473 for ietf-medfree-bks; Fri, 19 Jun 1998 09:59:32 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA11469 for ; Fri, 19 Jun 1998 09:59:31 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA01205; Fri, 19 Jun 1998 10:05:33 -0700 Date: Fri, 19 Jun 1998 10:05:33 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9806191005.ZM1203@thornhill.arc.nasa.gov> In-Reply-To: "Martin J. Duerst" "Re: Issues list" (Jun 18, 8:49pm) References: <199806190742.QAA12079@sh.w3.mag.keio.ac.jp> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: "Martin J. Duerst" , hardie@nic.nasa.gov Subject: Re: Issues list Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk On Jun 18, 8:49pm, Martin J. Duerst wrote: > > - strings, with defined comparison (case insensitive, unicode) > > > > For both ordered token and defined-comparison strings, the > > registration must include the information needed to compare > > (the order or the defintion of string comparison, as appropriate). > > How exactly is case-insensitive defined? For ASCII only? So that > it works for Turkish? There are quite a bit of things you can > wrong there :-(. Martin, Sorry if this is confusing, but we are not making case insensitive or unicode matching primitive to the registry; we are making strings-with-defined-matching primitive, and requiring that those registered items which use that primitive provide a definition of how to do the matching. If you provide a definition that indicates, for example, that whitespace is to be stripped before the comparison, that's the comparison for that registered item. Anyone supporting that item must then support that comparison (and since the registered item has *only one* comparison allowed, you can be sure if they do or don't support it). If you are using UTF-8 with a non-standard matching algorithm, that's the matching algorithm for that registered item. This does not mean that we should encourage people to use a huge variety of matching algorithms. Equality relationships are probably to be prefered in almost all cases. I hope this clears up the confusion, regards, Ted Hardie NASA/STX From owner-ietf-medfree Fri Jun 19 14:57:50 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA13975 for ietf-medfree-bks; Fri, 19 Jun 1998 14:57:50 -0700 (PDT) Received: from mailhost.bpa.nl (mailhost.bpa.nl [193.172.36.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA13937; Fri, 19 Jun 1998 14:56:50 -0700 (PDT) Received: from resilier (TCG.46.DEFIANT.ICDC.COM [209.186.11.52]) by mailhost.bpa.nl (8.8.8/8.8.7) with SMTP id AAA10907; Sat, 20 Jun 1998 00:00:46 +0200 (MET DST) Date: Sat, 20 Jun 1998 00:00:46 +0200 (MET DST) From: 3lu1ij <3lu1ij@sprint.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Friday, June 19th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Wednesday, June 17th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Monday, June 15th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Sunday, June 14th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Saturday, June 20th, 1998 Reply-To: 3lu1ij@sprint.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <3lu1ij@sprint.com> Subject: 3 u Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-427-5820 CALL FOR MORE INFORMATION 213-427-5820 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-427-5820 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Fri Jun 19 17:12:32 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA15340 for ietf-medfree-bks; Fri, 19 Jun 1998 17:12:32 -0700 (PDT) Received: from eiaj.or.jp (eiajnw.eiaj.or.jp [203.180.149.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA15296; Fri, 19 Jun 1998 17:12:06 -0700 (PDT) Received: from z7 (1Cust82.tnt1.lax3.da.uu.net [153.37.43.82]) by eiaj.or.jp (8.7.5) with SMTP id JAA05165; Sat, 20 Jun 1998 09:08:48 +0900 (JST) Date: Sat, 20 Jun 1998 09:08:48 +0900 (JST) From: 7wt8ij <7wt8ij@worldnet.att.net> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Thursday, June 18th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Tuesday, June 16th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Sunday, June 14th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Saturday, June 13th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Friday, June 19th, 1998 Reply-To: 7wt8ij@worldnet.att.net Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <7wt8ij@worldnet.att.net> Subject: 7 w Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-969-4930 CALL FOR MORE INFORMATION 213-969-4930 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-969-4930 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Sat Jun 20 17:45:44 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA11305 for ietf-medfree-bks; Sat, 20 Jun 1998 17:45:44 -0700 (PDT) Received: from sydkraft.sydkraft.se (sydkraft.sydkraft.se [143.217.129.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA11299 for ; Sat, 20 Jun 1998 17:45:42 -0700 (PDT) Received: from resilier (ip5.los-angeles3.ca.pub-ip.psi.net [38.14.43.5]) by sydkraft.sydkraft.se (8.6.11/8.6.11) with SMTP id CAA20898; Sun, 21 Jun 1998 02:55:12 +0200 Date: Sun, 21 Jun 1998 02:55:12 +0200 From: 1919h5 <1919h5@worldnet.att.net> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Tuesday, June 2nd, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Sunday, May 31st, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Friday, May 29th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Thursday, May 28th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Wednesday, June 3rd, 1998 Reply-To: 1919h5@worldnet.att.net Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <1919h5@worldnet.att.net> Subject: 1 9 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-427-5820 CALL FOR MORE INFORMATION 213-427-5820 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-427-5820 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Sun Jun 21 17:01:47 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA24490 for ietf-medfree-bks; Sun, 21 Jun 1998 17:01:47 -0700 (PDT) Received: from cheops.sito.se ([194.213.66.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA24479 for ; Sun, 21 Jun 1998 17:01:44 -0700 (PDT) Date: Sun, 21 Jun 1998 17:01:44 -0700 (PDT) Received: from ip50.los-angeles3.ca.pub-ip.psi.NET (ip50.los-angeles3.ca.pub-ip.psi.NET [38.14.43.50]) by cheops.sito.se (NTMail 3.02.10) with ESMTP id ka042390 for ; Mon, 22 Jun 1998 02:03:41 +0200 From: j6j644f To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Tuesday, June 2nd, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Sunday, May 31st, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Friday, May 29th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Thursday, May 28th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Wednesday, June 3rd, 1998 Reply-To: j6j644f@sprint.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is Subject: Bull's Eye Targeting Software Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Mon, 22 Jun 1998 02:03:40 +0200 EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-427-5820 CALL FOR MORE INFORMATION 213-427-5820 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-427-5820 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Mon Jun 22 17:03:06 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA20054 for ietf-medfree-bks; Mon, 22 Jun 1998 17:03:06 -0700 (PDT) Received: from as1.aokitech.co.jp ([210.129.151.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA20050 for ; Mon, 22 Jun 1998 17:03:02 -0700 (PDT) Received: from resilier (1Cust181.tnt1.malibu.ca.da.uu.net [208.254.22.181]) by as1.aokitech.co.jp (8.7.5/3.4W4) with SMTP id IAA17058; Tue, 23 Jun 1998 08:58:57 +0900 (JST) Date: Tue, 23 Jun 1998 08:58:57 +0900 (JST) From: 5mj3il <5mj3il@mci.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Wednesday, June 3rd, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Monday, June 1st, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Saturday, May 30th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Friday, May 29th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Thursday, June 4th, 1998 Reply-To: 5mj3il@mci.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <5mj3il@mci.com> Subject: Bull's**Eye Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-427-5820 CALL FOR MORE INFORMATION 213-427-5820 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-427-5820 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Tue Jun 23 15:23:13 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA14736 for ietf-medfree-bks; Tue, 23 Jun 1998 15:23:13 -0700 (PDT) Received: from ernitec.dk ([194.192.210.75]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA14732 for ; Tue, 23 Jun 1998 15:23:04 -0700 (PDT) Date: Tue, 23 Jun 1998 15:23:04 -0700 (PDT) Received: from resilier ([209.186.11.93]) by ernitec.dk (Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) with SMTP id C125662C.00788F6E; Tue, 23 Jun 1998 23:57:13 +0200 From: 2vc5lb <2vc5lb@mci.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Thursday, June 4th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Tuesday, June 2nd, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Sunday, May 31st, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Saturday, May 30th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Friday, June 5th, 1998 Reply-To: 2vc5lb@mci.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <2vc5lb@mci.com> Subject: Bull's**Eye Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-427-5820 CALL FOR MORE INFORMATION 213-427-5820 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-427-5820 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-ietf-medfree Wed Jun 24 16:44:39 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA12151 for ietf-medfree-bks; Wed, 24 Jun 1998 16:44:39 -0700 (PDT) Received: from server01.cdnet.at (SERVER01.CDNET.AT [195.26.202.254]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA12147; Wed, 24 Jun 1998 16:44:35 -0700 (PDT) Date: Wed, 24 Jun 1998 16:44:35 -0700 (PDT) Received: from z7 ([208.254.22.75]) by server01.cdnet.at (Post.Office MTA v3.1 release PO203a ID# 0-0U10L2S100) with SMTP id AFZ306; Thu, 25 Jun 1998 01:16:48 +0200 From: 5xlm9kh <5xlm9kh@mci.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Friday, June 5th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Wednesday, June 3rd, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Monday, June 1st, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Sunday, May 31st, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Saturday, June 6th, 1998 Reply-To: 5xlm9kh@mci.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <5xlm9kh@mci.com> Subject: Targeted Software Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-969-4930 CALL FOR MORE INFORMATION 213-969-4930 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-969-4930 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. *If you would like your email address removed, please write us at the above address. From owner-ietf-medfree Fri Jun 26 14:23:15 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA03172 for ietf-medfree-bks; Fri, 26 Jun 1998 14:23:15 -0700 (PDT) Received: from www.navratil.cz (www.brno.vol.cz [195.250.131.254]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA03115; Fri, 26 Jun 1998 14:21:17 -0700 (PDT) Received: from resilier (1Cust242.tnt1.malibu.ca.da.uu.net [208.254.22.242]) by www.navratil.cz (8.8.5/8.8.5) with SMTP id XAA13374; Fri, 26 Jun 1998 23:19:37 +0200 Date: Fri, 26 Jun 1998 23:19:37 +0200 From: "b.e.target software" <7fil1oh@mci.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Thursday, June 4th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Tuesday, June 2nd, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Sunday, May 31st, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Saturday, May 30th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Friday, June 5th, 1998 Reply-To: 7fil1oh@mci.com Sender: owner-ietf-medfree@imc.org Precedence: bulk Authenticated sender is <7fil1oh@mci.com> Subject: Targeting Software Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-427-5820 CALL FOR MORE INFORMATION 213-427-5820 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-427-5820 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. *If you would like your email address removed, please write us at the above address. From owner-ietf-medfree Tue Jun 30 10:51:38 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA18219 for ietf-medfree-bks; Tue, 30 Jun 1998 10:51:38 -0700 (PDT) Received: from wsooti08.win.tue.nl (wsooti08.win.tue.nl [131.155.70.156]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA18215 for ; Tue, 30 Jun 1998 10:51:37 -0700 (PDT) Received: from koen@localhost by wsooti08.win.tue.nl (8.8.7) id TAA14206. Tue, 30 Jun 1998 19:58:31 +0200 (MET DST) From: koen@win.tue.nl (Koen Holtman) Message-Id: <199806301758.TAA14206@wsooti08.win.tue.nl> Subject: Announce: update of TCN client implementation To: ietf-medfree@imc.org Date: Tue, 30 Jun 1998 19:58:30 +0200 (MET DST) Cc: koen@win.tue.nl (Koen Holtman) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ietf-medfree@imc.org Precedence: bulk I just put an updated version of the conneg-uax package on my transparent content negotiation web page http://gewis.win.tue.nl/~koen/conneg/ . This version is fully compatible with the experimental RFCs for transparent content negotiation. >From the README file: Content negotiating user agent extension ======================================== v2.0, 28 June 1998 This package contains an implementation of the user-agent side of the transparent content negotiation (TCN) specifications (RFC 2295 and RFC 2296, see (http://gewis.win.tue.nl/~koen/conneg/ for html versions of these specifications). It implements the example local variant selection algorithm in appendix 19 of RFC 2295, and includes a dynamic accept header generator which follows the method suggested in section 4.2.3 of RFC 2296. The package is useful as an example implementation of the above RFCs and can also be used for testing or debugging TCN implementations in CGI scripts or servers. Koen. From owner-ietf-medfree Thu Jul 2 18:59:40 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA23704 for ietf-medfree-bks; Thu, 2 Jul 1998 18:59:40 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA23699 for ; Thu, 2 Jul 1998 18:59:33 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA16797 for ietf-medfree@imc.org; Thu, 2 Jul 1998 18:59:06 -0700 Date: Thu, 2 Jul 1998 18:59:06 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9807021859.ZM16795@thornhill.arc.nasa.gov> Reply-To: hardie@archimedes.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: ietf-medfree@imc.org Subject: New -reg- draft Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19807021859.ZM16795.arc.nasa.gov" Sender: owner-ietf-medfree@imc.org Precedence: bulk -- --PART-BOUNDARY=.19807021859.ZM16795.arc.nasa.gov Content-Type: text/plain; charset=us-ascii Attached is a new version of the registration draft, capturing the changes associated with the items on our issues list. Among the changes: -The sections describing different registration policies for different trees now refer to the iesg iana considerations document, and the related text is now shorter. -% has been added to the set of characters allowed in feature tags -the values allowed for feature tags now reflects the data types agreed on by the group -the term "feature bundle" has been introduced to described sets of feature tags like pix-x and pix-y. -text related to the association of ASN.1 identifiers with specific feature tags has been added -the registration template has been modified to note these changes. Due to the press of work related to a product launch, Andy Mutz will no longer be able to serve as editor for this draft. With the consent of the Area Directors, I have tried to capture the consensus of the group for this draft, and I hope that we can move it forward with no further substantive changes. If there are extensive changes, we will need another editor. Please review the draft carefully, and join me in thanking Andy for all his work on it, regards, Ted Hardie Chair, CONNEG --PART-BOUNDARY=.19807021859.ZM16795.arc.nasa.gov X-Zm-Content-Name: draft-ietf-conneg-feature-reg-01.txt Content-Description: Text Content-Type: text/plain ; name="draft-ietf-conneg-feature-reg-01.txt" ; charset=us-ascii CONNEG Working Group Koen Holtman, TUE Internet-Draft Andrew Mutz, Hewlett-Packard Expires: January, 1999 Ted Hardie, NASA July, 1998 Content Feature Tag Registration Procedure draft-ietf-conneg-feature-reg-01.txt STATUS OF THIS MEMO This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Copyright (C) The Internet Society (1998). All Rights Reserved. Distribution of this document is unlimited. Please send comments to the MEDFREE working group at . Discussions of the working group are archived at . ABSTRACT Recent Internet applications, such as the World Wide Web, tie together a great diversity in data formats, client and server platforms, and communities. This has created a need for content feature descriptions and negotiation mechanisms in order to identify and reconcile the form of information to the capabilities and preferences of the parties involved. Extensible content feature identification and negotiation mechanisms require a common vocabulary in order to positively identify content features. A registration process and authority for content features is defined with the intent of sharing this vocabulary between communicating parties. In addition, a URI tree is defined to enable sharing of content feature definitions without registration. This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the content feature vocabulary. TABLE OF CONTENTS 1 Introduction 2 Feature tag definitions 2.1 Feature tag purpose 2.2 Feature tag syntax 3 Feature tag registration 3.1 Registration trees 3.1.1 IETF tree 3.1.2 Global tree 3.1.3 URL tree 3.1.4 Additional registration trees 3.2 Location of registered feature tag list 3.3 IANA procedures for registering feature tags 3.4 Registration template 4 Security considerations 5 Acknowledgments 6 References 7 Authors' addresses Appendix A: IANA and RFC editor to-do list 1 Introduction Recent Internet applications, such as the World Wide Web, tie together a great diversity in data formats, client and server platforms, and communities. This has created a need for content feature descriptions and negotiation mechanisms in order to identify and reconcile the form of information to the capabilities and preferences of the parties involved. Extensible content feature identification and negotiation mechanisms require a common vocabulary in order to positively identify content features. A registration process and authority for content features is defined with the intent of sharing this vocabulary between communicating parties. In addition, a URI tree is defined to enable sharing of content feature definitions without registration. This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the content feature vocabulary. 2 Feature tag definitions 2.1 Feature tag purpose Feature tags represent individual and simple dimensions of feature capability. Examples of features related to media are: * the color depth of the screen on which something is to be displayed * the type of paper available in a printer * the support of the `floating 5 dimensional tables' feature * the fonts which are available to the recipient * the capability to display graphical content A feature tag identifies a single dimension of characteristic. Feature tag values should use the data types defined in 2.3. Examples of feature tags are defined in detail elsewhere [4]. Examples of feature tags with values are: * the width of a display in pixels per centimeter represented as an integer value. * the fonts available to a recipient as an enumerated list. * the version of a protocol composed of integers "i.j.k", defined as either a value in an enumerated list or with a defined mapping to make the value isomorphic to a subset of integers (e.g. i*100 + j*10 +k, assuming j<=9 and k<=9). Feature bundles may be composed using a number of individual feature tags [2]. Composition of feature bundles is described elsewhere [2]. Examples of feature bundles requiring multiple feature tags are: * the width and height of a display * the combination of color depth and resolution a display can support This registry presumes the availability of the MIME media type registry, and MIME media types MUST NOT be re-registered as feature tags. Feature tags which are currently in use by individual protocols or applications MAY be registered with this registry if they might be applied outside of their current domain. The feature tag namespace is not bound to a particular transport protocol or capability exchange mechanism. The registry is limited, however, to feature tags which express a capability or preference related to how content is presented. Feature tags related to other axes of negotiation are not appropriate for this registry. Capability exchange mechanisms may, of course, be used to express a variety of capabilities or preferences. 2.2 Feature tag syntax A feature tag is a string consisting of one or more of the following US-ASCII characters: uppercase letters, lowercase letters, digits, colon (":"), slash ("/"), dot (".") percent ("%"), and dash ("-"). Feature tags are case-insensitive. Dots are understood to potentially imply heirarchy; a feature can be subtyped by describing it as tree.feature.subfeature and by indicating this in the feature registration. Feature tags should begin with an alphabetic character. In ABNF [6], this may be represented as: Feature-tag = ALPHA *( ALPHA / DIGIT / ":" / "/" / "." / "-" /"%" ) 2.2 Feature tag values The registry will initially support the use of the following data types as feature tag values: - integers - rational numbers - tokens, with equality relarionship - strings, with equality relationship - strings, with defined comparison - ordered tokens At the time of registration, each feature tag must be associated with a single data type. If that data type implies a defined comparison or an ordering, the registrant must define the ordering or comparison. For ordered tokens, this may be by full enumeration of the tokens and their order or by reference to an ordering mechanism. For defined comparisons, a full description of the rules for comparison must be provided or included by reference. Feature tags related to spatial or temporal characteristics must be registered with a single canonical unit. It is strongly preferred that units be in the SI system; where current practice has defined units in other systems (such as pixels per inch), a conversion method to SI units must be provided. Conversion methods should include a defined rounding practice. 2.3 ASN.1 identifiers for Feature tags Certain protocols use ASN.1 identifiers rather than human-readable representations for capability exchange. In order to allow both systems to interoperate, registrants may provide an ASN.1 identifier or ask that IANA assign an ASN.1 identifier during registration. These identifiers are not required for registration, but may provide assistance to those building gateways or other cross-protocol systems. Note that ASN.1 identifiers assigned by IANA will be treated as tokens, not as elements from which sub-delegated identifiers may be created or derived. 3 Feature tag registration Feature tags can be registered in several different registration trees, with different requirements as discussed below. The vocabulary for these requirements is taken from [5]. In general, a feature tag registration proposal is circulated and reviewed in a fashion appropriate to the tree involved. The feature tag is then registered if the proposal is accepted. Review of a feature tag in the URI tree is not required. 3.1 Registration trees The following subsections define registration "trees", distinguished by the use of faceted names (e.g., names of the form "tree.feature- name"). 3.1.1 IETF tree The IETF tree is intended for feature tags of general interest to the Internet Community, and proposals for these tags must meet the "IETF Consensus" policies described in [5]. Registration in the IETF tree requires approval by the IESG and publication of the feature tag specification as an RFC. Submissions for feature tag registration in the IETF tree can originate in any WG of the IETF or as an individual submission to the IESG. Feature tags in the IETF tree normally have names that are not explicitly faceted, i.e., do not contain period (".", full stop) characters. 3.1.2 Global tree Tags in the global tree will be distinguished by the leading facet "g.". That may be followed, at the discretion of the registrar, by either a designation indicative of the feature, (e.g., "g.blinktags") or by an IANA-approved designation of the producer's name which is then followed by a designation of the feature (e.g., g.bigcompany.obscurefeature). Registrations of feature tag in the global tree must meet the "Expert Review" policies described in [5]. In this case, a designated area expert will review the proposed tag, consulting with the members of a related mailing list. A registration may be placed in the global tree by anyone who has the need to allow for communication on a particular capability or preference. 3.1.3 URI tree A feature tag may be defined as a URI using the restricted character set defined above. Feature tags in the URI tree are identified by the leading facet "u.". The author of the URI is assumed to be registration authority regarding features defined and described by the content of the URI. These tags are considered unregistered for the purpose of this document. 3.1.4 Additional registration trees From time to time and as required by the community, the IANA may, with the advice and consent of the IESG, create new top-level registration trees. These trees may be created for external registration and management by (for example) well-known permanent bodies, such as scientific societies for content feature types specific to the sciences they cover. Establishment of these new trees will be announced through RFC publication approved by the IESG. 3.2 Location of registered feature tag list Feature tag registrations will be posted in the anonymous FTP directory "ftp://ftp.isi.edu/in-notes/iana/assignments/feature- tags/" and all registered feature tags will be listed in the periodically issued "Assigned Numbers" RFC [currently STD 2, RFC-1700]. The feature tag description and other supporting material may also be published as an Informational RFC by sending it to "rfc- editor@isi.edu" (please follow the instructions to RFC authors [RFC- 1543]). 3.3 IANA procedures for registering feature tags The IANA will only register feature tags in the IETF tree in response to a communication from the IESG stating that a given registration has been approved. Global tags will be registered by the IANA after review by an area expert. That review will serve to ensure that the tag meets the technical requirements of this specification. 3.4 Registration template To: ietf-feature-tags@iana.org (Feature tags mailing list) (or directly to iana@iana.org) Subject: Registration of feature tag XXXX | Instructions are preceded by `|'. Some fields are optional. Content feature tag name: ASN.1 identifier associated with feature tag: [optional] | To have IANA assign an ASN.1 identifier, | use the value "New assignment by IANA" here. Summary of the content feature indicated by this feature tag: | Include a short (no longer than 4 lines) description or summary | Examples: | `Use of the xyzzy feature is indicated by ...' | `Support of color display is indicated by ...' | `Number of colors in a palette which can be defined ...' Number of possible values associated with this feature tag: [ ] 1. The feature tag is Boolean and the feature tag has no associated value. The tag indicates presence (or absence) of the feature. [ ] 2. The feature has an associated numeric or enumerated value. For case 1: describe the nature of the `yes' and `no' alternatives: For case 2: Indicate the data type of the value: [ ] 2a. Integer [ ] 2b. Rational number [ ] 2c. Token (equality relationship) [ ] 2d. Token (ordered) [ ] 2e. String (equality relationship) [ ] 2f. String (defined comparison) |IMPORTANT: You may only chose one of the above data types. (Only for case 2) Detailed description of the feature value meaning, and of the format and meaning of the feature tag values for the alternative results. | If you have selected 2d you must provide the ordering mechanism | or a full and ordered enumeration of possible values. If you | have selected 2f, you must provide a defintion of the comparison. | Definitions by included reference must be to stable and readily | available specifications: | | If the number of alternative results is small, you may | enumerate the identifiers of the different results and describe | their meaning. | | If there is a limited useful numeric range of result (2b, 2c), | indicate the range. | | The identifiers of the alternative results could also be | described by referring to another IANA registry, for example | the paper sizes enumerated by the Printer MIB. Expected value or behavior in the absence of the feature tag (if applicable): The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: [optional] | For applications, also specify the number of the first version | which will use the tag, if applicable. Examples of typical use: [optional] Related standards or documents: [optional] Considerations particular to use in individual applications, protocols, services, or negotiation mechanisms: [optional] Interoperability considerations: [optional] Security considerations: Privacy concerns, related to exposure of personal information: Denial of service concerns related to consequences of specifying incorrect values: Other: Additional information: [optional] Keywords: [optional] Related feature tags: [optional] Related media types or data formats: [optional] Related markup tags: [optional] Name(s) & email address(es) of person(s) to contact for further information: Intended usage: | one of COMMON, LIMITED USE or OBSOLETE Author/Change controller: Requested IANA publication delay: [optional] | A delay may only be requested for registration in the global or | IETF trees, with a maximum of two months. Other information: [optional] | Any other information that the author deems interesting may be | added here. 4 Security considerations Negotiation mechanisms reveal information about one party to other parties. This may raise privacy concerns, and may allow a malicious party to make better guesses about the presence of specific security holes. 5 Acknowledgments The details of the registration procedure in this document were directly adapted from [1]. Much of the text in section 3 was directly copied from this source. The idea of creating a vocabulary of areas of content features, maintained in a central open registry, is due to discussions on extensible negotiation mechanisms [3] in the IETF HTTP working group. The authors wish to thank Larry Masinter, Graham Klyne, Al Gilman, Dan Wing, Jacob Palme, and Martin Duerst for their contributions to discussions about feature tag registration. 6 References [1] N. Freed, J. Klensin, J. Postel, Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. RFC 2048, BCP 13, Network Working Group, November 1996 [2] G. Klyne, An algebra for describing media feature sets, Internet Draft: Work in progress March 1998 [3] Holtman, K., et al, "The Alternates Header Field", Internet-Draft draft-ietf-http-alternates-01.txt, Work in progress, November 1997. [4] Masinter, L., et al, "Media Features for Display, Print, and Fax", Internet-Draft draft-ietf-conneg-media-features-00.txt, Work in progress, March 1998. [5] Norten, T., et al, "Guidelines for Writing an IANA Considerations Section in RFCs", Internet Draft draft-iesg-iana-considerations-04.txt, Work in progress, May 1998. [6] Crocker, D., Ed., Augmented BNF for Syntax Specifications: ABNF. RFC 2234, Network Working Group, November 1997. 7 Authors' addresses Koen Holtman Technische Universiteit Eindhoven Postbus 513 Kamer HG 6.57 5600 MB Eindhoven (The Netherlands) Email: koen@win.tue.nl Andrew H. Mutz Hewlett-Packard Company 11000 Wolfe Rd. 42UO Cupertino CA 95014 USA Fax +1 408 447 4439 Email: andy_mutz@hp.com Edward Hardie NASA/STX MS 204-14 Moffett Field, CA 94035 USA hardie@archimedes.nasa.gov Appendix A: IANA and RFC editor to-do list VERY IMPORTANT NOTE: This appendix is intended to communicate various editorial and procedural tasks the IANA and the RFC Editor should undertake prior to publication of this document as an RFC. This appendix should NOT appear in the actual RFC version of this document! This document refers to the feature tags mailing list ietf-feature-tags@iana.org. This list does not exist at the present time and needs to be created. The ftp://ftp.isi.edu/in-notes/iana/assignments/feature-tags/ area does not exist at the present time and needs to be created. Expires: September 11, 1998 --PART-BOUNDARY=.19807021859.ZM16795.arc.nasa.gov-- From owner-ietf-medfree Fri Jul 3 04:02:35 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA11856 for ietf-medfree-bks; Fri, 3 Jul 1998 04:02:35 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id EAA11852 for ; Fri, 3 Jul 1998 04:02:34 -0700 (PDT) Received: (qmail 10967 invoked from network); 3 Jul 1998 11:02:08 -0000 Received: from userl688.uk.uudial.com (HELO GK.Group5.co.uk) (193.149.75.247) by smtp.dial.pipex.com with SMTP; 3 Jul 1998 11:02:08 -0000 Message-Id: <3.0.32.19980703114248.00a8d270@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 03 Jul 1998 12:01:19 +0100 To: hardie@archimedes.nasa.gov From: Graham Klyne Subject: Re: New -reg- draft Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 18:59 02/07/98 -0700, Ted Hardie wrote: >Attached is a new version of the registration draft, capturing the >changes associated with the items on our issues list. Among the >changes: [...] >-the term "feature bundle" has been introduced to described >sets of feature tags like pix-x and pix-y. Ted, I've just downloaded my e-mail, so I haven't reviewed the whole yet, but I wanted to respond to this bit quickly. I've been using the term "feature collection" quite extensively to describe what you seem to mean by a "feature bundle". It would be good to harmonize our terminology. To clarify (?) with a little formalism: Feature-tag = Feature-value = Boolean | symbol | string | number Feature-attr = PAIR( Feature-tag, Feature-value ) Feature-collection = FINITE-MAP( Feature-attr ) Feature-set = SET( Feature-collection ) ("FINITE-MAP" here refers to a set of ordered pairs in which no two member pairs have the same value for their first element. In this context, it can be used as a model for a function which maps a "Feature-tag" value to a "Feature-value".) So, does my "Feature collection" match your idea of "Feature bundle"? I can see a possible distinction: I have generally used "Feature collection" to mean the complete set of feature attributes of a given document; you might be using "feature bundle" to describe a subset of such features. Within the framework suggested, I'm not sure that this distinction is important. #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-medfree Mon Jul 6 10:21:07 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA16249 for ietf-medfree-bks; Mon, 6 Jul 1998 10:21:07 -0700 (PDT) Received: from 207.181.100.101 (stn-on1-37.netcom.ca [207.181.100.101]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA16244 for ; Mon, 6 Jul 1998 10:20:58 -0700 (PDT) Date: Mon, 6 Jul 1998 10:20:58 -0700 (PDT) Message-Id: <199807061720.KAA16244@mail.proper.com> From: dp3000@cheney.net To: @imc.org Subject: Online Marketing X-Reply-To: xroma@netcom.ca Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk ONLINE MARKETING - THE NEXT GENERATION OF ADVERTISING/MARKETING Complete Online Marketing Solutions: At Estroco Technologies, we provide all the tools necessary to promote your business/organization. Whether your goal is: to have people come to your website, or to prospect for orders of products, we can help. Note all prices are in US$ funds. We provide the following solutions: 1. Bulk Email Services Let us send out your ad for you. It can be of any length, but must not be illegal in nature, or be of a pornographic nature. The list below, is a general pricing. We can customize how many you want sent out. 100,000 - 200 200,000 - 345 400,000 - 875 600,000 - 1,100 800,000 - 1,300 1,000,000 - 1,400 2,000,000 - 2,200 2. WebSite Search Engine Promotion One key factor for getting people to go to your website, is to have your site on search engines. The more search engines you are listed on, the more hits from your attended audience you'll receive. When including this option, we need the following criteria: - website to be submitted - keywords to be used(max. 25) - Title of Web Site - 30 word description Also, we allow multiple submissions, which will allow maximum exposure. As well, ever so often, sites will bump your listing down so it is a good idea to have the same site, submitted at least once a month, to guarantee to maintain your listing at the top. Our prices: 100 engines & directories - 15.00 200 engines & directories - 25.00 500 engines & directories - 45.00 3. Email Lists Ok. So you want to do your own bulk emailings. Well, we have our own bulk emailing lists, which are cleaned of remove requests, flames, etc. Also, we have much more on stock. 500,000 - 220.00 1,000,000 - 350.00 4. Targeted Mailings & Targeted Email Lists We also have targeted email addresses, and also can retrieve targeted email addresses. Minimum order of 5,000, due to the large work involved. Prices are per 5,000 @ 100.00. For Targeted Mailings prices are per 5,000 as well. Per 5,000 @ $200.00. 5. Web Page Design Let us create your web page, with state of the art design & graphics. To get started on this, you will need to send us a proposal, either by email, fax, or snail mail. If possible please send us a competitive price so we can work out and negotiate the web site to be designed. 6. Customized Graphics We can customize any graphics you desire. For example do you need customized pictures, a company logo, a banner, or any type of graphical illustration. We can do all. Contact us on what you need, and we will reply with a price quote. 7. Bulk Email Software We are distributors for one of the best bulk email packages out there. Express Mail Server transforms your computer into a powerful mail server. Let us show you the benefits of this amazing software. As well, you can receive a free 3-day fully-functional demo, which will give you time to actually try out the program package. the program retails regularly for: $299, but if you mention this ad, we will give it to you for $225. 8. Web Page Maintenance We also can maintain your web page, and make changes as you require them. The prices can be negotiated on this. For further info. please email us, or phone us. 9. Credit Card Merchant Account We have arrangements with a major credit card processor, which will allow you to obtain a pre-approved merchant account. You can then accept credit cards on your web-site, or be able to receive orders, form email messages sent out, etc. They also have various other services that they provide. Email us for more information. Do you have a deal to make with us?? Send us some info. on your proposal and we will look at it. If we want to go from there, we will negotiate fairly. We are always coming out with new services and products. Do you have any new ideas that we can add to our extensive list of products/services. Drop us a line, and we will certainly look over it. If there's something that's not here, we probably came out with it, or will come out with it. Just contact us and we will see what we can do. How to order or Contact us: As stated above, prices are in US. Funds. We accept as payment, check, money order, or bank transfer. For check's and money orders please send to our postal address. For bank transfer's please email, or phone us, for further instructions. To place an order, send a proposal, or to discuss anything with us: Postal Address: Estroco Technologies 32983 Wills Road Wainfleet, Ontario, Canada L0S 1V0 Email: xroma@netcom.ca Phone/Fax: (905) 899-3508 Thanks for your attention and time Note: if you don't wish to receive further mailings, please respond to our email address stating this, and you will not receive any mailings from us or will not be place on any email lists, etc. You will just be transferred to our permanent remove list, which will guarantee you receive no mailings form us, or any mailings form lists sold by us. From owner-ietf-medfree Mon Jul 6 11:24:13 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA16718 for ietf-medfree-bks; Mon, 6 Jul 1998 11:24:13 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA16714 for ; Mon, 6 Jul 1998 11:24:12 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA20496; Mon, 6 Jul 1998 11:23:57 -0700 Date: Mon, 6 Jul 1998 11:23:57 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9807061123.ZM20494@thornhill.arc.nasa.gov> In-Reply-To: Graham Klyne "Re: New -reg- draft" (Jul 3, 12:01pm) References: <3.0.32.19980703114248.00a8d270@pop.dial.pipex.com> Reply-To: hardie@archimedes.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: Graham Klyne , hardie@archimedes.nasa.gov Subject: Re: New -reg- draft Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk Graham, Thanks for your quick reply, sorry that the Independence Day holiday kept me from replying. I agree that it would be a good idea to harmonize the terminology. I appreciate as well your formalization below. I introduced the term "feature bundle" to describe FINITE-MAP(feature-attr) because of Koen's note that the terminology was used inconsistently. Going back through, I realized that you and I had consistently used set and collection in opposite ways; I felt the best way around that was to introduce a new term. Bundle suggested itself to me because of the U.S usage of "software bundling". We can, of course, simply take the terms you have formalized below, and I am willing to do so if you prefer it. I merely felt it would be better to use a third term so that those who read the archives wouldn't presume they understood the current usage based on the muddle I had previously made of it. best regards, Ted Hardie NASA/STX On Jul 3, 12:01pm, Graham Klyne wrote: > Ted, > > I've just downloaded my e-mail, so I haven't reviewed the whole yet, but I > wanted to respond to this bit quickly. > > I've been using the term "feature collection" quite extensively to describe > what you seem to mean by a "feature bundle". It would be good to harmonize > our terminology. > > To clarify (?) with a little formalism: > > Feature-tag = > Feature-value = Boolean | symbol | string | number > Feature-attr = PAIR( Feature-tag, Feature-value ) > Feature-collection = FINITE-MAP( Feature-attr ) > Feature-set = SET( Feature-collection ) > > ("FINITE-MAP" here refers to a set of ordered pairs in which no two member > pairs have the same value for their first element. In this context, it can > be used as a model for a function which maps a "Feature-tag" value to a > "Feature-value".) > > So, does my "Feature collection" match your idea of "Feature bundle"? > > I can see a possible distinction: I have generally used "Feature > collection" to mean the complete set of feature attributes of a given > document; you might be using "feature bundle" to describe a subset of such > features. Within the framework suggested, I'm not sure that this > distinction is important. > > > #g > > ------------ > Graham Klyne > (GK@ACM.ORG) >-- End of excerpt from Graham Klyne From owner-ietf-medfree Mon Jul 6 11:28:51 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA16786 for ietf-medfree-bks; Mon, 6 Jul 1998 11:28:51 -0700 (PDT) Received: from wsooti08.win.tue.nl (wsooti08.win.tue.nl [131.155.70.156]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA16782 for ; Mon, 6 Jul 1998 11:28:49 -0700 (PDT) Received: from koen@localhost by wsooti08.win.tue.nl (8.8.7) id UAA27623. Mon, 6 Jul 1998 20:28:25 +0200 (MET DST) From: koen@win.tue.nl (Koen Holtman) Message-Id: <199807061828.UAA27623@wsooti08.win.tue.nl> Subject: Re: New -reg- draft To: hardie@archimedes.nasa.gov Date: Mon, 6 Jul 1998 20:28:25 +0200 (MET DST) Cc: ietf-medfree@imc.org In-Reply-To: <9807021859.ZM16795@thornhill.arc.nasa.gov> from "Ted Hardie" at Jul 2, 98 06:59:06 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ietf-medfree@imc.org Precedence: bulk Ted Hardie: > >Due to the press of work related to a product launch, Andy Mutz >will no longer be able to serve as editor for this draft. With the >consent of the Area Directors, I have tried to capture the consensus >of the group for this draft, and I hope that we can move it forward >with no further substantive changes. If there are extensive changes, >we will need another editor. Ted, The last edits are very much an improvement, but I feel that we are not finished yet. I have been trying to read the draft with the eye of a person new to registration, and I found a number of confusing things, especially with respect to terminology usage (is this a synonym or does the term refer to something more narrow or wider?) and with respect to the case of tags with no (or is it a boolean?) value. In stead of listing all the details, I volunteer to be the document editor for one editing pass over the document next weekend. Apart from legibility I have a few concerns of a more normative or procedural nature too, which I will discuss below, together with proposals on how to handle them. overall: - Terminology fluctuates between 'content feature tag' and 'feature tag'. I propose that we use 'content feature tag' consistently. I prefer 'content feature tag' because this would allow for the creation of 'foo feature tag' registries for other types of tags later. 2.1: - It has to be made clear that the discussion of feature bundles (or whatever they are called) is non-normative, because an RFC cannot make a normative reference to an internet draft. - The document does not discuss if and how the scope of the feature tag registry could be extended to cover non-content tags. I feel that at least a note on this is necessary, and propose: Note: It is possible that a future content negotiation mechanism will need tags which are outside the scope of the registry described by this document. In that case one of the possible alternatives would be to produce a revision of this document which extends the scope. Another alternative would be to create a new, independently managed namespace. 2.2: - the document does not define what the difference between strings and tokens is. Are tokens HTTP tokens? To allow interoperability between negotiation protocols, we MUST define the allowed chars in a token (or we can delete tokens and have only strings). - it would be good to mention that integers and rational numbers get the standard = and < operators by default, and that these need not be defined by the registrants. 3: - I notice that [5] is a normative reference to an internet draft. Are we sure that [5] will be and RFC in time? If so, we must instruct the RFC editor to supply the correct number. 3.1.1: - It is hugely preferable to explicitly disallow certain prefixes on IETF tags. I propose to disallow all single and two-letter prefixes. 3.1.2: - The draft should explain or refer to the procedure by which a producer can obtaining an IANA-approved designation of a producer's name. - the last sentence `may be placed by anyone' seems to contradict the preceding sentence. Should be 'may be proposed by anyone' I think. - I suspect the draft needs to include a contact e-mail address for the designated expert or something. We should cross-check with [5]. 3.1.3: - the spec needs to say that the string following 'u.' should be a legal URI. 3.4: - The To: address should be changed to reflect the procedures in [5]. - The three example sentences are confusing in their current form. - The `boolean/no value' and `with value' dichotomy is strange and confusing, especially for those who do not know TCN. When I made the first draft of the registration template about 2 years ago, the template was for TCN only, and at that point the dichotomy made some sense because the TCN protocol 'overloads' its boolean type to indicate 'unknown tag' too. There is no guarantee that other protocols would use similar hack, so I would be happier if we forget about the 'no value' special case and call these tags 'boolean' in the registration form, with the notes that - representation of the boolean tag value is negotiation protocol dependent - to enhance interoperability between negotiation protocols, the registrar should define 'false' to be the tag value which corresponds to 'feature not present or needed' in case the boolean tag refers to the presence or need of some single feature. - the 'integer' type does not specify signed or unsigned. This is important for at least some protocols however. TCN can only do range processing for unsigned integers. It would even be a bigger issue in binary-encoded negotiation protocols. I propose to make a distinction between signed and unsigned integer on the form. - The 'expected value or behavior in the absence of the feature tag' question is a remnant from the TCN-only days and should be deleted. - In the security considerations question, the layout is a bit unclear. Can one put text immediately below security considerations? - The IANA publication delay question should be removed. The use case for this can now be handled by URI tags, and leaving it in would require that we define who may or may not see the tag before the publication delay is over (can the mailing list of the designated expert see it?). 6: reference [3] does not actually contain anything about feature tags. This should be a reference to RFC 2295. Koen. From owner-ietf-medfree Mon Jul 6 15:48:32 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA18894 for ietf-medfree-bks; Mon, 6 Jul 1998 15:48:32 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA18890 for ; Mon, 6 Jul 1998 15:48:31 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA20832; Mon, 6 Jul 1998 15:48:20 -0700 Date: Mon, 6 Jul 1998 15:48:20 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9807061548.ZM20830@thornhill.arc.nasa.gov> In-Reply-To: koen@win.tue.nl (Koen Holtman) "Re: New -reg- draft" (Jul 6, 8:28pm) References: <199807061828.UAA27623@wsooti08.win.tue.nl> Reply-To: hardie@archimedes.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: koen@win.tue.nl (Koen Holtman), hardie@archimedes.nasa.gov Subject: Re: New -reg- draft Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk Koen, Thanks for your comments below. I've made some replies or requests for clarification in them. regards, Ted Hardie NASA/STX On Jul 6, 8:28pm, Koen Holtman wrote: > > Ted, > > The last edits are very much an improvement, but I feel that we are > not finished yet. I have been trying to read the draft with the eye > of a person new to registration, and I found a number of confusing > things, especially with respect to terminology usage (is this a > synonym or does the term refer to something more narrow or wider?) and > with respect to the case of tags with no (or is it a boolean?) value. > In stead of listing all the details, I volunteer to be the document > editor for one editing pass over the document next weekend. > > Apart from legibility I have a few concerns of a more normative or > procedural nature too, which I will discuss below, together with > proposals on how to handle them. > > overall: > > - Terminology fluctuates between 'content feature tag' and 'feature > tag'. I propose that we use 'content feature tag' consistently. I > prefer 'content feature tag' because this would allow for the > creation of 'foo feature tag' registries for other types of tags > later. I agree that it should not fluctuate; my apologies for not catching all of the disagreements. I believe that it would be better to use the terminology "feature tag" or "media feature tag", rather than "content feature tag", since that can imply variable content rather than variable presentation. I'll go through and correct these. > 2.1: > > - It has to be made clear that the discussion of feature bundles (or > whatever they are called) is non-normative, because an RFC cannot > make a normative reference to an internet draft. I'll make sure that the references fit the case. We need to make sure that readers understand that feature bundles (or whathever) are possible and that there is ongoing work to define them. I'll check around to see how to do that. > - The document does not discuss if and how the scope of the feature > tag registry could be extended to cover non-content tags. I feel > that at least a note on this is necessary, and propose: > > Note: It is possible that a future content negotiation mechanism > will need tags which are outside the scope of the registry > described by this document. In that case one of the possible > alternatives would be to produce a revision of this document which > extends the scope. Another alternative would be to create a new, > independently managed namespace. The registry being created by this group is bounded and that bounding must remain very clear. Discussions of how it might change or other registries might come into existence in the future don't do any good for readers trying to build applications now, and could muddy the waters pretty considerably. I believe that we can consider any later registration outside of the current bounds to be part of a different registry (whether parallel or successor is someone else's problem). For the mechanism documents, I agree that we want to make clear that the use of these media feature tags does not preclude the use of the same negotiation mechanisms with other tags. > > 2.2: > > - the document does not define what the difference between strings and > tokens is. Are tokens HTTP tokens? To allow interoperability > between negotiation protocols, we MUST define the allowed chars in a > token (or we can delete tokens and have only strings). I was presuming HTTP tokens, and I will add language documenting that, unless there is a different interpretation. > > - it would be good to mention that integers and rational numbers > get the standard = and < operators by default, and that these need > not be defined by the registrants. Good idea, I'll put it in. > > 3: > > - I notice that [5] is a normative reference to an internet draft. > Are we sure that [5] will be and RFC in time? If so, we must > instruct the RFC editor to supply the correct number. The RFC editor will catch this. > > 3.1.1: > > - It is hugely preferable to explicitly disallow certain prefixes on > IETF tags. I propose to disallow all single and two-letter > prefixes. Could you explain more why this is hugely preferable? I agree that anything that looked like a faceting would be confusing, but I believe that the IETF process would catch anything that did. > > 3.1.2: > > - The draft should explain or refer to the procedure by which a > producer can obtaining an IANA-approved designation of a producer's > name. My reading of this was that the proposer proposed something like: g.NASA.coordinate-series or g.coordinate-series and that IANA, via the designated expert, accepted the name or didn't. This would normally be via consultation with the proposer. I don't think you would go to IANA in advance of registration to get a designation. I do think, on the other hand, that IANA might ask that you keep the same designation currently in use in the v. tree of the MIME media registration. Given that this is done by consultation, I'm leary to put too strict a procedure here. Any suggestions on better language for this? > - the last sentence `may be placed by anyone' seems to contradict the > preceding sentence. Should be 'may be proposed by anyone' I think. I'll take a run at this. > - I suspect the draft needs to include a contact e-mail address for > the designated expert or something. We should cross-check with > [5]. This is handled by IANA; there is no need to specify it in the draft. > > 3.1.3: > > - the spec needs to say that the string following 'u.' should be a > legal URI. > > 3.4: > > - The To: address should be changed to reflect the procedures in [5]. > > - The three example sentences are confusing in their current form. > > - The `boolean/no value' and `with value' dichotomy is strange and > confusing, especially for those who do not know TCN. When I made > the first draft of the registration template about 2 years ago, the > template was for TCN only, and at that point the dichotomy made some > sense because the TCN protocol 'overloads' its boolean type to > indicate 'unknown tag' too. There is no guarantee that other > protocols would use similar hack, so I would be happier if we forget > about the 'no value' special case and call these tags 'boolean' in > the registration form, with the notes that > > - representation of the boolean tag value is negotiation > protocol dependent > > - to enhance interoperability between negotiation protocols, the > registrar should define 'false' to be the tag value which > corresponds to 'feature not present or needed' in case the > boolean tag refers to the presence or need of some single > feature. I tend to believe that "present=yes" is not very good design. What will break if we switch this to requiring True/False values for booleans? > > - the 'integer' type does not specify signed or unsigned. This is > important for at least some protocols however. TCN can only do > range processing for unsigned integers. It would even be a bigger > issue in binary-encoded negotiation protocols. I propose to make a > distinction between signed and unsigned integer on the form. I was assuming signed integers. Is there anything deployed that can't handle a signed integers, so that we must have both a signed and unsigned integer data type? > > - The 'expected value or behavior in the absence of the feature tag' > question is a remnant from the TCN-only days and should be deleted. > > - In the security considerations question, the layout is a bit > unclear. Can one put text immediately below security > considerations? > > - The IANA publication delay question should be removed. The use case > for this can now be handled by URI tags, and leaving it in would > require that we define who may or may not see the tag before the > publication delay is over (can the mailing list of the designated > expert see it?). Actually, it remains useful. There are situations where a tag may not be appropriate for full release, but will benefit from the review of a global tag. > > > 6: > > reference [3] does not actually contain anything about feature tags. > This should be a reference to RFC 2295. > > > Koen. >-- End of excerpt from Koen Holtman Thanks for all your comments. Given the short time line, I plan to release another draft by Thursday, so that we can keep moving forward. Further comments welcome, of course, regards, Ted Hardie From owner-ietf-medfree Tue Jul 7 02:22:52 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA05101 for ietf-medfree-bks; Tue, 7 Jul 1998 02:22:52 -0700 (PDT) Received: from wsooti08.win.tue.nl (wsooti08.win.tue.nl [131.155.70.156]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA05097 for ; Tue, 7 Jul 1998 02:22:49 -0700 (PDT) Received: from koen@localhost by wsooti08.win.tue.nl (8.8.7) id LAA11224. Tue, 7 Jul 1998 11:22:36 +0200 (MET DST) From: koen@win.tue.nl (Koen Holtman) Message-Id: <199807070922.LAA11224@wsooti08.win.tue.nl> Subject: Re: New -reg- draft To: hardie@archimedes.nasa.gov Date: Tue, 7 Jul 1998 11:22:35 +0200 (MET DST) Cc: koen@win.tue.nl, ietf-medfree@imc.org In-Reply-To: <9807061548.ZM20830@thornhill.arc.nasa.gov> from "Ted Hardie" at Jul 6, 98 03:48:20 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ietf-medfree@imc.org Precedence: bulk Ted Hardie: > >Koen, > Thanks for your comments below. I've made some >replies or requests for clarification in them. > regards, > Ted Hardie > NASA/STX Ted, I am about to go on a trip until sunday, so I'll limit myself to a few quick comments. >On Jul 6, 8:28pm, Koen Holtman wrote: >I agree that it should not fluctuate; my apologies for not catching >all of the disagreements. Please check for the fluctuation in the terms which designate a 'negotiation mechanism' too. >> - I notice that [5] is a normative reference to an internet draft. >> Are we sure that [5] will be and RFC in time? If so, we must >> instruct the RFC editor to supply the correct number. > >The RFC editor will catch this. The IESG will probably catch this already and send back the document for another editing cycle if we are unlucky. >> 3.1.1: >> >> - It is hugely preferable to explicitly disallow certain prefixes on >> IETF tags. I propose to disallow all single and two-letter >> prefixes. > >Could you explain more why this is hugely preferable? It would make adding new namespaces much more easy, and would allow semi-inteligent protocol processors to anticipate. > I agree >that anything that looked like a faceting would be confusing, I certainly expect some application specific IETF tags to use faceting. >but I believe that the IETF process would catch anything that >did. The IETF process should not be used to catch things which can be caught much earlier along the way, with much less effort for everyone involved, by giving explicit instructions to the working groups inventing new tags. >> 3.1.2: >> >> - The draft should explain or refer to the procedure by which a >> producer can obtaining an IANA-approved designation of a producer's >> name. > >My reading of this was that the proposer proposed something like: > >g.NASA.coordinate-series > >or > >g.coordinate-series > >and that IANA, via the designated expert, accepted the name or didn't. My reading is that the proposer should somehow get IANA approval before submitting the tag. I like your reading better, so please fix it to make it unambiguous to follow your reading. >This would normally be via consultation with the proposer. I don't >think you would go to IANA in advance of registration to get a designation. >I do think, on the other hand, that IANA might ask that you keep the >same designation currently in use in the v. tree of the MIME media >registration. > >Given that this is done by consultation, I'm leary to put too strict >a procedure here. Any suggestions on better language for this? Put a description of how you expect things to go in the usual case in a non-normative note. That usually works. I agree that it would be bad to put in a very strict procedure, but on the other hand the newcomer to the process does need some background information on what to expect. I found a note to be a good device for this kind of thing. >> - I suspect the draft needs to include a contact e-mail address for >> the designated expert or something. We should cross-check with >> [5]. > >This is handled by IANA; there is no need to specify it in the draft. As long as it is made clear who I should contact to propose a tag, I am happy. >> - The `boolean/no value' and `with value' dichotomy is strange and >> confusing, especially for those who do not know TCN. When I made >> the first draft of the registration template about 2 years ago, the >> template was for TCN only, and at that point the dichotomy made some >> sense because the TCN protocol 'overloads' its boolean type to >> indicate 'unknown tag' too. There is no guarantee that other >> protocols would use similar hack, so I would be happier if we forget >> about the 'no value' special case and call these tags 'boolean' in >> the registration form, with the notes that >> >> - representation of the boolean tag value is negotiation >> protocol dependent >> >> - to enhance interoperability between negotiation protocols, the >> registrar should define 'false' to be the tag value which >> corresponds to 'feature not present or needed' in case the >> boolean tag refers to the presence or need of some single >> feature. > >I tend to believe that "present=yes" is not very good design. In what way is it not good design? I am confused on whether you mean syntax or semantics here. >What will break if we switch this to requiring True/False >values for booleans? The use of the term boolean already implies a two-value tag in my reading. I am not sure what your question is. >> - the 'integer' type does not specify signed or unsigned. This is >> important for at least some protocols however. TCN can only do >> range processing for unsigned integers. It would even be a bigger >> issue in binary-encoded negotiation protocols. I propose to make a >> distinction between signed and unsigned integer on the form. > >I was assuming signed integers. Is there anything deployed that >can't handle a signed integers, so that we must have both a signed >and unsigned integer data type? TCN is kind-of deployed, but it has no explicit typing and will therefore not break very much if we do not have an explicit unsigned type. It is necessary in my view though to make it clear whether 'integer' in the form implies unsigned or not. Else people writing binary protocols will have a hard time working things out. >> - The IANA publication delay question should be removed. The use case >> for this can now be handled by URI tags, and leaving it in would >> require that we define who may or may not see the tag before the >> publication delay is over (can the mailing list of the designated >> expert see it?). > >Actually, it remains useful. There are situations where a tag >may not be appropriate for full release, but will benefit from >the review of a global tag. You are implying a closed doors review process, which is kind of counter to the IETF traditions. I feel that the procedural hassle involved will not outhweigh the benefits. If you feel differently, you must at least add more language to the spec to describe what level of secrecy this publication delay implies exactly. Remember that the drafts is to supposed to give algorithms for IANA to use. There used to be more language in about this at some point but right now the form is the only place where the term is used at all. Koen. From owner-ietf-medfree Tue Jul 7 07:33:35 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA10016 for ietf-medfree-bks; Tue, 7 Jul 1998 07:33:35 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA10011 for ; Tue, 7 Jul 1998 07:33:34 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA02756; Tue, 7 Jul 1998 10:32:57 -0400 (EDT) Message-Id: <199807071432.KAA02756@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-ietf-conneg-feature-reg-01.txt Date: Tue, 07 Jul 1998 10:32:57 -0400 Sender: owner-ietf-medfree@imc.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Negotiation Working Group of the IETF. Title : Content Feature Tag Registration Procedure Author(s) : E. Hardie, K. Holtman, A. Mutz Filename : draft-ietf-conneg-feature-reg-01.txt Pages : 10 Date : 06-Jul-98 Recent Internet applications, such as the World Wide Web, tie together a great diversity in data formats, client and server platforms, and communities. This has created a need for content feature descriptions and negotiation mechanisms in order to identify and reconcile the form of information to the capabilities and preferences of the parties involved. Extensible content feature identification and negotiation mechanisms require a common vocabulary in order to positively identify content features. A registration process and authority for content features is defined with the intent of sharing this vocabulary between communicating parties. In addition, a URI tree is defined to enable sharing of content feature definitions without registration. This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the content feature vocabulary. Internet-Drafts are 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-ietf-conneg-feature-reg-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-conneg-feature-reg-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-conneg-feature-reg-01.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: <19980706162915.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-conneg-feature-reg-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-conneg-feature-reg-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980706162915.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-medfree Tue Jul 7 07:47:07 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA10232 for ietf-medfree-bks; Tue, 7 Jul 1998 07:47:07 -0700 (PDT) Received: from ar.rzeszow.pl ([194.92.134.130]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA10228 for ; Tue, 7 Jul 1998 07:47:02 -0700 (PDT) Received: from Ben by ar.rzeszow.pl (SMI-8.6/SMI-SVR4.001) id QAA14640; Tue, 7 Jul 1998 16:36:52 +0200 Organization: Akademia Rolnicza Date: Tue, 7 Jul 1998 16:36:52 +0200 To: meuhiolio89@aol.com From: meuhiolio89@aol.com (Your Home Town) Comments: Authenticated sender is Subject: Your Home Town Provides Everything You Need Message-Id: <199807064477JAA16446@base.ar.rzeszow.pl> Sender: owner-ietf-medfree@imc.org Precedence: bulk YOUR HOME TOWN WILL DO 100% OF THE WORK FOR YOU WE OFFER: You the chance to own your own Home Based Business. WE OFFER: To build your Home Based Business for you. WE OFFER You financial independence. WE OFFER: You life saving and life changing products. WE OFFER: You the easiest way we know to, improve your Health, your Wealth and your Happiness. For more information Call: Our toll free 24 hr message center at 888-771-9338 Our toll free 24 hr recorded message at 888-771-9340. Reference # 1007698 our research showed you would be interested in this subject. If this is not true and you would like to be removed from our data base please call 888-771-9338 and leave your e-mail address for remov From owner-ietf-medfree Tue Jul 7 12:53:30 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA17447 for ietf-medfree-bks; Tue, 7 Jul 1998 12:53:30 -0700 (PDT) Received: from pdavis.net (ad75-212.arl.compuserve.com [199.174.200.212]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA17442 for ; Tue, 7 Jul 1998 12:53:11 -0700 (PDT) From: Internet-Drafts@ietf.org Received: from mail.well.com [206.15.64.22] by pdavis.net [127.0.0.1] with POP (MDaemon.v2.7.SP3.T) for ; Tue, 07 Jul 1998 14:10:19 -0400 Received: from smtp.well.com (nobody@smtp.well.com [206.80.6.147]) by mail.well.com (8.8.5/8.8.5) with ESMTP id JAA24706 for ; Tue, 7 Jul 1998 09:00:43 -0700 (PDT) Received: from centauri.netnames.net (centauri.netnames.net [195.40.151.250]) by smtp.well.com (8.8.6/8.8.4) with ESMTP id JAA02882 for ; Tue, 7 Jul 1998 09:00:29 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by centauri.netnames.net (8.8.7/8.8.7) with ESMTP id RAA18155 for ; Tue, 7 Jul 1998 17:00:34 +0100 (BST) Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id LAA03833 for ietf-123-outbound.09@ietf.org; Tue, 7 Jul 1998 11:05:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA02756; Tue, 7 Jul 1998 10:32:57 -0400 (EDT) Message-Id: <199807071432.KAA02756@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-medfree@imc.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-conneg-feature-reg-01.txt Date: Tue, 07 Jul 1998 10:32:57 -0400 X-UIDL: 690053b6136326d7404fb73f47af787b X-MDaemon-Deliver-To: ietf-medfree@imc.org Sender: owner-ietf-medfree@imc.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Negotiation Working Group of the IETF. Title : Content Feature Tag Registration Procedure Author(s) : E. Hardie, K. Holtman, A. Mutz Filename : draft-ietf-conneg-feature-reg-01.txt Pages : 10 Date : 06-Jul-98 Recent Internet applications, such as the World Wide Web, tie together a great diversity in data formats, client and server platforms, and communities. This has created a need for content feature descriptions and negotiation mechanisms in order to identify and reconcile the form of information to the capabilities and preferences of the parties involved. Extensible content feature identification and negotiation mechanisms require a common vocabulary in order to positively identify content features. A registration process and authority for content features is defined with the intent of sharing this vocabulary between communicating parties. In addition, a URI tree is defined to enable sharing of content feature definitions without registration. This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the content feature vocabulary. Internet-Drafts are 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-ietf-conneg-feature-reg-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-conneg-feature-reg-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-conneg-feature-reg-01.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: <19980706162915.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-conneg-feature-reg-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-conneg-feature-reg-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980706162915.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-medfree Tue Jul 7 23:46:14 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA25650 for ietf-medfree-bks; Tue, 7 Jul 1998 23:46:14 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA25646 for ; Tue, 7 Jul 1998 23:46:13 -0700 (PDT) Received: (qmail 28813 invoked from network); 8 Jul 1998 06:46:11 -0000 Received: from usero463.uk.uudial.com (HELO GK.Group5.co.uk) (193.149.88.225) by smtp.dial.pipex.com with SMTP; 8 Jul 1998 06:46:11 -0000 Message-Id: <3.0.32.19980707235830.007a0b30@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 08 Jul 1998 07:45:17 +0100 To: hardie@archimedes.nasa.gov From: Graham Klyne Subject: Re: New -reg- draft Cc: koen@win.tue.nl (Koen Holtman), hardie@archimedes.nasa.gov, ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 15:48 06/07/98 -0700, Ted Hardie wrote: >> - to enhance interoperability between negotiation protocols, the >> registrar should define 'false' to be the tag value which >> corresponds to 'feature not present or needed' in case the >> boolean tag refers to the presence or need of some single >> feature. > >I tend to believe that "present=yes" is not very good design. >What will break if we switch this to requiring True/False >values for booleans? I agree here -- in my work on the -algebra- draft I explicitly reject a 'presence' test because it does not fit well with the overall selection model. The use of an explicit Boolean can achieve the same semantics. Also note Larry's comments about "feature incapabilities", and the idea that capability statements are a restruction on what is otherwise presumed to be unbounded capability. >I was assuming signed integers. Is there anything deployed that >can't handle a signed integers, so that we must have both a signed >and unsigned integer data type? I'd say this was a natural part of specifiying the range of applicable values (thougbh some reminder to indicate signed/non-signed would probably be a good idea). #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-medfree Wed Jul 8 08:10:39 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA14597 for ietf-medfree-bks; Wed, 8 Jul 1998 08:10:39 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA14590 for ; Wed, 8 Jul 1998 08:10:36 -0700 (PDT) Received: (qmail 7042 invoked from network); 8 Jul 1998 15:10:36 -0000 Received: from userl241.uk.uudial.com (HELO GK) (193.149.74.54) by smtp.dial.pipex.com with SMTP; 8 Jul 1998 15:10:36 -0000 Message-Id: <3.0.32.19980708111348.007ad830@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 08 Jul 1998 16:09:42 +0100 To: hardie@archimedes.nasa.gov From: Graham Klyne Subject: Re: New -reg- draft Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk [Resend: first time got bounced. Sorry for any duplicates.] At 11:23 06/07/98 -0700, Ted Hardie wrote: >[...] Going back through, I realized that you and >I had consistently used set and collection in opposite ways; I felt the >best way around that was to introduce a new term. Bundle suggested >itself to me because of the U.S usage of "software bundling". > We can, of course, simply take the terms you have formalized >below, and I am willing to do so if you prefer it. I merely felt it would >be better to use a third term so that those who read the archives wouldn't >presume they understood the current usage based on the muddle I >had previously made of it. I have a fair volume of draft material (terminology/framework and -algebra-) that uses the terms in the sense I have defined. I could go through these and change them if it is felt that some alternative phrasing is clearer, but I'm less keen to do so for the sake of change. #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-medfree Wed Jul 8 14:11:16 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA18212 for ietf-medfree-bks; Wed, 8 Jul 1998 14:11:16 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA18208 for ; Wed, 8 Jul 1998 14:11:14 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA23525; Wed, 8 Jul 1998 14:11:10 -0700 Date: Wed, 8 Jul 1998 14:11:10 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9807081411.ZM23523@thornhill.arc.nasa.gov> In-Reply-To: Graham Klyne "Re: New -reg- draft" (Jul 7, 11:19pm) References: <3.0.32.19980706235036.009c0390@pop.dial.pipex.com> Reply-To: hardie@archimedes.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: Graham Klyne Subject: Re: New -reg- draft Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-medfree@imc.org Precedence: bulk Graham, I'll go back and restore your terminology, including the formalization you gave in your previous message on this topic. regards, Ted > I have a fair volume of draft material (terminology/framework and > -algebra-) that uses the terms in the sense I have defined. I could go > through these and change them if it is felt that some alternative phrasing > is clearer, but I'm less keen to do so for the sake of change. > > #g > > ------------ > Graham Klyne > (GK@ACM.ORG) >-- End of excerpt from Graham Klyne From owner-ietf-medfree Wed Jul 8 14:11:26 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA18222 for ietf-medfree-bks; Wed, 8 Jul 1998 14:11:26 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA18217 for ; Wed, 8 Jul 1998 14:11:24 -0700 (PDT) Received: (qmail 24100 invoked from network); 8 Jul 1998 21:11:25 -0000 Received: from usern981.uk.uudial.com (HELO GK) (193.149.86.252) by smtp.dial.pipex.com with SMTP; 8 Jul 1998 21:11:25 -0000 Message-Id: <3.0.32.19980708220836.011e7d10@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 08 Jul 1998 22:10:31 +0100 To: conneg WG From: Graham Klyne Subject: draft-ietf-conneg-feature-algebra-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk Hi all, I've finally sweated out a new version of the -algebra- draft, which I shall be submitting for I-D publication today. The biggest difference is that I've done an outline of a feature set matching algorithm. It's pretty clumsy at the moment and could do with a lot of refinement (not to mention completion of some of the details), but I thought it was important to have an outline for such an algorithm before I posted the next round of feature syntax proposals. I've also added some possible extensions to the syntax (described separately) and some feature set examples. For those who are just interested in the syntax, the core material is in chapter 6. Chapter 7 covers development of the feature matching algorithm, and gets a bit heavy in places. But it can be skipped if your primary concern is representation. #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-medfree Thu Jul 9 04:45:01 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA09007 for ietf-medfree-bks; Thu, 9 Jul 1998 04:45:01 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA09000 for ; Thu, 9 Jul 1998 04:45:00 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA01387; Thu, 9 Jul 1998 07:44:32 -0400 (EDT) Message-Id: <199807091144.HAA01387@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-ietf-conneg-feature-algebra-02.txt Date: Thu, 09 Jul 1998 07:44:31 -0400 Sender: owner-ietf-medfree@imc.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Negotiation Working Group of the IETF. Title : An algebra for describing media feature sets Author(s) : G. Klyne Filename : draft-ietf-conneg-feature-algebra-02.txt Pages : 43 Date : 08-Jul-98 This document describes an algebra and syntax that can be used to define feature sets which are formed from combinations and relations involving individual media features. Such feature sets are used to describe the media feature handling capabilities of message senders, recipients and file formats. Internet-Drafts are 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-ietf-conneg-feature-algebra-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-conneg-feature-algebra-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-conneg-feature-algebra-02.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: <19980708111201.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-conneg-feature-algebra-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-conneg-feature-algebra-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980708111201.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-medfree Thu Jul 9 17:20:09 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA14778 for ietf-medfree-bks; Thu, 9 Jul 1998 17:20:09 -0700 (PDT) Received: from thornhill.arc.nasa.gov (thornhill.arc.nasa.gov [128.102.33.38]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA14774 for ; Thu, 9 Jul 1998 17:20:07 -0700 (PDT) Received: (from hardie@localhost) by thornhill.arc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA24901 for ietf-medfree@imc.org; Thu, 9 Jul 1998 17:20:11 -0700 Date: Thu, 9 Jul 1998 17:20:11 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9807091720.ZM24899@thornhill.arc.nasa.gov> Reply-To: hardie@archimedes.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: ietf-medfree@imc.org Subject: New -reg- draft Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19807091720.ZM24899.arc.nasa.gov" Sender: owner-ietf-medfree@imc.org Precedence: bulk -- --PART-BOUNDARY=.19807091720.ZM24899.arc.nasa.gov Content-Type: text/plain; charset=us-ascii Based on editorial comments by Graham and Koen, I made some changes to the -reg- draft and the enclosed version went up to the drafts editor today. The basic changes are: -reverted to Graham's use of feature collection -substituted "media feature" for "content feature" -made it explicit that integers were signed -gave an explicit definition of tokens -added advice on avoiding implication of faceting for tags in the global tree -fixed IANA directory and mailing list names -updated references Please read the draft carefully and comment as soon as possible. regards, Ted Hardie NASA/STX --PART-BOUNDARY=.19807091720.ZM24899.arc.nasa.gov X-Zm-Content-Name: draft-ietf-conneg-feature-reg-02.txt Content-Description: Text Content-Type: text/plain ; name="draft-ietf-conneg-feature-reg-02.txt" ; charset=us-ascii CONNEG Working Group Koen Holtman, TUE Internet-Draft Andrew Mutz, Hewlett-Packard Expires: January, 1999 Ted Hardie, NASA/STX July, 1998 Content Feature Tag Registration Procedure draft-ietf-conneg-feature-reg-02.txt STATUS OF THIS MEMO This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Copyright (C) The Internet Society (1998). All Rights Reserved. Distribution of this document is unlimited. Please send comments to the CONNEG working group at . Discussions of the working group are archived at . ABSTRACT Recent Internet applications, such as the World Wide Web, tie together a great diversity in data formats, client and server platforms, and communities. This has created a need for media feature descriptions and negotiation mechanisms in order to identify and reconcile the form of information to the capabilities and preferences of the parties involved. Extensible media feature identification and negotiation mechanisms require a common vocabulary in order to positively identify media features. A registration process and authority for media features is defined with the intent of sharing this vocabulary between communicating parties. In addition, a URI tree is defined to enable sharing of media feature definitions without registration. This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary. TABLE OF CONTENTS 1 Introduction 2 Media feature tag definitions 2.1 Media eature tag purpose 2.2 Media feature tag syntax 3 Media feature tag registration 3.1 Registration trees 3.1.1 IETF tree 3.1.2 Global tree 3.1.3 URL tree 3.1.4 Additional registration trees 3.2 Location of registered media feature tag list 3.3 IANA procedures for registering media feature tags 3.4 Registration template 4 Security considerations 5 Acknowledgments 6 References 7 Authors' addresses Appendix A: IANA and RFC editor to-do list 1 Introduction Recent Internet applications, such as the World Wide Web, tie together a great diversity in data formats, client and server platforms, and communities. This has created a need for media feature descriptions and negotiation mechanisms in order to identify and reconcile the form of information to the capabilities and preferences of the parties involved. Extensible media feature identification and negotiation mechanisms require a common vocabulary in order to positively identify media features. A registration process and authority for media features is defined with the intent of sharing this vocabulary between communicating parties. In addition, a URI tree is defined to enable sharing of media feature definitions without registration. This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary. This document uses the terms MUST, MUST NOT, SHOULD, SHOULD NOT and MAY according to usage described in [8]. 2 Media feature tag definitions 2.1 Media feature tag purpose Media feature tags represent individual and simple dimensions of feature capability. Examples of features related to media are: * the color depth of the screen on which something is to be displayed * the type of paper available in a printer * the support of the `floating 5 dimensional tables' feature * the fonts which are available to the recipient * the capability to display graphical content A media feature tag identifies a single dimension of characteristic. Tag values should use the data types defined in 2.3. Examples of media feature tags with values are: * the width of a display in pixels per centimeter represented as an integer value. * the fonts available to a recipient as an enumerated list. * the version of a protocol composed of integers "i.j.k", defined as either a value in an enumerated list or with a defined mapping to make the value isomorphic to a subset of integers (e.g. i*100 + j*10 +k, assuming j<=9 and k<=9). Further examples of media feature tags are defined in detail elsewhere [4]. Feature collections may be composed using a number of individual feature tags [2]. Composition of feature collections is described elsewhere [2]. Examples of feature collections requiring multiple media feature tags are: * the width and height of a display * the combination of color depth and resolution a display can support This registry presumes the availability of the MIME media type registry, and MIME media types MUST NOT be re-registered as media feature tags. Media feature tags which are currently in use by individual protocols or applications MAY be registered with this registry if they might be applied outside of their current domain. The media feature tag namespace is not bound to a particular transport protocol or capability exchange mechanism. The registry is limited, however, to feature tags which express a capability or preference related to how content is presented. Feature tags related to other axes of negotiation are not appropriate for this registry. Capability exchange mechanisms may, of course, be used to express a variety of capabilities or preferences. 2.2 Media feature tag syntax A media feature tag is a string consisting of one or more of the following US-ASCII characters: uppercase letters, lowercase letters, digits, colon (":"), slash ("/"), dot (".") percent ("%"), and dash ("-"). Feature tags are case-insensitive. Dots are understood to potentially imply heirarchy; a feature can be subtyped by describing it as tree.feature.subfeature and by indicating this in the registration. Tags should begin with an alphabetic character. In ABNF [6], this may be represented as: Feature-tag = ALPHA *( ALPHA / DIGIT / ":" / "/" / "." / "-" /"%" ) Registrants should take care to avoid creating tags which might conflict with the creation of new registration trees; in general this means avoiding tags which begin with an alphabetic character followed by a dot. The current registration trees are described in section 3 below. 2.3 Media feature tag values The registry will initially support the use of the following data types as tag values: - signed integers - rational numbers - tokens, with equality relationship - strings, with equality relationship - strings, with defined comparison - ordered tokens "Token" here means the token data type as defined by [7], which may be summarized as: token = 1* tspecials = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT At the time of registration, each tag must be associated with a single data type. If that data type implies a defined comparison or an ordering, the registrant must define the ordering or comparison. For ordered tokens, this may be by full enumeration of the tokens and their order or by reference to an ordering mechanism. For defined comparisons, a full description of the rules for comparison must be provided or included by reference. Media feature tags related to spatial or temporal characteristics must be registered with a single canonical unit. It is strongly preferred that units be in the SI system; where current practice has defined units in other systems (such as pixels per inch), a conversion method to SI units must be provided. Conversion methods should include a defined rounding practice. 2.3 ASN.1 identifiers for media feature tags Certain protocols use ASN.1 identifiers rather than human-readable representations for capability exchange. In order to allow both systems to interoperate, registrants may provide an ASN.1 identifier or ask that IANA assign an ASN.1 identifier during registration. These identifiers are not required for registration, but may provide assistance to those building gateways or other cross-protocol systems. Note that ASN.1 identifiers assigned by IANA will be treated as tokens, not as elements from which sub-delegated identifiers may be created or derived. 3 Media feature tag registration Media feature tags can be registered in several different registration trees, with different requirements as discussed below. The vocabulary for these requirements is taken from [5]. In general, a feature tag registration proposal is circulated and reviewed in a fashion appropriate to the tree involved. The feature tag is then registered if the proposal is accepted. Review of a feature tag in the URI tree is not required. 3.1 Registration trees The following subsections define registration "trees", distinguished by the use of faceted names (e.g., names of the form "tree.feature- name"). 3.1.1 IETF tree The IETF tree is intended for media feature tags of general interest to the Internet Community, and proposals for these tags must meet the "IETF Consensus" policies described in [5]. Registration in the IETF tree requires approval by the IESG and publication of the feature tag specification as an RFC. Submissions for feature tag registration in the IETF tree can originate in any WG of the IETF or as an individual submission to the IESG. Feature tags in the IETF tree normally have names that are not explicitly faceted, i.e., do not contain period (".", full stop) characters. 3.1.2 Global tree Tags in the global tree will be distinguished by the leading facet "g.". An organization may propose either a designation indicative of the feature, (e.g., "g.blinktags") or a faceted designation including the organization name (e.g., "g.organization.blinktags"). Organizations which have registered media types under the MIME vendor tree should use the same organizational name for media feature tags if they propose a faceted designation. The acceptance of the proposed designation is at the discretion of the IANA. If the IANA believes that a designation needs clarification it may request a new proposal from the proposing organization or otherwise coordinate the development of an appropriate designation. Registrations of feature tags in the global tree must meet the "Expert Review" policies described in [5]. In this case, a designated area expert will review the proposed tag, consulting with the members of a related mailing list. A registration may be proposed for the global tree by anyone who has the need to allow for communication on a particular capability or preference. 3.1.3 URI tree A feature tag may be defined as a URI using the restricted character set defined above. Feature tags in the URI tree are identified by the leading facet "u.". The author of the URI is assumed to be registration authority regarding features defined and described by the content of the URI. These tags are considered unregistered for the purpose of this document. 3.1.4 Additional registration trees From time to time and as required by the community, the IANA may, with the advice and consent of the IESG, create new top-level registration trees. These trees may be created for external registration and management by (for example) well-known permanent bodies, such as scientific societies for content feature types specific to the sciences they cover. Establishment of these new trees will be announced through RFC publication approved by the IESG. 3.2 Location of registered feature tag list Feature tag registrations will be posted in the anonymous FTP directory: "ftp://ftp.isi.edu/in-notes/iana/assignments/media-feature-tags/" and all registered feature tags will be listed in the periodically issued "Assigned Numbers" RFC [currently STD 2, RFC-1700]. The feature tag description and other supporting material may also be published as an Informational RFC by sending it to "rfc- editor@isi.edu" (please follow the instructions to RFC authors [RFC- 1543]). 3.3 IANA procedures for registering feature tags The IANA will only register feature tags in the IETF tree in response to a communication from the IESG stating that a given registration has been approved. Global tags will be registered by the IANA after review by a designated expert. That review will serve to ensure that the tag meets the technical requirements of this specification. 3.4 Registration template To: ietf-media-feature-tags@iana.org (Media feature tags mailing list) (or directly to iana@iana.org) Subject: Registration of media feature tag XXXX | Instructions are preceded by `|'. Some fields are optional. Media feature tag name: ASN.1 identifier associated with feature tag: [optional] | To have IANA assign an ASN.1 identifier, | use the value "New assignment by IANA" here. Summary of the media feature indicated by this feature tag: | Include a short (no longer than 4 lines) description or summary | Examples: | `Use of the xyzzy feature is indicated by ...' | `Support of color display is indicated by ...' | `Number of colors in a palette which can be defined ...' Number of possible values associated with this feature tag: [ ] 1. The feature tag is Boolean and the feature tag has no associated value. A value of TRUE indicates the availability of the feature. A value of FALSE indicates the feature is not available [ ] 2. The feature has an associated numeric or enumerated value. For case 2: Indicate the data type of the value: [ ] 2a. Signed Integer [ ] 2b. Rational number [ ] 2c. Token (equality relationship) [ ] 2d. Token (ordered) [ ] 2e. String (equality relationship) [ ] 2f. String (defined comparison) |IMPORTANT: You may only chose one of the above data types. (Only for case 2) Detailed description of the feature value meaning, and of the format and meaning of the feature tag values for the alternative results. | If you have selected 2d you must provide the ordering mechanism | or a full and ordered enumeration of possible values. If you | have selected 2f, you must provide a defintion of the comparison. | Definitions by included reference must be to stable and readily | available specifications: | | If the number of alternative results is small, you may | enumerate the identifiers of the different results and describe | their meaning. | | If there is a limited useful numeric range of result (2b, 2c), | indicate the range. | | The identifiers of the alternative results could also be | described by referring to another IANA registry, for example | the paper sizes enumerated by the Printer MIB. The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: [optional] | For applications, also specify the number of the first version | which will use the tag, if applicable. Examples of typical use: [optional] Related standards or documents: [optional] Considerations particular to use in individual applications, protocols, services, or negotiation mechanisms: [optional] Interoperability considerations: [optional] Security considerations: Privacy concerns, related to exposure of personal information: Denial of service concerns related to consequences of specifying incorrect values: Other: Additional information: [optional] Keywords: [optional] Related feature tags: [optional] Related media types or data formats: [optional] Related markup tags: [optional] Name(s) & email address(es) of person(s) to contact for further information: Intended usage: | one of COMMON, LIMITED USE or OBSOLETE Author/Change controller: Requested IANA publication delay: [optional] | A delay may only be requested for final placement in the global | or IETF trees, with a maximum of two months. Organizations | requesting a registration with a publication delay should note | that this delays only the official publication of the tag | and does not prevent information on it from being disseminated | by the members of the relevant mailing list. Other information: [optional] | Any other information that the author deems interesting may be | added here. 4 Security considerations Negotiation mechanisms reveal information about one party to other parties. This may raise privacy concerns, and may allow a malicious party to make better guesses about the presence of specific security holes. 5 Acknowledgments The details of the registration procedure in this document were directly adapted from [1]. Much of the text in section 3 was directly copied from this source. The idea of creating a vocabulary of areas of content features, maintained in a central open registry, is due to discussions on extensible negotiation mechanisms [3] in the IETF HTTP working group. The authors wish to thank Larry Masinter, Graham Klyne, Al Gilman, Dan Wing, Jacob Palme, and Martin Duerst for their contributions to discussions about media feature tag registration. 6 References [1] N. Freed, J. Klensin, J. Postel, Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. RFC 2048, BCP 13, Network Working Group, November 1996 [2] G. Klyne, An algebra for describing media feature sets, Internet Draft: Work in progress March 1998 [3] Holtman, K., et al, Transparent Content Negotiation in HTTP. RFC 2295, Network Working Group, March 1998. [4] Masinter, L., et al, "Media Features for Display, Print, and Fax", Internet-Draft draft-ietf-conneg-media-features-00.txt, Work in progress, March 1998. [5] Norten, T., et al, "Guidelines for Writing an IANA Considerations Section in RFCs", Internet Draft draft-iesg-iana-considerations-04.txt, Work in progress, May 1998. [6] Crocker, D., Ed., Augmented BNF for Syntax Specifications: ABNF. RFC 2234, Network Working Group, November 1997. [7] Fielding, R. et al, Hypertext Transfer Protocol -- HTTP/1.1. RFC 2068, Network Working Group, January 1997. [8] Bradner, S. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, Network Working Group, March 1997. 7 Authors' addresses Koen Holtman Technische Universiteit Eindhoven Postbus 513 Kamer HG 6.57 5600 MB Eindhoven (The Netherlands) Email: koen@win.tue.nl Andrew H. Mutz Hewlett-Packard Company 11000 Wolfe Rd. 42UO Cupertino CA 95014 USA Fax +1 408 447 4439 Email: andy_mutz@hp.com Edward Hardie NASA/STX MS 204-14 Moffett Field, CA 94035 USA hardie@archimedes.nasa.gov Appendix A: IANA and RFC editor to-do list VERY IMPORTANT NOTE: This appendix is intended to communicate various editorial and procedural tasks the IANA and the RFC Editor should undertake prior to publication of this document as an RFC. This appendix should NOT appear in the actual RFC version of this document! This document refers to the feature tags mailing list ietf-media-feature-tags@iana.org. This list does not exist at the present time and needs to be created. The ftp://ftp.isi.edu/in-notes/iana/assignments/media-feature-tags/ area does not exist at the present time and needs to be created. Expires: September 11, 1998 --PART-BOUNDARY=.19807091720.ZM24899.arc.nasa.gov-- From owner-ietf-medfree Fri Jul 10 08:54:47 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA05614 for ietf-medfree-bks; Fri, 10 Jul 1998 08:54:47 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA05610 for ; Fri, 10 Jul 1998 08:54:44 -0700 (PDT) Received: (qmail 9732 invoked from network); 10 Jul 1998 15:54:38 -0000 Received: from userm996.uk.uudial.com (HELO GK) (193.149.81.30) by smtp.dial.pipex.com with SMTP; 10 Jul 1998 15:54:38 -0000 Message-Id: <3.0.32.19980710165232.007c0100@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 10 Jul 1998 16:53:41 +0100 To: hardie@archimedes.nasa.gov From: Graham Klyne Subject: Re: New -reg- draft Cc: ietf-medfree@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-medfree@imc.org Precedence: bulk At 17:20 09/07/98 -0700, Ted Hardie wrote: >Please read the draft carefully and comment as soon >as possible. Ted, I have some comments below -- mostly of the nit-picking variety. #g [...] >TABLE OF CONTENTS > > 1 Introduction > > 2 Media feature tag definitions > 2.1 Media eature tag purpose ...............^ typo > 2.2 Media feature tag syntax [...] >2 Media feature tag definitions > >2.1 Media feature tag purpose > > Media feature tags represent individual and simple dimensions of .....................[---------] "identify" > feature capability. Examples of features related to media > are: Something I noticed here and elsewhere is that the concepts of "feature tag" (a name) and "feature value" (some value) seem to be a bit muddled. The case above is an example. I'll point out others as I go through. > * the color depth of the screen on which something is to be displayed > * the type of paper available in a printer > * the support of the `floating 5 dimensional tables' feature > * the fonts which are available to the recipient > * the capability to display graphical content > > A media feature tag identifies a single dimension of characteristic. > Tag values should use the data types defined in 2.3. > > Examples of media feature tags with values are: The examples that follow don't actually include feature *tags*. Also, some don't relate to individual media features. Thus, I suggest: "Examples of media features are:" > * the width of a display in pixels per centimeter represented as an > integer value. > * the fonts available to a recipient as an enumerated list. The set of fonts would be several feature values. I would suggest: "a font available to a recipient, selected from an enumerated list" On reflection, this is an interesting case as it exposes a flaw in some of my thinking. Feature values are defined as simple scalars, and a feature collection has formally been treated as a finite map, which means each tag appears only once. I think it will be necessary to allow repeated feature tags in a feature collection, to capture cases like that of a single document that uses multiple fonts (which is the general thrust in section 3 of -algebra-. I don't think this has any difficult ramifications, but it needs to be dealt with in a consistent fashion. > * the version of a protocol composed of integers "i.j.k", defined as > either a value in an enumerated list or with a defined mapping to .................[--]"selected from"...^ insert ',' > make the value isomorphic to a subset of integers (e.g. i*100 + j*10 +k, > assuming j<=9 and k<=9). > > Further examples of media feature tags are defined in detail ............................[------------]"features, and their tags," > elsewhere [4]. > > Feature collections may be composed using a number of individual > feature tags [2]. Composition of feature collections is described ...............^ "and associated values" > elsewhere [2]. Examples of feature collections requiring multiple > media feature tags are: > > * the width and height of a display > * the combination of color depth and resolution a display can support In view of my comments above, maybe add: "* the set of all fonts used by a document" [...] >2.2 Media feature tag syntax > > A media feature tag is a string consisting of one or more of the following > US-ASCII characters: uppercase letters, lowercase letters, digits, > colon (":"), slash ("/"), dot (".") percent ("%"), and dash > ("-"). Feature tags are case-insensitive. Dots are understood to > potentially imply heirarchy; a feature can be subtyped by describing > it as tree.feature.subfeature and by indicating this in the > registration. Tags should begin with an alphabetic character. A passing thought: this desription suggested to me that maybe X- and Y- values (pix-x, pix-y, res-x, res-y, etc.) should be described by faceted values (pix.x, pix.y, etc.) [...] >2.3 Media feature tag values > > The registry will initially support the use of the following data > types as tag values: > > - signed integers > - rational numbers > - tokens, with equality relationship > - strings, with equality relationship > - strings, with defined comparison > - ordered tokens I would suggest a slight re-arrangement of the above: # - signed integers # - rational numbers # - tokens, with equality relationship # - tokens, with defined ordering relationship # - strings, with standard (octet-by-octet) equality relationship # - strings, with defined equality and/or ordering relationships > "Token" here means the token data type as defined by [7], > which may be summarized as: > > token = 1* > > tspecials = "(" | ")" | "<" | ">" | "@" > | "," | ";" | ":" | "\" | <"> > | "/" | "[" | "]" | "?" | "=" > | "{" | "}" | SP | HT Two nits: (1) 'tspecials' is correct for RFC 2068, but I believe that in the latest HTTP drafts it has been renamed to avoid a clash with the MIME specs. (2) this document cites RFC2245, but the above syntax description does not conform (uses '|' instead of '/'). (Personally, I prefer '|', but that doesn't seem to be the way the wind is blowing.) [...] >2.3 ASN.1 identifiers for media feature tags > > Certain protocols use ASN.1 identifiers rather than human-readable > representations for capability exchange. In order to allow both > systems to interoperate, registrants may provide an ASN.1 identifier > or ask that IANA assign an ASN.1 identifier during registration. > These identifiers are not required for registration, but may provide > assistance to those building gateways or other cross-protocol > systems. Note that ASN.1 identifiers assigned by IANA will be > treated as tokens, not as elements from which sub-delegated > identifiers may be created or derived. Good point! (The last sentence.) [...] >3.1.2 Global tree > > Tags in the global tree will be distinguished by the leading facet > "g.". An organization may propose either a designation indicative > of the feature, (e.g., "g.blinktags") or a faceted designation > including the organization name (e.g., "g.organization.blinktags"). > Organizations which have registered media types under the MIME > vendor tree should use the same organizational name for media > feature tags if they propose a faceted designation. Is there potential here for conflict over the use of organizational names? > [...] The acceptance > of the proposed designation is at the discretion of the IANA. > If the IANA believes that a designation needs clarification > it may request a new proposal from the proposing organization > or otherwise coordinate the development of an appropriate > designation. Is this possibly a bit vague for IANA considerations? Isn't this covered by the "expert review" policy? I think that, given "expert review", this text might be deleted. [...] >3.2 Location of registered feature tag list > > Feature tag registrations will be posted in the anonymous FTP > directory: > "ftp://ftp.isi.edu/in-notes/iana/assignments/media-feature-tags/" > and all registered feature tags will be listed in the periodically > issued "Assigned Numbers" RFC [currently STD 2, RFC-1700]. The > feature tag description and other supporting material may also be > published as an Informational RFC by sending it to "rfc- > editor@isi.edu" (please follow the instructions to RFC authors [RFC- > 1543]). [RFC-1543] is an inconsistent form of citation, and is not included in the references. [...] >3.4 Registration template > > To: ietf-media-feature-tags@iana.org (Media feature tags mailing list) > (or directly to iana@iana.org) > Subject: Registration of media feature tag XXXX > > > | Instructions are preceded by `|'. Some fields are optional. > > Media feature tag name: .....................[----] delete? > ASN.1 identifier associated with feature tag: [optional] > > | To have IANA assign an ASN.1 identifier, > | use the value "New assignment by IANA" here. > > Summary of the media feature indicated by this feature tag: > > | Include a short (no longer than 4 lines) description or summary > | Examples: > | `Use of the xyzzy feature is indicated by ...' > | `Support of color display is indicated by ...' > | `Number of colors in a palette which can be defined ...' > > Number of possible values associated with this feature tag: > > [ ] 1. The feature tag is Boolean and the feature tag has no > associated value. A value of TRUE indicates the availability > of the feature. A value of FALSE indicates the feature > is not available The idea of "no associated value" seems wrong: the associated value is TRUE or FALSE. I have two issues with this use of a Boolean value indicating "avalability": (1) in some occurrences, a TRUE value might indicate a _requirement for_ rather than _availability of_ a feature. If a document is intended for double-sided printing, indicating "duplex=TRUE" doesn't really indicate availability of a feature. (2) Boolean values can also be used to indicate two mutually exclusive possibilities. E.g. "hardcopy=TRUE" and "hardcopy=FALSE" could indicate printing and display terminals respectively. (It is arguable that this case is better handled by a two-valued token enumeration. In some ways, that is exactly how I view Boolean.) How about TRUE indicating "a capability that may be exercised", and FALSE indicating the "absence or converse of that capability"? > [ ] 2. The feature has an associated numeric or enumerated value. > > > For case 2: Indicate the data type of the value: > > [ ] 2a. Signed Integer > [ ] 2b. Rational number > [ ] 2c. Token (equality relationship) > [ ] 2d. Token (ordered) > [ ] 2e. String (equality relationship) > [ ] 2f. String (defined comparison) > > |IMPORTANT: You may only chose one of the above data types. > > > (Only for case 2) Detailed description of the feature value meaning, > and of the format and meaning of the feature tag values > for the alternative results. > > | If you have selected 2d you must provide the ordering mechanism > | or a full and ordered enumeration of possible values. If you > | have selected 2f, you must provide a defintion of the comparison. > | Definitions by included reference must be to stable and readily > | available specifications: > | > | If the number of alternative results is small, you may > | enumerate the identifiers of the different results and describe > | their meaning. > | > | If there is a limited useful numeric range of result (2b, 2c), > | indicate the range. Add: "including whether values may be negative" ? > | The identifiers of the alternative results could also be > | described by referring to another IANA registry, for example > | the paper sizes enumerated by the Printer MIB. > > The feature tag is intended primarily for use in the following > applications, protocols, services, or negotiation mechanisms: > [optional] > > | For applications, also specify the number of the first version > | which will use the tag, if applicable. > > Examples of typical use: [optional] > > Related standards or documents: [optional] > > Considerations particular to use in individual applications, > protocols, services, or negotiation mechanisms: [optional] > > Interoperability considerations: [optional] > > Security considerations: > > Privacy concerns, related to exposure of personal information: > > Denial of service concerns related to consequences of specifying > incorrect values: > > Other: > > Additional information: [optional] > > Keywords: [optional] The purpose of this entry is not clear to me. > Related feature tags: [optional] > > Related media types or data formats: [optional] > > Related markup tags: [optional] The purpose of this entry is not clear to me. [...] That's all folks! #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-medfree Mon Jul 13 04:03:49 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA10719 for ietf-medfree-bks; Mon, 13 Jul 1998 04:03:49 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA10715 for ; Mon, 13 Jul 1998 04:03:48 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA24315; Mon, 13 Jul 1998 07:02:28 -0400 (EDT) Message-Id: <199807131102.HAA24315@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-ietf-conneg-feature-reg-02.txt Date: Mon, 13 Jul 1998 07:02:21 -0400 Sender: owner-ietf-medfree@imc.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Negotiation Working Group of the IETF. Title : Content Feature Tag Registration Procedure Author(s) : E. Hardie, K. Holtman, A. Mutz Filename : draft-ietf-conneg-feature-reg-02.txt Pages : 12 Date : 10-Jul-98 This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary. Internet-Drafts are 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-ietf-conneg-feature-reg-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-conneg-feature-reg-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-conneg-feature-reg-02.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: <19980710090755.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-conneg-feature-reg-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-conneg-feature-reg-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980710090755.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-medfree Mon Jul 13 20:49:52 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA17286 for ietf-medfree-bks; Mon, 13 Jul 1998 20:49:52 -0700 (PDT) Received: from 207.181.100.220 (stn-on98-28.netcom.ca [207.181.100.220