From owner-malloc@catarina.usc.edu Thu Oct 1 11:06:51 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id LAA06814 for ; Thu, 1 Oct 1998 11:06:49 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id HAA12018 for malloc-list; Thu, 1 Oct 1998 07:29:37 -0700 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id HAA12014 for ; Thu, 1 Oct 1998 07:29:32 -0700 Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA38822; Thu, 1 Oct 1998 10:29:21 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA04932; Thu, 1 Oct 1998 10:26:20 -0400 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id KAA19544; Thu, 1 Oct 1998 10:26:19 -0400 (EDT) Message-Id: <199810011426.KAA19544@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: Munil Shah cc: "'Vern Paxson'" , "'Steve Hanna'" , "'malloc@catarina.usc.edu'" Subject: Re: MDHCP changes In-reply-to: Your message of "Tue, 29 Sep 1998 17:40:18 PDT." Date: Thu, 01 Oct 1998 10:26:19 -0400 From: Thomas Narten Sender: owner-malloc@catarina.usc.edu Precedence: bulk > > So how much opportunity for common code is left? Is it enough to > > merit any semblence of compatibility? > There is still a plenty of opportunity for common code. The administration, > ipaddress management are two big things. Could you please elaborate a bit? Seems like the administration/address management issues might be server implementation issues and don't have a direct dependency on the packet format used between clients/server. I.e., couldn't you have a simple mapping layer between the packet formats and what the backend code for the existing server wants? Steve Hanna writes: > We have also agreed to remove the chaddr, sname, and file fields from the packet > format. This will remove 208 of the 228 bytes currently devoted to reserved > fields within the MDHCP packet format. Removing more fields would make it > difficult to share any code between MDHCP and DHCP implementations. which 20 bytes are left, and exactly what fields do they represent? Is the issue that the information contained in those fields is needed for compatability (in which case the packet format could potentially be changed without loss of flexibility) or are the exact fields (format/syntax/semantics) needed? Are those fields directly relevant to malloc? Thomas From owner-malloc@catarina.usc.edu Thu Oct 1 13:43:22 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id NAA12332 for ; Thu, 1 Oct 1998 13:43:21 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA12478 for malloc-list; Thu, 1 Oct 1998 10:15:57 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA12474 for ; Thu, 1 Oct 1998 10:15:43 -0700 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA13776; Thu, 1 Oct 1998 10:15:06 -0700 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id NAA00990; Thu, 1 Oct 1998 13:15:01 -0400 Received: from bcn.East.Sun.COM by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id NAA01434; Thu, 1 Oct 1998 13:15:02 -0400 Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id NAA22708; Thu, 1 Oct 1998 13:14:59 -0400 Message-Id: <199810011714.NAA22708@bcn.East.Sun.COM> Date: Thu, 1 Oct 1998 13:15:01 -0400 (EDT) From: Steve Hanna Reply-To: Steve Hanna Subject: Re: MDHCP changes To: narten@raleigh.ibm.com Cc: malloc@catarina.usc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: jklGM58J3ivBHkjGMU6ywg== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-malloc@catarina.usc.edu Precedence: bulk > > We have also agreed to remove the chaddr, sname, and file fields from the > > packet format. This will remove 208 of the 228 bytes currently devoted to > > reserved fields within the MDHCP packet format. Removing more fields would > > make it difficult to share any code between MDHCP and DHCP implementations. > > which 20 bytes are left, and exactly what fields do they represent? > Is the issue that the information contained in those fields is needed > for compatability (in which case the packet format could potentially > be changed without loss of flexibility) or are the exact fields > (format/syntax/semantics) needed? Are those fields directly relevant > to malloc? The remaining reserved fields are: op (1 byte), htype (1), hlen (1), hops (1), secs (2), flags (2), ciaddr (4), siaddr (4), and giaddr (4). None of these fields are relevant to malloc. All of these fields are defined in the MDHCP spec as "Must be zero" (or something similar). They are retained in MDHCP only to make it easier to share code between DHCP and MDHCP implementation. -Steve From owner-malloc@catarina.usc.edu Fri Oct 2 00:41:35 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id AAA27361 for ; Fri, 2 Oct 1998 00:41:34 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id VAA15113 for malloc-list; Thu, 1 Oct 1998 21:21:44 -0700 Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id VAA15109 for ; Thu, 1 Oct 1998 21:21:35 -0700 Received: by mail4.microsoft.com with Internet Mail Service (5.5.2232.9) id <4BAKKAXS>; Thu, 1 Oct 1998 21:21:05 -0700 Message-ID: From: Munil Shah To: "'Thomas Narten'" Cc: "'Vern Paxson'" , "'Steve Hanna'" , "'malloc@catarina.usc.edu'" Subject: RE: MDHCP changes Date: Thu, 1 Oct 1998 21:21:04 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-malloc@catarina.usc.edu Precedence: bulk > There is still a plenty of opportunity for common code. The administration, > ipaddress management are two big things. Could you please elaborate a bit? >> The implementation which i have been able to reuse include header formatting and parsing, options processing, stable store use/management and the dhcp administration interface. By removing the 3 big fields from the dhcp packet format (boot file name, server, hardware id) we can eliminate the majority of unused fields without causing significant code changes to the packet formatting and parsing. By keeping the packet format almost similar we can reuse this portion of implementation on both client and the server. Thanks, Munil From owner-malloc@catarina.usc.edu Fri Oct 2 18:29:46 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id SAA10863 for ; Fri, 2 Oct 1998 18:29:46 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA17682 for malloc-list; Fri, 2 Oct 1998 13:54:30 -0700 Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA17678 for ; Fri, 2 Oct 1998 13:54:26 -0700 Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.1/8.9.1) id NAA25205; Fri, 2 Oct 1998 13:54:23 -0700 (PDT) Message-Id: <199810022054.NAA25205@daffy.ee.lbl.gov> To: Steve Hanna , munils@MICROSOFT.com Cc: malloc@catarina.usc.edu Subject: Re: MDHCP changes In-reply-to: Your message of Thu, 01 Oct 1998 13:15:01 PDT. Date: Fri, 02 Oct 1998 13:54:23 PDT From: Vern Paxson Sender: owner-malloc@catarina.usc.edu Precedence: bulk > The remaining reserved fields are: op (1 byte), htype (1), hlen (1), hops (1), > secs (2), flags (2), ciaddr (4), siaddr (4), and giaddr (4). None of these > fields are relevant to malloc. All of these fields are defined in the MDHCP spec > as "Must be zero" (or something similar). They are retained in MDHCP only to > make it easier to share code between DHCP and MDHCP implementation. I'm still not getting it. How do must-be-zero fields, none of which are relevant to malloc, help with sharing code? There's nothing useful in the fields, and I'm having trouble seeing how having the exact same packet format can save more than a few lines of code. I could see perhaps having the same style of options as saving some code; but can somone please explain how the presence of the empty fields on the wire is actually a significant win? Vern From owner-malloc@catarina.usc.edu Mon Oct 5 15:17:38 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id PAA26293 for ; Mon, 5 Oct 1998 15:17:38 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA24800 for malloc-list; Mon, 5 Oct 1998 11:37:19 -0700 Received: from north.lcs.mit.edu ([18.26.0.4]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA24796 for ; Mon, 5 Oct 1998 11:37:12 -0700 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id OAA21657; Mon, 5 Oct 1998 14:37:06 -0400 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: malloc@catarina.usc.edu Subject: Abstract API and Broken Scopes Date: Mon, 05 Oct 1998 14:37:06 -0400 Message-ID: <21655.907612626@north.lcs.mit.edu> Sender: owner-malloc@catarina.usc.edu Precedence: bulk Dave Thaler and I were just reviewing MZAP open issues, and one question came up that we thought we should consult this list about: In the Malloc Abstract API, when the client asks for the admin scopes that apply to be enumerated, should the server return all the scopes it knows about, or should it hide scopes that MZAP reveals to be broken? Scope zones can be broken because they're not convex, not closed, or overlap with another zone in address range. If the zone is not convex, we might still want to allocate an address from it. In the other cases I'm not sure. One option might be for the API to return all the scope zones and to have a status code associated with each zone with a value indicating the zone is OK, or the type of problem detected. User applications can then choose to present broken scope zones to the user or not as they think appropriate rather than having this information filtered below the API. Comments? Cheers, Mark From owner-malloc@catarina.usc.edu Mon Oct 5 17:08:37 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id RAA28560 for ; Mon, 5 Oct 1998 17:08:36 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA25054 for malloc-list; Mon, 5 Oct 1998 13:09:55 -0700 Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.14]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA25050 for ; Mon, 5 Oct 1998 13:09:49 -0700 Received: from mg136-147.ricochet.net (mg136-147.ricochet.net [204.179.136.147]) by proxy3.ba.best.com (8.9.0/8.9.0/best.out) with SMTP id NAA02208 for ; Mon, 5 Oct 1998 13:07:21 -0700 (PDT) Message-Id: <3.0.5.16.19981005125805.23677eae@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16) Date: Mon, 05 Oct 1998 12:58:05 To: malloc@catarina.usc.edu From: Ross Finlayson Subject: Re: Abstract API and Broken Scopes In-Reply-To: <21655.907612626@north.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-malloc@catarina.usc.edu Precedence: bulk At 02:37 PM 10/5/98 -0400, Mark Handley wrote: >In the Malloc Abstract API, when the client asks for the admin scopes >that apply to be enumerated, should the server return all the scopes >it knows about, or should it hide scopes that MZAP reveals to be >broken? I think it's safest/best for applications not to be told anything about admin scopes that are broken. Learning about broken admin scopes should be the responsibility of system administrator(s), using some separate "MZAP management" API (e.g., tied in with SNMP or whatever). We should be keeping things simple for application developers, and not overloading them with functionality that really belongs under system administration. >If the zone is not >convex, we might still want to allocate an address from it. I'd rather see such zones 'fixed' first. Keeping a non-convex zone hidden from applications will provide an additional incentive to get it fixed. Ross. From owner-malloc@catarina.usc.edu Tue Oct 6 12:51:57 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id MAA21264 for ; Tue, 6 Oct 1998 12:51:57 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id JAA28306 for malloc-list; Tue, 6 Oct 1998 09:04:34 -0700 Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id JAA28302 for ; Tue, 6 Oct 1998 09:04:26 -0700 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id MAA22778; Tue, 6 Oct 1998 12:04:24 -0400 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: malloc@catarina.usc.edu Subject: AAP timestamps Date: Tue, 06 Oct 1998 12:04:24 -0400 Message-ID: <22776.907689864@north.lcs.mit.edu> Sender: owner-malloc@catarina.usc.edu Precedence: bulk Currently AAP specifies timestamps to be number of seconds since 1st Jan 1970 as a 32 bit unsigned integer. This means we're safe from wrapping timestamps until the year 2106 (assuming everyone implements them as unsigned). Should we consider making these timestamps 64 bits so we'll never have a problem? This would almost double the bandwidth or halve the announcement rate, so the cost of doing so is not insignificant. Cheers, Mark From owner-malloc@catarina.usc.edu Tue Oct 6 14:36:37 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id OAA23679 for ; Tue, 6 Oct 1998 14:36:36 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA28679 for malloc-list; Tue, 6 Oct 1998 10:21:06 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA28675 for ; Tue, 6 Oct 1998 10:21:01 -0700 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA11358; Tue, 6 Oct 1998 10:20:29 -0700 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id NAA20235; Tue, 6 Oct 1998 13:20:25 -0400 Received: from bcn.East.Sun.COM by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id NAA15830; Tue, 6 Oct 1998 13:20:27 -0400 Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id NAA05997; Tue, 6 Oct 1998 13:20:24 -0400 Message-Id: <199810061720.NAA05997@bcn.East.Sun.COM> Date: Tue, 6 Oct 1998 13:20:25 -0400 (EDT) From: Steve Hanna Reply-To: Steve Hanna Subject: Re: AAP timestamps To: mjh@EAST.ISI.EDU Cc: malloc@catarina.usc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: uWR3O3Avr7QV28R/ZSDIcg== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-malloc@catarina.usc.edu Precedence: bulk Mark Handley wrote: > Currently AAP specifies timestamps to be number of seconds since 1st > Jan 1970 as a 32 bit unsigned integer. This means we're safe from > wrapping timestamps until the year 2106 (assuming everyone implements > them as unsigned). > > Should we consider making these timestamps 64 bits so we'll never have > a problem? This would almost double the bandwidth or halve the > announcement rate, so the cost of doing so is not insignificant. I would say no. We can easily use windowing to redefine the range half way through. That is, after the current time is solidly > 2^31 (about year 2039), you redefine the low half of the range to start at 2106 and go up to 2175 (or whatever). So long as all systems using this protocol are updated every 70 years or less, there is no problem. Since all times currently in use will be within a few years of the current time (at most), there's no problem of old data. Thanks, Steve Hanna From owner-malloc@catarina.usc.edu Tue Oct 6 20:22:25 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id UAA27447 for ; Tue, 6 Oct 1998 20:22:25 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id QAA00130 for malloc-list; Tue, 6 Oct 1998 16:52:36 -0700 Received: from dip.eecs.umich.edu (thalerd@dip.eecs.umich.edu [141.212.99.5]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id QAA00123 for ; Tue, 6 Oct 1998 16:52:30 -0700 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.9.1/8.9.0) id TAA03850; Tue, 6 Oct 1998 19:52:26 -0400 (EDT) From: Dave Thaler Message-Id: <199810062352.TAA03850@dip.eecs.umich.edu> Subject: Re: Abstract API and Broken Scopes To: finlayson@live.com (Ross Finlayson) Date: Tue, 6 Oct 1998 19:52:25 -0400 (EDT) Cc: malloc@catarina.usc.edu In-Reply-To: <3.0.5.16.19981005125805.23677eae@shell7.ba.best.com> from "Ross Finlayson" at Oct 5, 98 12:58:05 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Ross wrote: > I think it's safest/best for applications not to be told anything about > admin scopes that are broken. Learning about broken admin scopes should be > the responsibility of system administrator(s), using some separate "MZAP > management" API (e.g., tied in with SNMP or whatever). > > We should be keeping things simple for application developers, and not > overloading them with functionality that really belongs under system > administration. > > >If the zone is not > >convex, we might still want to allocate an address from it. > > I'd rather see such zones 'fixed' first. Keeping a non-convex zone hidden > from applications will provide an additional incentive to get it fixed. Since no one else has responded yet, I'll say that I agree with Ross's points above. -Dave From owner-malloc@catarina.usc.edu Wed Oct 7 17:31:17 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id RAA19871 for ; Wed, 7 Oct 1998 17:31:16 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id OAA03630 for malloc-list; Wed, 7 Oct 1998 14:11:18 -0700 Received: from dip.eecs.umich.edu (thalerd@dip.eecs.umich.edu [141.212.99.5]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA03624 for ; Wed, 7 Oct 1998 14:11:12 -0700 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.9.1/8.9.0) id RAA09145; Wed, 7 Oct 1998 17:11:09 -0400 (EDT) From: Dave Thaler Message-Id: <199810072111.RAA09145@dip.eecs.umich.edu> Subject: Language support for scope enumeration To: malloc@catarina.usc.edu Date: Wed, 7 Oct 1998 17:11:08 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk One of the topics Mark, Pavlin, and I discussed during this week's meeting on the MBone was that of language support for scope names. We propose to do the following in MZAP: * Replace the "scope name" in the MZAP spec with a list of (language tag, scope name) pairs. Language tags are described in RFC 1766. * Each scope may have at most one name per language (multiples signal a config error). * MAAS's will thus see all scope names. * MZAP message may also label a specific (language tag, scope name) pair as the "default name" to display if none matches your desired language. Since you have the actual language tag, you can tell how to render the default name. * Only one language (per scope) can be tagged as the default name. (Multiples could signal a config error, such as if one router says English is default and another one says French is default). This would allow the abstract API and MDHCP to support language localization (which is required for them to get through the IESG acc. to Alvestrand and RFC 2277). Presumably the enumerate scopes call would take a language tag as an input parameter and the MAAS would use that to decide which names to pass back. Munil and Ross have each said that the above sounds reasonable. Any other comments from the list? -Dave From owner-malloc@catarina.usc.edu Fri Oct 9 14:53:04 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id OAA04874 for ; Fri, 9 Oct 1998 14:53:03 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA10796 for malloc-list; Fri, 9 Oct 1998 11:12:44 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA10787 for ; Fri, 9 Oct 1998 11:12:35 -0700 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA11855; Fri, 9 Oct 1998 11:12:03 -0700 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id OAA18679; Fri, 9 Oct 1998 14:11:59 -0400 Received: from bcn.East.Sun.COM (bcn [129.148.75.4]) by suneast.East.Sun.COM (8.8.8+Sun/8.8.8) with SMTP id OAA03247; Fri, 9 Oct 1998 14:12:00 -0400 (EDT) Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id OAA16473; Fri, 9 Oct 1998 14:11:59 -0400 Message-Id: <199810091811.OAA16473@bcn.East.Sun.COM> Date: Fri, 9 Oct 1998 14:11:59 -0400 (EDT) From: Steve Hanna Reply-To: Steve Hanna Subject: Re: Language support for scope enumeration To: thalerd@eecs.umich.edu Cc: malloc@catarina.usc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Vx1lNbYyH2rObpXfKALaSg== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-malloc@catarina.usc.edu Precedence: bulk > * Replace the "scope name" in the MZAP spec with a list of > (language tag, scope name) pairs. Language tags are described > in RFC 1766. Good idea! Do we want to *require* a language tag for each scope name? It might be hard to force the user to enter one. And it is possible for a scope name to include more than one language (although I doubt this would be common). I suggest that the first item in the pair be a comma-separated list of language tags where the empty string indicates no language tag at all. > * Each scope may have at most one name per language > (multiples signal a config error). It might be useful to have more than one name per language. For instance, a scope might be named "Company-wide", "IBM", and "International Business Machines" (all with the language tag "en"). > * MAAS's will thus see all scope names. > * MZAP message may also label a specific (language tag, scope name) > pair as the "default name" to display if none matches your > desired language. Since you have the actual language tag, > you can tell how to render the default name. I assume this would also apply if you don't know which language (or languages) the user wants. > * Only one language (per scope) can be tagged as the default name. > (Multiples could signal a config error, such as if one router says > English is default and another one says French is default). > > This would allow the abstract API and MDHCP to support language > localization (which is required for them to get through the IESG > acc. to Alvestrand and RFC 2277). Presumably the enumerate scopes > call would take a language tag as an input parameter and the MAAS > would use that to decide which names to pass back. What if the user can speak two languages? Do you pass in two languages (like "en, fr")? And what if none of the language tags match exactly (user specifies "en", only choice is "en-US")? And what if you have many users who speak many different languages? I'm somewhat reluctant to make the MAAS responsible for deciding which names to return. I would like to have some way to ask the MAAS for *all* names. Thanks, Steve From owner-malloc@catarina.usc.edu Fri Oct 9 16:06:30 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id QAA05953 for ; Fri, 9 Oct 1998 16:06:30 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA11153 for malloc-list; Fri, 9 Oct 1998 12:40:21 -0700 Received: from dip.eecs.umich.edu (thalerd@dip.eecs.umich.edu [141.212.99.5]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA11149 for ; Fri, 9 Oct 1998 12:40:16 -0700 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.9.1/8.9.0) id PAA05130; Fri, 9 Oct 1998 15:40:11 -0400 (EDT) From: Dave Thaler Message-Id: <199810091940.PAA05130@dip.eecs.umich.edu> Subject: Re: Language support for scope enumeration To: shanna@bcn.East.Sun.COM Date: Fri, 9 Oct 1998 15:40:10 -0400 (EDT) Cc: thalerd@eecs.umich.edu, malloc@catarina.usc.edu In-Reply-To: <199810091811.OAA16473@bcn.East.Sun.COM> from "Steve Hanna" at Oct 9, 98 02:11:59 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk > > * MZAP message may also label a specific (language tag, scope name) > > pair as the "default name" to display if none matches your > > desired language. Since you have the actual language tag, > > you can tell how to render the default name. > > I assume this would also apply if you don't know which language (or > languages) the user wants. Sorry, I misread your statement the first time. Yes, you are correct. This would apply if the API caller cannot determine the desired language (or has no preference). -Dave From owner-malloc@catarina.usc.edu Fri Oct 9 16:25:10 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id QAA06197 for ; Fri, 9 Oct 1998 16:25:09 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA11130 for malloc-list; Fri, 9 Oct 1998 12:35:59 -0700 Received: from dip.eecs.umich.edu (thalerd@dip.eecs.umich.edu [141.212.99.5]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA11126 for ; Fri, 9 Oct 1998 12:35:54 -0700 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.9.1/8.9.0) id PAA04759; Fri, 9 Oct 1998 15:35:48 -0400 (EDT) From: Dave Thaler Message-Id: <199810091935.PAA04759@dip.eecs.umich.edu> Subject: Re: Language support for scope enumeration To: shanna@bcn.East.Sun.COM Date: Fri, 9 Oct 1998 15:35:48 -0400 (EDT) Cc: thalerd@eecs.umich.edu, malloc@catarina.usc.edu In-Reply-To: <199810091811.OAA16473@bcn.East.Sun.COM> from "Steve Hanna" at Oct 9, 98 02:11:59 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk > Do we want to *require* a language tag for each scope name? In the discussion between Pavlin, Mark, and I, one of them stated that sometimes you cannot render a name unless you know the language, and hence requiring a language tag may be required. > It might be hard to force the user to enter one. It would require the abstract API caller to have one. If it can't make the user enter one, then it would need to choose one itself somehow. > And it is possible for a scope name to include more > than one language (although I doubt this would be common). I suggest that the > first item in the pair be a comma-separated list of language tags where the > empty string indicates no language tag at all. Offhand, this sounds too complex to me. Using the original proposal, this would be best represented by a single language tag, and marking it as the default. > > * Each scope may have at most one name per language > > (multiples signal a config error). > > It might be useful to have more than one name per language. For instance, a > scope might be named "Company-wide", "IBM", and "International Business > Machines" (all with the language tag "en"). This is a tradeoff. We decided that we preferred the greater ability to diagnose misconfigurations which you gained by forcing only one name. However, this is something which people can provide input on. You have to understand that if you allow multiples, then you can't detect collisions (one router says it's the "IBM" scope and another says it's the "Sun" scope). It also complicates the abstract API, since a client wanting to enumerate scopes in a particular language wouldn't get one name per scope. I still prefer one name per scope (for the above reasons). More comments on this topic would be appreciated. > > * MAAS's will thus see all scope names. > > * MZAP message may also label a specific (language tag, scope name) > > pair as the "default name" to display if none matches your > > desired language. Since you have the actual language tag, > > you can tell how to render the default name. > > I assume this would also apply if you don't know which language (or languages) > the user wants. No, the main case targetted is one where you know which language the user wants (e.g. "Klingon"), but there's no scope name in that language. So the MAAS passes back the default name in the enumerate scopes api. > What if the user can speak two languages? Do you pass in two languages (like > "en, fr")? And what if none of the language tags match exactly (user > specifies > "en", only choice is "en-US")? And what if you have many users who speak many > different languages? Typically people configure their machine with a specific language (in today's OS's). If you wanted to write a tool which is tailored for bilingual people, then I would expect that this tool would use the abstract API by calling enumerate scopes twice, once for each language, and then combining the results it gets. > I'm somewhat reluctant to make the MAAS responsible for deciding which > names to return. Agree. The proposal was that the client specify the language in the enumerate scopes request. > I would like to have some way to ask the MAAS for *all* names. I'm not sure there's value in that, except for management, where this can be supported via SNMP. Can you provide an example where an end-user would care? Thanks, -Dave From owner-malloc@catarina.usc.edu Fri Oct 9 16:59:09 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id QAA06652 for ; Fri, 9 Oct 1998 16:59:08 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA11456 for malloc-list; Fri, 9 Oct 1998 13:30:25 -0700 Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA11452 for ; Fri, 9 Oct 1998 13:30:20 -0700 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id QAA28503; Fri, 9 Oct 1998 16:30:07 -0400 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Steve Hanna cc: thalerd@eecs.umich.edu, malloc@catarina.usc.edu Subject: Re: Language support for scope enumeration In-reply-to: Your message of "Fri, 09 Oct 1998 16:23:27 EDT." <199810092023.QAA16923@bcn.East.Sun.COM> Date: Fri, 09 Oct 1998 16:30:07 -0400 Message-ID: <28501.907965007@north.lcs.mit.edu> Sender: owner-malloc@catarina.usc.edu Precedence: bulk >> > Do we want to *require* a language tag for each scope name? >> >> In the discussion between Pavlin, Mark, and I, one of them >> stated that sometimes you cannot render a name unless you know >> the language, and hence requiring a language tag may be >> required. > >Since we are using Unicode, I expect that this situation would arise rarely. >Does anyone have a specific example? My recollection is that this is an issue with some far eastern languages. I'm not an expert on this, but I heard that although Chinese and Japanese share Kanji and the unicode for them, you can't decide how to render them correctly unless you know which language it's in. Perhaps someone with more experience of this can correct me if I got this wrong. I guess another example would be if you wanted to put the name through a text-to-speech system such as the one Jeremy Hall uses. Different languages that are all using the same western european characters pronounce those characters differently. You need to know which language it is to even get close to the correct pronunication (let alone accents :-). Cheers, Mark From owner-malloc@catarina.usc.edu Fri Oct 9 17:02:39 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id RAA06762 for ; Fri, 9 Oct 1998 17:02:38 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA11311 for malloc-list; Fri, 9 Oct 1998 13:24:06 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA11306 for ; Fri, 9 Oct 1998 13:24:01 -0700 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA18281; Fri, 9 Oct 1998 13:23:30 -0700 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id QAA09268; Fri, 9 Oct 1998 16:23:27 -0400 Received: from bcn.East.Sun.COM (bcn [129.148.75.4]) by suneast.East.Sun.COM (8.8.8+Sun/8.8.8) with SMTP id QAA08399; Fri, 9 Oct 1998 16:23:27 -0400 (EDT) Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id QAA16923; Fri, 9 Oct 1998 16:23:26 -0400 Message-Id: <199810092023.QAA16923@bcn.East.Sun.COM> Date: Fri, 9 Oct 1998 16:23:27 -0400 (EDT) From: Steve Hanna Reply-To: Steve Hanna Subject: Re: Language support for scope enumeration To: thalerd@eecs.umich.edu Cc: malloc@catarina.usc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: gfDrPGx/k9TWyREpY7SSfQ== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-malloc@catarina.usc.edu Precedence: bulk > > Do we want to *require* a language tag for each scope name? > > In the discussion between Pavlin, Mark, and I, one of them > stated that sometimes you cannot render a name unless you know > the language, and hence requiring a language tag may be > required. Since we are using Unicode, I expect that this situation would arise rarely. Does anyone have a specific example? > > It might be hard to force the user to enter one. > > It would require the abstract API caller to have one. If it can't make > the user enter one, then it would need to choose one itself somehow. I don't think the abstract API is involved here. The question is: can we force the person configuring scope names to enter a language tag? > > > * Each scope may have at most one name per language > > > (multiples signal a config error). > > > > It might be useful to have more than one name per language. For instance, a > > scope might be named "Company-wide", "IBM", and "International Business > > Machines" (all with the language tag "en"). > > This is a tradeoff. We decided that we preferred the greater > ability to diagnose misconfigurations which you gained by > forcing only one name. However, this is something which > people can provide input on. > > You have to understand that if you allow multiples, then > you can't detect collisions (one router says it's the "IBM" scope > and another says it's the "Sun" scope). It also complicates the > abstract API, since a client wanting to enumerate scopes in > a particular language wouldn't get one name per scope. > > I still prefer one name per scope (for the above reasons). > More comments on this topic would be appreciated. I'm not sure that it's desirable for a client that requests a scope list in a given language to always get one name per scope. In addition to the example I presented above, here's another one. Assume you have a scope with two names: ("en-US", "Harbor") and ("en-UK", "Harbour"). If the client requests names with the language tag "en", which one do you return? If you say "the default," what if the default has language tag "fr"? What if the scope has one name: ("en", "Harbor") and the client requested "en-UK"? If you say "the default," what if the default has language tag "fr"? Overall, I think it is best to provide a simple algorithm for the MAAS to use and a way for the client to get a complete list if it wants to do something fancy. If this complicates the API a bit, I don't mind. It can be a separate entrypoint if you like. > > > * MZAP message may also label a specific (language tag, scope name) > > > pair as the "default name" to display if none matches your > > > desired language. Since you have the actual language tag, > > > you can tell how to render the default name. > > > > I assume this would also apply if you don't know which language (or languages) > > the user wants. > > No, the main case targetted is one where you know which language > the user wants (e.g. "Klingon"), but there's no scope name in that > language. So the MAAS passes back the default name in the enumerate > scopes api. There are cases where you don't know which language the user wants (they haven't set their locale, etc.). BTW, how do you plan to indicate which name is the default name? > > What if the user can speak two languages? Do you pass in two languages (like > > "en, fr")? And what if none of the language tags match exactly (user > > specifies > > "en", only choice is "en-US")? And what if you have many users who speak many > > different languages? > > Typically people configure their machine with a specific language > (in today's OS's). If you wanted to write a tool which is tailored > for bilingual people, then I would expect that this tool would use > the abstract API by calling enumerate scopes twice, once for each > language, and then combining the results it gets. Some OS's are multiuser. For these OS's, it might be most efficient to fetch all the scope names and match them to the user preferences at the OS level. Also, some OS's may have more sophisticated language matching features than we would want to require in MAAS's. Again, I think it would be best to have a way to get all the names for a scope from an MAAS. > > I'm somewhat reluctant to make the MAAS responsible for deciding which > > names to return. > > Agree. The proposal was that the client specify the language > in the enumerate scopes request. But the MAAS must do some comparison between the language requested and the languages available. At the least, it must do a case-insensitive comparison. But this doesn't handle the case where the user specifies "en" and the only choices are "en-US" and "fr" (the default). Either the MAAS has to do something fancy or the user will never see the "en-US" name. If the client could request all names, it could have some fancy language tag matching code. The API and client-MAAS protocol shouldn't get in our way and make the client play a guessing game. Nor should they require that the MAAS include fancy language tag matching code. There should be a simple, reasonable default and a simple workaround to fetch all names for a scope. -Steve P.S. I think this is a fine feature. However, the devil is in the details. From owner-malloc@catarina.usc.edu Fri Oct 9 17:21:55 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id RAA06999 for ; Fri, 9 Oct 1998 17:21:54 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA11491 for malloc-list; Fri, 9 Oct 1998 13:41:11 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA11487 for ; Fri, 9 Oct 1998 13:41:07 -0700 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA22506 for ; Fri, 9 Oct 1998 13:40:36 -0700 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id QAA11281; Fri, 9 Oct 1998 16:40:32 -0400 Received: from bcn.East.Sun.COM (bcn [129.148.75.4]) by suneast.East.Sun.COM (8.8.8+Sun/8.8.8) with SMTP id QAA08957 for ; Fri, 9 Oct 1998 16:40:33 -0400 (EDT) Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id QAA16983; Fri, 9 Oct 1998 16:40:31 -0400 Message-Id: <199810092040.QAA16983@bcn.East.Sun.COM> Date: Fri, 9 Oct 1998 16:40:32 -0400 (EDT) From: Steve Hanna Reply-To: Steve Hanna Subject: Re: Language support for scope enumeration To: malloc@catarina.usc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: sCvWKFbT9wPqC9bWFFdzfg== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-malloc@catarina.usc.edu Precedence: bulk > >> > Do we want to *require* a language tag for each scope name? > >> > >> In the discussion between Pavlin, Mark, and I, one of them > >> stated that sometimes you cannot render a name unless you know > >> the language, and hence requiring a language tag may be > >> required. > > > >Since we are using Unicode, I expect that this situation would arise rarely. > >Does anyone have a specific example? > > My recollection is that this is an issue with some far eastern > languages. I'm not an expert on this, but I heard that although > Chinese and Japanese share Kanji and the unicode for them, you can't > decide how to render them correctly unless you know which language > it's in. Then you would need to have a language tag for scope names that include those characters. > I guess another example would be if you wanted to put the name through > a text-to-speech system such as the one Jeremy Hall uses. Different > languages that are all using the same western european characters > pronounce those characters differently. You need to know which > language it is to even get close to the correct pronunication (let > alone accents :-). Then his system wouldn't work very well if there wasn't a language tag. I definitely would like all scope names to have a language tag. I'm just concerned that administrators may not do this or may not do it properly. If nobody else is concerned about this, I won't worry about it. However, we should be prepared to deal with systems that send malformed language tags (zero length, invalid characters, etc.). This is just another example of misconfiguration, I guess. -Steve From owner-malloc@catarina.usc.edu Fri Oct 9 18:33:04 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id SAA07693 for ; Fri, 9 Oct 1998 18:33:04 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id PAA11886 for malloc-list; Fri, 9 Oct 1998 15:03:28 -0700 Received: from usc.edu (usc.edu [128.125.253.136]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id PAA11882 for ; Fri, 9 Oct 1998 15:03:22 -0700 Received: from dip.eecs.umich.edu (thalerd@dip.eecs.umich.edu [141.212.99.5]) by usc.edu (8.8.8/8.8.8/usc) with ESMTP id PAA06459 for ; Fri, 9 Oct 1998 15:03:21 -0700 (PDT) Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.9.1/8.9.0) id SAA15852; Fri, 9 Oct 1998 18:02:01 -0400 (EDT) From: Dave Thaler Message-Id: <199810092202.SAA15852@dip.eecs.umich.edu> Subject: Re: Language support for scope enumeration To: shanna@bcn.East.Sun.COM, malloc@catarina.usc.edu Date: Fri, 9 Oct 1998 18:02:00 -0400 (EDT) Cc: dthaler@dthaler.microsoft.com In-Reply-To: <199810092023.QAA16923@bcn.East.Sun.COM> from "Steve Hanna" at Oct 9, 98 04:23:27 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk > Assume you have a scope with two names: > ("en-US", "Harbor") and ("en-UK", "Harbour"). If the client requests names > with > the language tag "en", which one do you return? If you say "the default," > what if the default has language tag "fr"? > > What if the scope has one name: ("en", "Harbor") and the client requested > "en-UK"? If you say "the default," what if the default has language tag "fr"? I'm sure (from your previous comments) you might classify the following as "fancy language tag matching code". In my opinion, however, it's simpler and more powerful in terms of misconfiguration detection ability to specify two rules for MAAS's: A request for "foo-bar" matches "foo" if "foo-bar" does not exist. A request for "foo" may match any "foo-bar" (pick one arbitrarily) I'm not adamant about the above, but it appears to me to provide the best advantage-to-disadvantage tradeoff. > BTW, how do you plan to indicate which name is the default name? In MZAP messages? A bit per name is my strawman. > Again, I think it would be best to have a way > to get all the names for a scope from an MAAS. I would have no objection to adding another entry point to the abstract api, as you suggested, if that's what the WG consensus is. -Dave From owner-malloc@catarina.usc.edu Thu Oct 22 16:49:52 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id QAA04717 for ; Thu, 22 Oct 1998 16:49:51 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA04349 for malloc-list; Thu, 22 Oct 1998 13:08:26 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA04345 for ; Thu, 22 Oct 1998 13:08:21 -0700 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA00358; Thu, 22 Oct 1998 13:07:47 -0700 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id QAA21510; Thu, 22 Oct 1998 16:07:41 -0400 Received: from bcn.East.Sun.COM (bcn [129.148.75.4]) by suneast.East.Sun.COM (8.8.8+Sun/8.8.8) with SMTP id QAA12140; Thu, 22 Oct 1998 16:07:42 -0400 (EDT) Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id QAA15057; Thu, 22 Oct 1998 16:07:41 -0400 Message-Id: <199810222007.QAA15057@bcn.East.Sun.COM> Date: Thu, 22 Oct 1998 16:07:41 -0400 (EDT) From: Steve Hanna Reply-To: Steve Hanna Subject: Re: Language support for scope enumeration To: thalerd@eecs.umich.edu Cc: malloc@catarina.usc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=US-ASCII Content-MD5: nO9m83mpWgZX4xpn6RHAyA== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id QAA04717 I apologize for taking so long to continue this discussion. > > Assume you have a scope with two names: > > ("en-US", "Harbor") and ("en-UK", "Harbour"). If the client requests names > > with > > the language tag "en", which one do you return? If you say "the default," > > what if the default has language tag "fr"? > > > > What if the scope has one name: ("en", "Harbor") and the client requested > > "en-UK"? If you say "the default," what if the default has language tag "fr"? > > I'm sure (from your previous comments) you might classify the following > as "fancy language tag matching code". In my opinion, however, > it's simpler and more powerful in terms of misconfiguration detection > ability to specify two rules for MAAS's: > A request for "foo-bar" matches "foo" if "foo-bar" does not exist. > A request for "foo" may match any "foo-bar" (pick one arbitrarily) > I'm not adamant about the above, but it appears to me to provide the > best advantage-to-disadvantage tradeoff. RFC 1766 section 2.1 says: Applications should always treat language tags as a single token; the division into main tag and subtags is an administrative mechanism, not a navigation aid. I suggest that we provide two options: fetching all names for a zone or fetching a single name for each zone. In the latter case, the client would provide a language tag string. The MAAS would match this against all names for a given zone using a simple case-insensitive ASCII string comparison. The first one that matches would be returned. If none match, the default would be returned. This should provide a simple solution for the common case, while allowing clients with special needs to handle them. Are there any objections? -Steve From owner-malloc@catarina.usc.edu Sat Oct 31 16:14:42 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id QAA13128 for ; Sat, 31 Oct 1998 16:14:41 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA14074 for malloc-list; Sat, 31 Oct 1998 12:43:51 -0800 Received: from revnet4.revnet.com (revnet4.revnet.com [198.51.35.125]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA14070; Sat, 31 Oct 1998 12:43:45 -0800 From: scj2@gs4.revnet.com Received: from gs4.revnet.com (gs4.revnet.com [198.51.35.84]) by revnet4.revnet.com (8.8.7/8.8.7) with SMTP id OAA31179; Sat, 31 Oct 1998 14:42:43 -0600 Message-Id: <199810312042.OAA31179@revnet4.revnet.com> To: scj2@gs4.revnet.com Subject: ISM Corp has acquired 4.7 mill to begin production Stock up 100 percent Date: Sat, 31 Oct 1998 14:47:10 -0600 Originator: scj2@gs4.revnet.com X-Mailer: GroupMaster X-Mailer-Version: 1.5 X-GroupMasterUser: Revnet Express Sender: owner-malloc@catarina.usc.edu Precedence: bulk Please open the following message in your web browser http://gs4.revnet.com/GM/MSGVIEW/MSOHNOPA.HTML ____________________________________________________________ International Shoe Manufacturing Corp Update: International Shoe Manufacturing Corp. (Ticker-ISHO) has acquired the final-stage financing to begin full-scale production at its plants in India. The $4.75 million is being used to purchase the final equipment needed to begin production at the company’s existing plant in India. With equipment in place, the company projects net profits of over $25 million a year within two years. The company stated that the financing will be followed up by a $9 million dollar IPO in India, anticipated for March 1999. The IPO will be handled by underwriters in India, and will leave ISM with control of its wholly owned subsidiary in India. The proceeds of the IPO will pay off the $4.75 million dollar financing. The balance will be used for the acquisition of additional shoe manufacturing. ISHO is in the business of manufacturing athletic footwear for the world’s leading shoe companies. It owns a 23,000-square-foot plant located in the protected “free trade zone” in Noida, just outside of New Delhi, India, where skilled labor is plentiful and very inexpensive. The Indian government recently developed new economic policy to attract foreign investment that is export-oriented, and could employ large numbers of people. ISM is the only athletic shoe manufacturer in India directed toward the international market. It currently has contracts with Adidas and The Pentland Group. These two companies have agreed to purchase all the shoes ISM can manufacture. The athletic shoe industry is estimated at $14.25 billion a year. The world’s leading shoe companies such as Adidas, Nike, and Reebok do not manufacture shoes. They are design and marketing organizations that spend hundreds of millions of dollars a year getting their products sold. They then rely on others to manufacture to their specifications. Almost, if not all athletic shoe manufacturers are privately owned, benefiting from the hundreds of millions of dollars spent on advertising by the name-brand companies. The result is an open purchase order where such manufacturers literally can sell every pair of shoes they can produce. A business like this lends itself to being privately held due to the large cash flow allowing for internal financing. International Shoe Manufacturing Corp. is the only company known to exist that offers a public investor the opportunity to own a share of this highly lucrative business in a pure investment play. For inquiries please contact the office of the director of investor relations toll free at: 877-ISM-CORP (877-476-2677) or send your e-mail request to nsi@smallcapjournal.com Your request will be handled immediately. Or write to ISM Corp at P.O. Box 520310 Longwood, Florida 32752 Please visit ISM’s web site at www.ismcorp.net Safe Harbor for Forward-Looking Statements: Except for historical information contained herein, the statements in this press release are forward-looking statements that are made pursuant to the safe harbor provisions of the Private Securities Reform Act of 1995. Forward-looking statements involve known and unknown risks and uncertainties which may cause the company’s actual results in the future periods to differ materially from forecasted results. These risks and uncertainties include, among other things, product price volatility, product demand, market competition, risk inherent in the company’s domestic and international operations, imprecision in estimating product reserves and the company’s ability to replace and expand its holdings. ____________________________________________________________ Unsubscribe or access your membership settings at: http://gs4.revnet.com/GMG/ctrlpanel/0/79