From owner-ietf-medfree@imc.org Wed Feb 2 21:58:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26328 for ; Wed, 2 Feb 2000 21:58:28 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA04914 for ietf-medfree-bks; Wed, 2 Feb 2000 18:53:49 -0800 (PST) Received: from willie.localaccess.net (root@willie.localaccess.net [208.228.198.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA04908 for ; Wed, 2 Feb 2000 18:53:47 -0800 (PST) Received: from localaccess.net (dial-main-12.localaccess.net [208.228.198.12]) by willie.localaccess.net (8.8.5/8.8.5) with ESMTP id UAA01120 for ; Wed, 2 Feb 2000 20:48:56 -0600 (CST) Message-ID: <38990A74.AA247C66@localaccess.net> Date: Wed, 02 Feb 2000 20:56:20 -0800 From: nac X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-medfree@imc.org Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Please forward further information about your shoppingcart service software Thank! From owner-ietf-medfree@imc.org Mon Feb 14 16:54:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24811 for ; Mon, 14 Feb 2000 16:54:20 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA22720 for ietf-medfree-bks; Mon, 14 Feb 2000 13:48:00 -0800 (PST) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22716 for ; Mon, 14 Feb 2000 13:47:59 -0800 (PST) Received: from 192.168.110.7 (workstation1.swip.net [130.244.254.1]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id WAA10433; Mon, 14 Feb 2000 22:48:04 +0100 (MET) Date: Mon, 14 Feb 2000 22:42:36 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: GK@acm.org cc: ietf-medfree@imc.org, Keith Moore , Ned Freed Subject: Re: Last Call: Indicating media features for MIME content to (fwd) Message-ID: <1427578.3159556956@localhost> X-Mailer: Mulberry/2.0.0b9 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id NAA22717 Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Comments from IANA. Is the reference in question normative? Patrik P.S. See that I am addressed explicitely on the response! ---------- Forwarded Message ---------- Date: måndag 14 februari 2000 11.52 -0800 From: Internet Assigned Numbers Authority To: iesg@ISI.EDU Subject: Re: Last Call: Indicating media features for MIME content to IESG: The IANA has reviewed the following Internet-Drafts which are in Last Call: draft-ietf-conneg-content-features-02.txt draft-ietf-conneg-feature-type-02.txt and has the following comments with regards to the publication of these documents. In both "References" sections, there is an I-D: [9] "Registration of Charset and Languages Media Features Tags", draft-hoffman-char-lang-media-01.txt What is the status? Is it normative? Joyce K. Reynolds IANA Liaison to the IESG ---------- End Forwarded Message ---------- From owner-ietf-medfree@imc.org Mon Feb 14 17:40:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25702 for ; Mon, 14 Feb 2000 17:40:04 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA23824 for ietf-medfree-bks; Mon, 14 Feb 2000 14:33:39 -0800 (PST) Received: from monsoon.mail.pipex.net (monsoon.mail.pipex.net [158.43.128.69]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA23820 for ; Mon, 14 Feb 2000 14:33:37 -0800 (PST) Received: (qmail 6471 invoked from network); 14 Feb 2000 22:36:58 -0000 Received: from usercq11.uk.uudial.com (HELO GK-VAIO) (62.188.156.139) by smtp.dial.pipex.com with SMTP; 14 Feb 2000 22:36:58 -0000 Message-Id: <4.2.2.20000214222529.00b1ac90@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 14 Feb 2000 22:37:08 +0000 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Graham Klyne Subject: Re: Last Call: Indicating media features for MIME content to (fwd) Cc: ietf-medfree@imc.org, Keith Moore , Ned Freed In-Reply-To: <1427578.3159556956@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA23821 Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Patrik, The indicated reference is not normative to either of these specifications. Some examples do use the charset tag defined by the reference in question (partly due to WG last-call comments about the desirability of always indicating a charset with a text content type), but does not affect the specification. Quite coincidentally, I have just (within the past hour) e-mailed Paul Hoffman about asking for a (non-WG) last call on his charset/language draft, since that is very complementary, and I think it would be desirable if it were to move forward about the same time as the WG proposals. #g -- At 10:42 PM 2/14/00 +0100, Patrik Fältström wrote: >Comments from IANA. > >Is the reference in question normative? > > Patrik > >P.S. See that I am addressed explicitely on the response! > >---------- Forwarded Message ---------- >Date: måndag 14 februari 2000 11.52 -0800 >From: Internet Assigned Numbers Authority >To: iesg@ISI.EDU >Subject: Re: Last Call: Indicating media features for MIME content to > > > > >IESG: > >The IANA has reviewed the following Internet-Drafts which are in Last >Call: > > draft-ietf-conneg-content-features-02.txt > draft-ietf-conneg-feature-type-02.txt > >and has the following comments with regards to the publication of these >documents. > >In both "References" sections, there is an I-D: > > [9] "Registration of Charset and Languages Media Features > Tags", > draft-hoffman-char-lang-media-01.txt > >What is the status? Is it normative? > > >Joyce K. Reynolds >IANA Liaison to the IESG > >---------- End Forwarded Message ---------- > ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-medfree@imc.org Mon Feb 14 18:51:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26661 for ; Mon, 14 Feb 2000 18:51:29 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA25207 for ietf-medfree-bks; Mon, 14 Feb 2000 15:43:33 -0800 (PST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25058; Mon, 14 Feb 2000 15:34:23 -0800 (PST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id SAA00271; Mon, 14 Feb 2000 18:37:05 -0500 (EST) Message-Id: <200002142337.SAA00271@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: apps area chairs and working groups: ; cc: ietf@ietf.org reply-to: ietf@ietf.org From: Keith Moore Subject: IETF Adelaide and interim meetings for APPS WGs Date: Mon, 14 Feb 2000 18:37:05 -0500 Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It has come to the attention of the Applications Area Directors that one or more Applications area working groups have elected to not meet in Adelaide, and instead to hold an "interim meeting" in the United States, presumably because of distance and/or cost issues. IETF is an international organization, and it is IETF's longstanding practice to hold its meetings in various locations around the planet. This serves both to encourage wider participation in IETF and also to more fairly distribute travel costs and inconvenience (over time) among all participants. The scheduleing of an interim WG meeting in the US in lieu of a WG meeting in Adelaide undermines this policy. This is insulting to non-US participants of IETF (many of whom have attended meetings in the US for years), embarassing to IETF as a whole, and a threat to IETF's international stature. Even if a working group has few participants outside the United States, a working group does not work in isolation from other working groups. Attendance at IETF meetings is an invaluable mechanism for cross-group collaboration. RFC 2418 states: Interim meetings are subject to the same rules for advance notification, reporting, open participation, and process, which apply to other working group meetings. Since normal working group meetings require advance notification via email to the entire IETF list, and the process for getting a meeting slot involves prior approval of the Area Directors, the same requirements apply to interim working group meetings. Part of the reason for prior approval being required is to ensure that the locations of the meetings are not being chosen to favor certain participants over others. There have been several violations of this policy since publication of RFC 2418. Therefore, - All interim meetings within the Applications Area which were not previously and explicitly approved by the Applications Area Directors, are hereby cancelled. - No Applications Area group will hold any interim meeting prior to April 15. - No Applications Area group which does not hold a meeting in Adelaide, will hold any interim meeting prior to July 31. (i.e. prior to the Pittsburg IETF meeting) - This applies to all face to face meetings held for the purpose of conducting working group discussion and to which the working group is invited, even if labelled "informal" or otherwise labelled to distinguish them from official working group meetings. - Exceptions to this policy may be made for recently chartered groups, but Area Director approval is still required for such groups to schedule interim meetings. for the Applications Area Directors, Keith Moore From owner-ietf-medfree@imc.org Tue Feb 15 01:17:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08195 for ; Tue, 15 Feb 2000 01:17:31 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA10604 for ietf-medfree-bks; Mon, 14 Feb 2000 22:06:55 -0800 (PST) Received: from iis.winweb.ch (iis.winweb.ch [160.85.145.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA10599; Mon, 14 Feb 2000 22:06:52 -0800 (PST) From: jobs@agnet.com.au Received: from monorailpc (ip5.margate.fl.pub-ip.PSI.NET [38.14.96.5]) by iis.winweb.ch (Netscape Messaging Server 3.62) with SMTP id 247; Mon, 14 Feb 2000 21:19:12 +0100 To: jobs@agnet.com.au Subject: HOT OPENINGS IN AUSTIN, TEXAS!!! Date: Mon, 14 Feb 2000 21:19:12 +0100 Message-ID: <20000214201416598.AAH148.247@ip5.margate.fl.pub-ip.PSI.NET> Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ************************************* ************************************* HOT JOB OPENINGS IN AUSTIN, TEXAS ************************************* ************************************* Exciting opportunities have just opened up in Austin, Texas. If you are thinking of making a career change or know of anyone else who might be interested, please forward these excellent opportunities to them. _________________________________________________________ Web Developers are needed with strong knowledge of HTML, JAVAscript, Perl, CGI methodology, Unix, and Sun Solaris. Salaries up to $90,000 No contractors accepted on this position. ************************************* _________________________________________________________ Several JAVA Programmers also needed to develop & deploy a web-based integrated work flow management & sales tool for mid range products. Salaries up to $90,000. Contractors will be paid $48.00 per hour. ************************************* _________________________________________________________ Sr. JAVA Developer needed to work on fast growing web enabled private line networking products. Will work as part of a highly skilled team. JAVA plus solid development methodology, Enterprise JAVA Beans (EJB), and BEA's Web Logic EJB Server needed. Salaries up to $90,000 or $48.00 per hour. ************************************* _________________________________________________________ C++/JAVA Programmers needed to work on 8-10 member team within a Linux environment. Expert knowledge of Linux/Unix/AIX needed. Salaries up to $68,000. Contractors paid up to $38.00 per hour. ************************************* _________________________________________________________ AIX Support Delivery Technical Specialists needed. Shell scripting/programming in an AIX/UNIX environment (Perl or C) needed. _________________________________________________________ OS/2 Technical Support. Must be able to travel to client sites when needed. Must also have some OS/2 LAN Manager. Salaries up to $78,338. Contractors will be paid $45.00 per hour. ************************************* _________________________________________________________ Instructional Designer/Developer needed to design and help with course development. Will develop and coordinate training and develop course material on the company's products and sales. Any experience with JAVA, JAVA Beans will be a plus. This is a contractor postion only and will pay up to $30.00 per hour. ************************************* _________________________________________________________ Visual C++ Developers needed as part of a development team for a telecommunications company. Will perform all phases of the development life cycle. Must have Visual C++, MFC, Object Oriented Design and SQL. Salaries up to $50,000 or $26.00 per hour. ************************************* _________________________________________________________ Software Test Engineers needed to help design, develop, code and execute functional test plans. Salaries are open. _________________________________________________________ Disk Drive Engineer needed to provide world wide product engineering support for a variety of disk drivers on the RS/6000. Salary up to $50,000 or $30.00 per hour. ************************************* _________________________________________________________ Device Driver Developers needed to perform new development and technical Level 2.5/3.0 support of the AIX operating system. Salary up to $73,000 or $40.00 per hour. ************************************* _________________________________________________________ AIX Kernel Developers to perform support and serviceability using AIX, Virtual Memory Manager, Unix Configuration, Unix Security, Printer Device Drivers. Will pay up to $68,000 or $38.00 per hour. ************************************* AIX Performance Testers also needed. _________________________________________________________ SQL Server DBA's needed for three projects. Salaries up to $47,000 or $26.00 per hour. ************************************* _________________________________________________________ DB2 Database Manager needed to develop and manage a database for partner commerce/servers. Will be responsible for database backup and recovery procedures. Will access security and database integrity. Salary up to $93,596 or $51.00 per hour. ************************************* _________________________________________________________ ADABAS DBA needed for a short term contract. Must have ADASMP. Will pay top dollar to find the right person. ************************************* _________________________________________________________ QA Manager needed to Manage Test group. Salary up to $72,000 or $40.00 per hour. ************************************* _________________________________________________________ _________________________________________________________ For detailed information on these and other openings please CONTACT us at our toll free =============================== =============================== DP West Incorporated Professional Recruiting and Services 1-888-664-2388 or 623-374-0030 =============================== =============================== _________________________________________________________ _________________________________________________________ Note: This mail has been directed to computer professionals seeking employment. It is not intended to be spam mail. We have received your reference from fellow business partners. If you do not want to receive this mail in the future please let us know the e-mail ID this message was received at and any aliases and we will take you off our list. We appreciate your patience and regret the inconvenience. From owner-ietf-medfree@imc.org Tue Feb 15 01:51:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10656 for ; Tue, 15 Feb 2000 01:51:34 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA11640 for ietf-medfree-bks; Mon, 14 Feb 2000 22:45:24 -0800 (PST) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA11636 for ; Mon, 14 Feb 2000 22:45:22 -0800 (PST) Received: from 192.168.110.5 (workstation1.swip.net [130.244.254.1]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id HAA23527; Tue, 15 Feb 2000 07:45:44 +0100 (MET) Date: Tue, 15 Feb 2000 07:25:49 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: GK@acm.org, ietf-medfree@imc.org cc: Ned Freed , Keith Moore Subject: Re: Last Call: Indicating media features for MIME content to (fwd) Message-ID: <1661387.3159588349@localhost> X-Mailer: Mulberry/2.0.0b9 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id WAA11637 Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Comments from Ned Freed. Can you comment please, and IF you find that you want to tweak the I-D, let me know _before_ you start doing that process, and then, when I say ok, let me know when the new I-D is announced. Thanks, Patrik ---------- Forwarded Message ---------- Date: måndag 14 februari 2000 14.00 -0800 From: ned.freed@innosoft.com To: iesg@ISI.EDU Subject: Re: Last Call: Indicating media features for MIME content to Here are my comments on these documents: Comments on draft-ietf-conneg-feature-type-02.txt: I'm very concerned about the handling of content-type parameters in section 3. I really don't like allowing them as part of the type tag. I see real problems with canonicalization, ordering, case sensitivity, and so on. I suggest that content-type parameters be excluded from the type feature tag. If we need to be able to describe parameters (and I think we do need to be able to do this, if only to handle charset= for text subtypes), I would suggest defining a new tag "type-parameter" whose value is of the form "name=value". (I'm assuming that a feature tag can be repeated with different values; if not then there's a real problem representing MIME information in feature tags.) Comments on draft-ietf-conneg-content-features-02.txt: In section 3, I think the interaction between filter syntax and header line folding needs to be stated explicitly. According to RFC 2533, whitespace is allowed between lexical elements of a media feature expression. This then interacts in a nice way with RFC822/MIME header folding rules, since it lets you fold long expressions in content-features fields to avoid line length restrictions. I would suggest adding a new section 3.1 (and moving the others down one) that explains this fact, and suggests putting plenty of whitespace into content-features header fields so that folding will be facilitated in agents that otherwise don't grok the syntax of the field. I am concerned about the section 3.1.2 "No one-to-one relationship between headers and contained body parts is assumed" rule, especially in the case of multipart/alternative. I think it would be useful to have the ability to express specific per-part content features in the multipart/alternative case. And more importantly, I think people are likely to assume a relationship unless this restriction is called out a lot more aggressively in the document. If there's a strong consensus that specific per-part indicators are too complex (and I do see the issues with multipart/alternative where the parts are themselves composite) or have other problems and hence this restriction should be retained, that's fine. But in such a case I would use language like "implementations MUST NOT assume a one-to-one relationship" in section 3.1.2, I would reiterate this point in section 4.3, and I would deliberately make the example in section 4.3, incomplete, out of order, more complex, or perhaps all three. In section 5 (security considerations) the issues associated with the use of this facility in conjunction with multipart/signed should be elaborated. In particular, putting content-features information outside the signed object has the virtue of not requiring a parse of the message, but since it isn't protected under the hash could be tampered with, possibly fooling implementations into not displaying material they really can handle, or displaying information they really can't handle. On the other hand, putting content-features information inside the hash means implementations have to parse the structure to find it, but it will be protected there. That's it for these documents. I have some comments on some other conneg documents that I'll send in separately to the WG list. Ned ---------- End Forwarded Message ---------- From owner-ietf-medfree@imc.org Tue Feb 15 07:59:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26506 for ; Tue, 15 Feb 2000 07:59:26 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA21284 for ietf-medfree-bks; Tue, 15 Feb 2000 04:52:25 -0800 (PST) Received: from monsoon.mail.pipex.net (monsoon.mail.pipex.net [158.43.128.69]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA21280 for ; Tue, 15 Feb 2000 04:52:23 -0800 (PST) Received: (qmail 20557 invoked from network); 15 Feb 2000 12:55:45 -0000 Received: from userl416.uk.uudial.com (HELO GK-VAIO) (193.149.74.229) by smtp.dial.pipex.com with SMTP; 15 Feb 2000 12:55:45 -0000 Message-Id: <4.2.2.20000215113221.00ae7100@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 15 Feb 2000 12:00:50 +0000 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Graham Klyne Subject: Re: Last Call: Indicating media features for MIME content to (fwd) Cc: ietf-medfree@imc.org, Ned Freed , Keith Moore In-Reply-To: <1661387.3159588349@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id EAA21281 Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit At 07:25 AM 2/15/00 +0100, Patrik Fältström wrote: >Comments from Ned Freed. Can you comment please, and IF you find that you >want to tweak the I-D, let me know _before_ you start doing that process, >and then, when I say ok, let me know when the new I-D is announced. Patrik, I think there are some useful comments here. I think a revision would be good, but I'd like to clarify with Ned some of the points raised before proceeding. #g -- >---------- Forwarded Message ---------- >Date: måndag 14 februari 2000 14.00 -0800 >From: ned.freed@innosoft.com >To: iesg@ISI.EDU >Subject: Re: Last Call: Indicating media features for MIME content to > > >Here are my comments on these documents: > > Comments on draft-ietf-conneg-feature-type-02.txt: > > I'm very concerned about the handling of content-type parameters in > section 3. I really don't like allowing them as part of the type tag. I > see real problems with canonicalization, ordering, case sensitivity, and > so on. > > I suggest that content-type parameters be excluded from the type feature > tag. If we need to be able to describe parameters (and I think we do need > to be able to do this, if only to handle charset= for text subtypes), > I would suggest defining a new tag "type-parameter" whose value is of the > form "name=value". (I'm assuming that a feature tag can be repeated with > different values; if not then there's a real problem representing MIME > information in feature tags.) I generally agree with the basic premise -- I have tried to discourage the use of parameters in type parameters, but was maybe too timid in not prohibiting them outright. I personally have no problem, with outright prohibition of parameters within a "type" value. However, I don't think that Ned's proposed solution works too well, for a couple of reasons: (a) the assumption that a tag can be repeated with different values does not hold: the logical structure of feature expressions assumes only one value can be asserted for a given feature tag in any particular feature collection ("instance"). For example, suppose we have three type parameters: charset=US-ASCII charset=UTF-8 language=EN-US is this to mean all three must be simultaneously true (logical AND, leading to a contradiction), or that any one must be true (logical OR, which fails to assert anything about charset of language), or some combination such as: (& (| (charset=US-ASCII) (charset=UTF-8) ) (language=EN-US) ) The intent of the feature framework is to be able to capture combinations like the final example. (b) one of the design principles that we agreed for feature tags is that the _meaning_ of a tag should _never_ depend on the value of another tag. This would be violated by having a generic 'type-parameter' tag whose meaning would depend on the value of a 'type' tag. The solution I would suggest is that new feature tags are defined for content-type parameter values that are significant for content negotiation/description. Paul Hoffman has prepared a draft dealing with charset and language, which I would like to see progressed on a similar timeframe to these. > Comments on draft-ietf-conneg-content-features-02.txt: > > In section 3, I think the interaction between filter syntax and header > line folding needs to be stated explicitly. According to RFC 2533, > whitespace is allowed between lexical elements of a media feature > expression. This then interacts in a nice way with RFC822/MIME header > folding rules, since it lets you fold long expressions in > content-features fields to avoid line length restrictions. OK. I am entirely happy to add some text to this effect. > I would suggest adding a new section 3.1 (and moving the others down > one) that explains this fact, and suggests putting plenty of whitespace > into content-features header fields so that folding will be facilitated > in agents that otherwise don't grok the syntax of the field. Good point. > I am concerned about the section 3.1.2 "No one-to-one relationship > between headers and contained body parts is assumed" rule, especially in > the case of multipart/alternative. I think it would be useful to have > the ability to express specific per-part content features in the > multipart/alternative case. And more importantly, I think people are > likely to assume a relationship unless this restriction is called out a > lot more aggressively in the document. I had taken the view that per-part content feature indications would be expressed by applying 'Content-features' directly to the part concerned. Maybe my text isn't clear? I had meant to say that there was no 1:1 correspondence between headers on the outermost content-type and the contained body parts. e.g: Content-type: multipart/alternative;boundary="next" Content-features: () Content-features: () --next Content-type: text/plain Content-features: () : --next Content-type: text/html Content-features: () : --next Content-type: image/tiff Content-features: () : --next-- The intent here is allow the multipart/alternative to give an indication of what lies inside, without having to be specific about _where_ inside it may be found. > If there's a strong consensus that specific per-part indicators are too > complex (and I do see the issues with multipart/alternative where the > parts are themselves composite) or have other problems and hence this > restriction should be retained, that's fine. But in such a case I would > use language like "implementations MUST NOT assume a one-to-one > relationship" in section 3.1.2, I would reiterate this point in section > 4.3, and I would deliberately make the example in section 4.3, > incomplete, out of order, more complex, or perhaps all three. Is this affected by my explanaton above? > In section 5 (security considerations) the issues associated with the use > of this facility in conjunction with multipart/signed should be > elaborated. In particular, putting content-features information outside > the signed object has the virtue of not requiring a parse of the > message, but since it isn't protected under the hash could be tampered > with, possibly fooling implementations into not displaying material they > really can handle, or displaying information they really can't handle. > On the other hand, putting content-features information inside the hash > means implementations have to parse the structure to find it, but it > will be protected there. I think that's a useful addition. --end-- ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-medfree@imc.org Tue Feb 15 08:03:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26914 for ; Tue, 15 Feb 2000 08:03:33 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA21385 for ietf-medfree-bks; Tue, 15 Feb 2000 04:58:27 -0800 (PST) Received: from monsoon.mail.pipex.net (monsoon.mail.pipex.net [158.43.128.69]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA21378 for ; Tue, 15 Feb 2000 04:58:26 -0800 (PST) Received: (qmail 22614 invoked from network); 15 Feb 2000 13:01:48 -0000 Received: from userl416.uk.uudial.com (HELO GK-VAIO) (193.149.74.229) by smtp.dial.pipex.com with SMTP; 15 Feb 2000 13:01:48 -0000 Message-Id: <4.2.2.20000215130119.00b70180@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 15 Feb 2000 13:02:56 +0000 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Graham Klyne Subject: Re: Last Call: Indicating media features for MIME content to (fwd) Cc: ietf-medfree@imc.org, Ned Freed , Keith Moore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Reviewing my last message, I notice that it may not be immediately obvious that it also contains my responses to the points Ned has raised. #g -- ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-medfree@imc.org Tue Feb 15 08:15:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27745 for ; Tue, 15 Feb 2000 08:15:54 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA21715 for ietf-medfree-bks; Tue, 15 Feb 2000 05:09:53 -0800 (PST) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA21711 for ; Tue, 15 Feb 2000 05:09:52 -0800 (PST) Received: from vis188.inria.fr (nix.swip.net [192.71.220.2]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id OAA08206; Tue, 15 Feb 2000 14:09:45 +0100 (MET) Date: Tue, 15 Feb 2000 14:07:07 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Graham Klyne cc: ietf-medfree@imc.org, Ned Freed , Keith Moore Subject: Re: Last Call: Indicating media features for MIME content to (fwd) Message-ID: <1063894.3159612427@localhost> In-Reply-To: <4.2.2.20000215113221.00ae7100@pop.dial.pipex.com> X-Mailer: Mulberry/2.0.0b9 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit --On 2000-02-15 12.00 +0000, Graham Klyne wrote: > I think there are some useful comments here. I think a revision would be > good, but I'd like to clarify with Ned some of the points raised before > proceeding. Definitely. It might happen that some more comments will pour in from other IESG members the next week or so (until we discuss the document next thursday), so take it easy with doing too much work. Resolv issues with Ned, perfect! Update document, maybe not yet. paf From owner-ietf-medfree@imc.org Tue Feb 15 16:27:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23284 for ; Tue, 15 Feb 2000 16:26:58 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA04266 for ietf-medfree-bks; Tue, 15 Feb 2000 13:19:34 -0800 (PST) Received: from mauve.innosoft.com (mauve.innosoft.com [192.160.253.247]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA04261 for ; Tue, 15 Feb 2000 13:19:32 -0800 (PST) From: ned.freed@INNOSOFT.COM Received: from MAUVE.INNOSOFT.COM by MAUVE.INNOSOFT.COM (PMDF V6.0-20 #35243) id <01JLXJ0FYNJ4000979@MAUVE.INNOSOFT.COM> for ietf-medfree@imc.org; Tue, 15 Feb 2000 13:22:27 -0800 (PST) Date: Tue, 15 Feb 2000 13:16:38 -0800 (PST) Subject: Re: Last Call: Indicating media features for MIME content to (fwd) In-reply-to: "Your message dated Tue, 15 Feb 2000 12:00:50 +0000" <4.2.2.20000215113221.00ae7100@pop.dial.pipex.com> To: Graham Klyne Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , ietf-medfree@imc.org, Ned Freed , Keith Moore Message-id: <01JLXS1GURSG000979@MAUVE.INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1; format=flowed References: <1661387.3159588349@localhost> Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > >Here are my comments on these documents: > > > > Comments on draft-ietf-conneg-feature-type-02.txt: > > > > I'm very concerned about the handling of content-type parameters in > > section 3. I really don't like allowing them as part of the type tag. I > > see real problems with canonicalization, ordering, case sensitivity, and > > so on. > > > > I suggest that content-type parameters be excluded from the type feature > > tag. If we need to be able to describe parameters (and I think we do need > > to be able to do this, if only to handle charset= for text subtypes), > > I would suggest defining a new tag "type-parameter" whose value is of the > > form "name=value". (I'm assuming that a feature tag can be repeated with > > different values; if not then there's a real problem representing MIME > > information in feature tags.) > I generally agree with the basic premise -- I have tried to discourage the > use of parameters in type parameters, but was maybe too timid in not > prohibiting them outright. I personally have no problem, with outright > prohibition of parameters within a "type" value. > However, I don't think that Ned's proposed solution works too well, for a > couple of reasons: > (a) the assumption that a tag can be repeated with different values does > not hold: the logical structure of feature expressions assumes only one > value can be asserted for a given feature tag in any particular feature > collection ("instance"). For example, suppose we have three type parameters: > charset=US-ASCII > charset=UTF-8 > language=EN-US > is this to mean all three must be simultaneously true (logical AND, leading > to a contradiction), or that any one must be true (logical OR, which fails > to assert anything about charset of language), or some combination such as: > (& (| (charset=US-ASCII) (charset=UTF-8) ) (language=EN-US) ) > The intent of the feature framework is to be able to capture combinations > like the final example. > (b) one of the design principles that we agreed for feature tags is that > the _meaning_ of a tag should _never_ depend on the value of another > tag. This would be violated by having a generic 'type-parameter' tag whose > meaning would depend on the value of a 'type' tag. > The solution I would suggest is that new feature tags are defined for > content-type parameter values that are significant for content > negotiation/description. Paul Hoffman has prepared a draft dealing with > charset and language, which I would like to see progressed on a similar > timeframe to these. I'm not particularly fond of this as it creates an open-ended registration problem. However, given the way this stuff works I agree there is realistically no other way to do it. So I suggest proceeding by prohibiting parameters from the content-type feature tag and adding text describing what must be done when such parameters come up. > > I am concerned about the section 3.1.2 "No one-to-one relationship > > between headers and contained body parts is assumed" rule, especially in > > the case of multipart/alternative. I think it would be useful to have > > the ability to express specific per-part content features in the > > multipart/alternative case. And more importantly, I think people are > > likely to assume a relationship unless this restriction is called out a > > lot more aggressively in the document. > I had taken the view that per-part content feature indications would be > expressed by applying 'Content-features' directly to the part concerned. > Maybe my text isn't clear? I had meant to say that there was no 1:1 > correspondence between headers on the outermost content-type and the > contained body parts. e.g: > Content-type: multipart/alternative;boundary="next" > Content-features: () > Content-features: () > --next > Content-type: text/plain > Content-features: () > : > --next > Content-type: text/html > Content-features: () > : > --next > Content-type: image/tiff > Content-features: () > : > --next-- > The intent here is allow the multipart/alternative to give an indication of > what lies inside, without having to be specific about _where_ inside it may > be found. That's fine, but in such a case you need to be very clear that's what's intended. The problem is that people will naturally assume ordering in such a case. > > If there's a strong consensus that specific per-part indicators are too > > complex (and I do see the issues with multipart/alternative where the > > parts are themselves composite) or have other problems and hence this > > restriction should be retained, that's fine. But in such a case I would > > use language like "implementations MUST NOT assume a one-to-one > > relationship" in section 3.1.2, I would reiterate this point in section > > 4.3, and I would deliberately make the example in section 4.3, > > incomplete, out of order, more complex, or perhaps all three. > Is this affected by my explanaton above? No, your explanation makes these changes necessary IMO. All this is doing is making it very clear that there is no order to these sets. Ned From owner-ietf-medfree@imc.org Wed Feb 16 07:23:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23817 for ; Wed, 16 Feb 2000 07:22:57 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA01634 for ietf-medfree-bks; Wed, 16 Feb 2000 04:12:10 -0800 (PST) Received: from msw.mimesweeper.com (msw.mimesweeper.com [194.168.90.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA01628 for ; Wed, 16 Feb 2000 04:12:07 -0800 (PST) Received: from bell.mimesweeper.com (unverified) by msw.mimesweeper.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 16 Feb 2000 12:17:47 +0000 Received: from GK-VAIO (gk-vaio.mimesweeper.com [194.168.90.137]) by bell.mimesweeper.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DKP3H99V; Wed, 16 Feb 2000 12:17:01 -0000 Message-Id: <4.2.2.20000216120010.00bc5690@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 16 Feb 2000 12:16:26 +0000 To: ned.freed@INNOSOFT.COM From: Graham Klyne Subject: Re: Last Call: Indicating media features for MIME content to (fwd) Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , ietf-medfree@imc.org, Keith Moore In-Reply-To: <01JLXS1GURSG000979@MAUVE.INNOSOFT.COM> References: <"Your message dated Tue, 15 Feb 2000 12:00:50 +0000" <4.2.2.20000215113221.00ae7100@pop.dial.pipex.com> <1661387.3159588349@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ned, I think we are in agreement. To summarize the proposed changes (mainly for the benefit of others following this): draft-ietf-conneg-feature-type-02.txt: (a) restrict content of type to content-type only, without parameters. (b) add text explaining how to deal with content-type parameters. draft-ietf-conneg-content-features-xx.txt: (c) clarification of interpretation of Content-feature headers on outer multipart. Specifically, MUST NOT assume relationship between outer header and any specific inner part. Also explain that content-feature can be applied directly to any inner body part. (d) add text pointing out that whitespace is allowed in feature expressions, and that this facilitates header wrapping. (e) add text to security considerations about placement of content-features header on a multipart/signed document. #g -- At 01:16 PM 2/15/00 -0800, ned.freed@INNOSOFT.COM wrote: >> >Here are my comments on these documents: >> > >> > Comments on draft-ietf-conneg-feature-type-02.txt: >> > >> > I'm very concerned about the handling of content-type parameters in >> > section 3. I really don't like allowing them as part of the type tag. I >> > see real problems with canonicalization, ordering, case >> sensitivity, and >> > so on. >> > >> > I suggest that content-type parameters be excluded from the type >> feature >> > tag. If we need to be able to describe parameters (and I think we >> do need >> > to be able to do this, if only to handle charset= for text subtypes), >> > I would suggest defining a new tag "type-parameter" whose value is >> of the >> > form "name=value". (I'm assuming that a feature tag can be repeated >> with >> > different values; if not then there's a real problem representing MIME >> > information in feature tags.) > >>I generally agree with the basic premise -- I have tried to discourage the >>use of parameters in type parameters, but was maybe too timid in not >>prohibiting them outright. I personally have no problem, with outright >>prohibition of parameters within a "type" value. > >>However, I don't think that Ned's proposed solution works too well, for a >>couple of reasons: > >>(a) the assumption that a tag can be repeated with different values does >>not hold: the logical structure of feature expressions assumes only one >>value can be asserted for a given feature tag in any particular feature >>collection ("instance"). For example, suppose we have three type parameters: > >> charset=US-ASCII >> charset=UTF-8 >> language=EN-US > >>is this to mean all three must be simultaneously true (logical AND, leading >>to a contradiction), or that any one must be true (logical OR, which fails >>to assert anything about charset of language), or some combination such as: > >> (& (| (charset=US-ASCII) (charset=UTF-8) ) (language=EN-US) ) > >>The intent of the feature framework is to be able to capture combinations >>like the final example. > >>(b) one of the design principles that we agreed for feature tags is that >>the _meaning_ of a tag should _never_ depend on the value of another >>tag. This would be violated by having a generic 'type-parameter' tag whose >>meaning would depend on the value of a 'type' tag. > >>The solution I would suggest is that new feature tags are defined for >>content-type parameter values that are significant for content >>negotiation/description. Paul Hoffman has prepared a draft dealing with >>charset and language, which I would like to see progressed on a similar >>timeframe to these. > >I'm not particularly fond of this as it creates an open-ended registration >problem. However, given the way this stuff works I agree there is >realistically >no other way to do it. So I suggest proceeding by prohibiting parameters from >the content-type feature tag and adding text describing what must be done when >such parameters come up. > >> > I am concerned about the section 3.1.2 "No one-to-one relationship >> > between headers and contained body parts is assumed" rule, >> especially in >> > the case of multipart/alternative. I think it would be useful to have >> > the ability to express specific per-part content features in the >> > multipart/alternative case. And more importantly, I think people are >> > likely to assume a relationship unless this restriction is called out a >> > lot more aggressively in the document. > >>I had taken the view that per-part content feature indications would be >>expressed by applying 'Content-features' directly to the part concerned. > >>Maybe my text isn't clear? I had meant to say that there was no 1:1 >>correspondence between headers on the outermost content-type and the >>contained body parts. e.g: > >> Content-type: multipart/alternative;boundary="next" >> Content-features: () >> Content-features: () > >> --next >> Content-type: text/plain >> Content-features: () >> : >> --next >> Content-type: text/html >> Content-features: () >> : >> --next >> Content-type: image/tiff >> Content-features: () >> : >> --next-- > >>The intent here is allow the multipart/alternative to give an indication of >>what lies inside, without having to be specific about _where_ inside it may >>be found. > >That's fine, but in such a case you need to be very clear that's what's >intended. The problem is that people will naturally assume ordering in such >a case. > >> > If there's a strong consensus that specific per-part indicators are too >> > complex (and I do see the issues with multipart/alternative where the >> > parts are themselves composite) or have other problems and hence this >> > restriction should be retained, that's fine. But in such a case I would >> > use language like "implementations MUST NOT assume a one-to-one >> > relationship" in section 3.1.2, I would reiterate this point in section >> > 4.3, and I would deliberately make the example in section 4.3, >> > incomplete, out of order, more complex, or perhaps all three. > >>Is this affected by my explanaton above? > >No, your explanation makes these changes necessary IMO. All this is doing is >making it very clear that there is no order to these sets. > > Ned ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-medfree@imc.org Fri Feb 18 05:20:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18895 for ; Fri, 18 Feb 2000 05:20:06 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA09335 for ietf-medfree-bks; Fri, 18 Feb 2000 02:11:01 -0800 (PST) Received: from hotmail.com (f75.law8.hotmail.com [216.33.241.75]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA09330 for ; Fri, 18 Feb 2000 02:11:00 -0800 (PST) Received: (qmail 94612 invoked by uid 0); 18 Feb 2000 10:14:10 -0000 Message-ID: <20000218101410.94611.qmail@hotmail.com> Received: from 202.135.194.18 by www.hotmail.com with HTTP; Fri, 18 Feb 2000 02:14:10 PST X-Originating-IP: [202.135.194.18] From: "Paul Ulrich" To: ietf-medfree@imc.org Subject: RE: Last Call: Indicating media features for MIME content to Proposed Standard Date: Fri, 18 Feb 2000 02:14:10 PST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I’d like to applaud your initiative and Graham Klyne’s drafting of “Indicating media features for MIME content” as well as the informational “Protocol-independent Content Negotiation Framework”. I think they are both excellent and address a problem that I see as a lay user of the Internet: improved management of message and non-message data. I only recently stumbled across your working group in my search for whether anyone was doing XML metadata for messaging. It seems that your proposals fit nicely with that notion, and I’m wondering whether you are collaborating with the IETF-Trade Working Group on its XML Messaging, the joint W3C/WAP Forum work on its Composite Capability/Preference Profiles, or the United Nations ebXML. This may be a minor point, but can “Content-features” in the draft include, for example, word count (or duration for audio/video messages)? I’m not a programmer so I don’t know what’s possible. From a mobile user’s perspective, however, it would be nice to be able to decide in advance (say, via receipt of an XML token or tag) whether I want to download a particular message (or parts of it) from a series of incoming transmissions. Knowing for example, that a particular message is 100 words long versus 1,000 (or 1 minute versus ten in duration) would be useful at times, even if my device could download either length. A longer, less important message (screened via XML tags) I might specify for later downloading to a different device like a PC or laptop. (Just having kilobyte file size might not be so helpful, as it may vary considerably depending on the amount and types of included graphics or formatting.) Will the draft under consideration permit this kind of feature? Paul Ulrich Cambridge, Massachusetts ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ietf-medfree@imc.org Fri Feb 18 17:31:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03308 for ; Fri, 18 Feb 2000 17:31:10 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA04994 for ietf-medfree-bks; Fri, 18 Feb 2000 14:25:23 -0800 (PST) Received: from kiwi.equinix.com (kiwi.equinix.com [207.20.85.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04990 for ; Fri, 18 Feb 2000 14:25:22 -0800 (PST) Received: (from hardie@localhost) by kiwi.equinix.com (8.9.3/8.9.3) id OAA11382; Fri, 18 Feb 2000 14:29:04 -0800 (PST) Message-Id: <200002182229.OAA11382@kiwi.equinix.com> Subject: Re: Last Call: Indicating media features for MIME content to Proposed Standard To: paul_ulrich@hotmail.com (Paul Ulrich) Date: Fri, 18 Feb 2000 14:29:04 -0800 (PST) Cc: ietf-medfree@imc.org In-Reply-To: <20000218101410.94611.qmail@hotmail.com> from "Paul Ulrich" at Feb 18, 2000 02:14:10 AM From: hardie@equinix.com Reply-to: hardie@equinix.com X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Thanks for your comments. To answer your questions on coordination, both Graham Klyne and I are participating in the W3C's CCPP effort; we and other members of the group also follow the TRADE working group, as well as RESCAP, CNRP, and a variety of other related work. I am not familiar with the UN ebXML work; do you have a pointer so that I could follow that area up? As for your questions of length (word count, duration, etc.), there is currently no registered feature tag which would cover that feature. I had originally seen other protocol elements (like Content-length) as having too high an overlap. I can see, however, that there are some advantages to an abstracted duration as opposed to size. I am not sure whether a single feature could actually cover this ground. If you or a group with which you are working would like to propose such a feature, I would be happy to personally review it. Since this group is nearing the end of its established milestones, I would be reluctant to add it as work item of the group. best regards, Ted Hardie Chair, CONNEG > > I’d like to applaud your initiative and Graham Klyne’s drafting of > “Indicating media features for MIME content” as well as the informational > “Protocol-independent Content Negotiation Framework”. I think they are both > excellent and address a problem that I see as a lay user of the Internet: > improved management of message and non-message data. > > I only recently stumbled across your working group in my search for whether > anyone was doing XML metadata for messaging. It seems that your proposals > fit nicely with that notion, and I’m wondering whether you are collaborating > with the IETF-Trade Working Group on its XML Messaging, the joint W3C/WAP > Forum work on its Composite Capability/Preference Profiles, or the United > Nations ebXML. > > This may be a minor point, but can “Content-features” in the draft include, > for example, word count (or duration for audio/video messages)? I’m not a > programmer so I don’t know what’s possible. From a mobile user’s > perspective, however, it would be nice to be able to decide in advance (say, > via receipt of an XML token or tag) whether I want to download a particular > message (or parts of it) from a series of incoming transmissions. Knowing > for example, that a particular message is 100 words long versus 1,000 (or 1 > minute versus ten in duration) would be useful at times, even if my device > could download either length. A longer, less important message (screened > via XML tags) I might specify for later downloading to a different device > like a PC or laptop. (Just having kilobyte file size might not be so > helpful, as it may vary considerably depending on the amount and types of > included graphics or formatting.) Will the draft under consideration permit > this kind of feature? > > Paul Ulrich > Cambridge, Massachusetts > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com > From owner-ietf-medfree@imc.org Fri Feb 25 19:16:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23540 for ; Fri, 25 Feb 2000 19:16:38 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA05683 for ietf-medfree-bks; Fri, 25 Feb 2000 16:09:47 -0800 (PST) Received: from mail.ntkcom.com (www.ntkonlineshoppingmall.com [216.216.38.83]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA05679 for ; Fri, 25 Feb 2000 16:09:45 -0800 (PST) Received: (qmail 19878 invoked by uid 0); 26 Feb 2000 01:24:03 -0000 Date: 26 Feb 2000 01:24:03 -0000 Message-ID: <20000226012403.19877.qmail@mail.ntkcom.com> Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain MIME-Version: 1.0 X-Mailer: MIME::Lite 1.135 (B2.11; Q2.03) From: Calendar-On-Line@ntktermlifeinsurance.com To: ietf-medfree@imc.org Subject: A Leap Year 2000 Reminder Sender: owner-ietf-medfree@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: binary Leap Year 2000 - an extra day to spend quality time with your family. It's also a great opportunity to take a few of those extra minutes to review your life insurance, purchase additional protection, or apply for this important coverage to protect your family if you haven't already done so. It's really quite EASY and you can do it right now in the privacy of your home or office. And we can help! Determine your life insurance needs using our coverage calculator located at http://www.ntktermlifeinsurance.com/term_life_insurance_calculator.html or navigate our site from our main page at http://www.NTKTermLifeInsurance.com. Either way, you are under NO OBLIGATION and you'll find that we are QUICK, EASY, INFORMATIVE and HASSLE FREE. We represent over 50 of the insurance industry's TOP RATED companies. We provide you with the FREEDOM TO COMPARE QUOTES and the ability to APPLY ON-LINE. Quite simply, WE ARE THE BEST PLACE FOR YOUR INSURANCE NEEDS! If you prefer, feel free to use our TOLL-FREE Quote-BY-Phone System by calling 1-888-368-5685. We look forward to assisting you with all of your insurance needs! ------------------------------------------------------------------ To be removed from our email list please call us at (888)NTK-2002. ------------------------------------------------------------------