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 wha