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 S