RE: Please make sure that you do not run your WLAN in ad hoc mode
At 11:44 -0500 11/11/05, Nelson, David wrote: Phillip Hallam-Baker writes... I think that what we should do is to send the IEEE 801.b/g group a polite letter pointing out that if our people here at the IETF cannot figure this stuff out then their less technically astute customers might be having some trouble as well. I don't believe this is an 802.11 problem. That group standardizes PHY and MAC (up to Layer 2) protocols. The usability problems with 802.11 networks are in the device drivers, operating systems and configuration applications. It would be more effective to send mail to Microsoft, Apple, et. al. I disagree, I think. IETF, MPEG, large corporate conferences and so on, they all have trouble running large 802.11 networks. They all can run large wired networks. The difference is that even at meetings run by and attended by supposed network experts, it's hard hard hard to get an 802.11 network to run well. That is not right. I do believe that there are (were) some operating systems that switched to ad-hoc mode and made a network if it couldn't find the network you asked to join. (I don't think it was OS X.) That's a mistake. A big big mistake. Guidelines on (a) network naming and (b) frequency selection from the 802.11 group would be useful. For example, maybe you need to do something to claim to be an 'expert' to create an ad-hoc with a 'plain' name; otherwise your ad-hoc network would be (for example) prefixed by * or something. And maybe OS's could diagnose frequency problems (there are several base stations in here all on channel XX and they are interfering with each other or whatever). Dammit, a FAQ on http://grouper.ieee.org/groups would be a good start. I've been at a meeting where a respected network equipment provider provided the network. Because the base stations had an artificial limit of 10 IP addresses for their NAT/DHCP, he setup 3 of them in the room, next to each other, on the same channel and SSID. Result -- they are all in very low-power mode, interfering like hell, and the users if they get a signal can't choose from which box and so it doesn't actually spread the load. Finally, it's clear that at least some base stations get hopelessly confused (sometimes I have even resorted to the technical term wedged) when there is an ad-hoc in range with the same SSID. Some testing and robustness guidelines from the 802.11 group would also help. -- David Singer Apple Computer/QuickTime ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Fwd: Can the USA welcome IETF (was: Last Call under RFC 3683 concerning Dean Anderson (reissued))
Eduardo, I think I may be misunderstanding you, and if so I apologize. As I understand it, the original announcement of the 'last call' was not sent in strict accord with the agreed procedures, in that it used the wrong mailing list. As a result it has now been sent to the correct mailing list. There was then a question should the deadline -- the end of the call -- be as originally announced, or should it be extended? It seems, I think, that it is only fair that it be extended, in case there were people who did not see the first announcement. This gives all parties at least the required time to discover the last call, read, and respond if they wish. I think you are arguing that the original deadline should have been maintained, that it was in fact unfair to extend it, but I am not sure I understand why you feel this. If this is how you feel, could you explain? And if I am wrong, could you correct me? Many thanks, -- David Singer Apple Computer/QuickTime ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: delegating (portions of) ietf list disciplinary process (fwd)
At 20:04 -0400 28/09/05, Dean Anderson wrote: This was offlist, but I think it is relevant, now to similar questions raised by others. My apologies to the list. I emailed Dean off-list, and was not asked for, and hence did not give, permission to reproduce my email on-list. I'm sorry if the result is more traffic on this list. -- David Singer Apple Computer/QuickTime ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group and charter problems
At 0:30 +0200 7/09/05, Iljitsch van Beijnum wrote: On 7-sep-2005, at 0:16, Daniel Senie wrote: Actually, a Firewall Considerations section would make sense. What would be in such a section? There are only three possibilities: 1. There is no firewall: no need for text. 2. There is a firewall, and it doesn't try to block the protocol: no need for text. 3. There is a firewall, and it tries to block the protocol. So what text would be helpful in case #3? Either the firewall successfully blocks the protocol and the firewall works and the protocol doesn't, or the firewall doesn't manage to block the protocol and the protocol works but the firewall doesn't. So whatever happens, someone is going to be unhappy. It could at least discuss the question is the protocol designed in such a way that firewall management is reasonably enabled? . Two obvious counter-examples come to mind: non-passive-mode FTP, and the use of RTSP with RTP (and having to enable traversal for the RTP/RTCP ports). Then it could discuss whether this protocol can be individually isolated and decisions on firewall handling be made in isolation for it, or whether it is effectively bundled with other protocols which will have to be handled together, and whether that 'bundle' is in fact appropriate (e.g. if it layers on HTTP, is that appropriate?). There are probably other questions as well. -- David Singer Apple Computer/QuickTime ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
I'm a by-stander on this discussion, maybe off-base or out of it -- but something other than the undesirable traffic struck me. Isn't it also true that I might *deliberately break* all sorts of things by introducing 'blocking' names into DNS responses, so that an LLMNR request is never issued. So an ISP could 'grab' traffic that the users thought was local, by replying to a DNS request in a proxy (or converting a negative reply into an answer). Also, ISPs might be tempted to start turning around DNS requests in their proxies for names that they *think* should be answered by LLMNR, returning resolution failure, so as not to send too much traffic outbound. This pre-empts the real DNS from ever actually replying. The whole idea that 'real DNS' can arbitrarily pre-empt local name resolution seems, well, wrong, and needs serious study for security implications for the services using those names, no? -- David Singer Apple Computer/QuickTime ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Why have we gotten away from running code?
I hear the opposite complaint enough to believe that the truth lies somewhere in between (the ietf is dominated by academics who have no idea what it takes to design, deploy, and maintain large complex networks). I only see a tiny portion of the ietf myself, agreed (I doubt many people see much more as it is so large), but I don't see reason to be excessively pejorative about the attendance I see. It's mixed; academics, industrial engineers, writers, thinkers, implementers, observers, dilettantes, all mixed in. Just like other standards orgs. At 18:36 +0200 10/08/05, Simon Josefsson wrote: I think that is a good point. A variation on that theme is that the IETF is no longer run by people who actually implement protocols. The relevance and impact of the IETF on what is actually used on the Internet is marginalized through that change of membership. The attitude of That is not how we do things in the IETF make people go away. Cheers, Simon C Wegrzyn [EMAIL PROTECTED] writes: I think a big part of the issue is that the IETF has been taken over little by little by corporate interests. Before it used to be for the love of doing it. Today it is more for the benefit of one. -- David Singer Apple Computer/QuickTime ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Why have we gotten away from running code?
Don't forget the organizations that adopt IETF specs. ISMA has a regular interop and conformance program for RTSP + RTP + the codecs used, both 'virtual' over the internet and face to face at most meetings. Likewise IMTC does testing of 3GPP SA4 multimedia specs, again using RTSP, RTP, codecs etc. I'm sure there are more. Not that I am opposed to running code, sample code, or more IETF bake-offs, mind you. Just that the number of organizations filling the glass is more than it used to be. At 15:12 -0400 10/08/05, C Wegrzyn wrote: Perhaps they are more regionalized. I know there are some labs like at the UNH that hold them but the attendance isn't nearly as universal as they once were. As for statistics, no I don't have any. But I bet there aren't any more -- in fact -- I would bet there are a lot less. I can't remember the last SIP bake-off... Chuck Jari Arkko wrote: C Wegrzyn wrote: Hey, we not only had code that ran we also had bake-offs to make sure all the stuff worked together. The idea was to work out the nuances (the 20% of the inaccuracies) and produce a damn good system. Today the idea is to slap something together - damn the interop - and get out the door for the first mover advantage. We also tend to not worry about the experience of the user - we expect them to understand our Gold is more like fool's gold than a well thought out and tested system. We still have bakeoffs. Or do you have some statistics that show we have now less bakeoffs per RFC than we used to, or that the bakeoffs are later than they used to be? (We here is the internet community, the IETF doesn't hold bakeoffs.) --Jari -- David Singer Apple Computer/QuickTime ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Cautionary tale: Paris pickpockets
At 12:55 -0700 10/08/05, Dave Crocker wrote: he said I'd be crazy to have my wallet in the backpocket and urged me to put it somewhere inside my jacket because that would be much more difficult to get. when my wallet was lifted, 2 months ago in the Paris metro, it was in my front left pocket. much more difficult is simply not correct. I travel a lot. In cities where worry is appropriate (Paris, Rome and quite a few others), I chain the wallet to the bottom of the pocket. Go to local hardware store, get two feet of 'sink plug' chain (the stuff that look like balls joined together), and an eyelet for each end, and a small key-ring clip, and a safety pin. Attach eyelet + safety pin to bottom of pocket, eyelet + clip to wallet. The chain is heavy and flexible enough that it naturally snakes into the pocket, and the whole solution costs maybe $5. Yes, it's easy to cut, but most pickpockets don't have time for scissors or cutters or hassle. -- David Singer Apple Computer/QuickTime ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: reflections from the trenches of ietf62 wireless
At 11:12 AM -0500 3/16/05, Marshall Eubanks wrote: how much would it cost us to have our own equipment? Shouldn't the question of _which_ equipment to buy come first ? That will pretty much determine the price. I know that the volunteer teams have some strong opinions on this, as I have heard their venting. Paris is hosted (including the WLAN), so there is at least 6 months until it is needed (is Nortel providing the Vancouver WLAN?). Regards Marshall Eubanks There is also the minor question of how often one would want to replace/upgrade it. (But I do agree, some makes of 802.11 equipment seem much more susceptible to less-than-perfect conditions than others). -- David Singer Apple Computer/QuickTime ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: idea for spam protection
At 9:22 AM -0500 3/13/05, Bruce Lilly wrote: Date: 2005-03-12 11:18 From: Bill Sommerfeld [EMAIL PROTECTED] where's that Final Ultimate Solution to the Spam Problem scorecard? You're probably thinking of http://www.rhyolite.com/anti-spam/you-might-be.html great list. but just because there is no final ultimate technical solution, doesn't mean that (a) governmental/legal solutions are viable or (b) that nothing can be done to ameliorate the situation. the list conspicuously doesn't mention understanding the spam industry and particularly its money-flow. this is kinda like trying to eradicate a disease without really understanding its biology or food-sources; you might succeed, but it's probably more luck than science. we 'merely' have to tip the tables so that spam is mostly unprofitable, after all (presuming that spammers are not in it for altruism). -- David Singer Apple Computer/QuickTime ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IEEE 802.11 and large meetings
Forgive me, I wasn't at the meeting, but I suspect that you had the usual slew of problems with 802.11 networks at large meetings, such as: a) Users confusing other users by going into ad-hoc mode with the same network name; b) some base stations seem to get royally confused when this happens, which is worse (and I suspect but do not know that this can cause the base stations to drop their transmit power) c) radio-level problems caused by 802.11 devices using the same radio channels but not co-operating. I even recently was at a meeting where the IS had setup 3 base stations on the same network and frequency, within feet of each other, because each had a 10-user NAT limit. Asking for radio interference (and it didn't solve the problem, since users cannot then choose which base station they get!). d) aggressive bluetooth devices making it difficult to get large packets through ... Why do I bring this up? Because at IETF and MPEG meetings, large company developer conferences, and so on, I observe it takes a significant team of people just managing the wireless network. Is it time for those who have experience at the sharp end to pool the collected wisdom and talk to the 802.11 committee about this? I think that otherwise these problems will (and probably are) damping the adoption and use of this, and hence IP-based services, and that it's time to consider changes to the spec. -- or at least recommendations -- to ameliorate some of these problems. As to why some OSs switch automatically into ad-hoc mode if they cannot find the base station, I will remain silent... -- David Singer Apple Computer/QuickTime ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: MARID back from the grave?
At 10:14 PM -0500 2/26/05, Keith Moore wrote: Thanks. I forgot to say on (c) that there MUST be as many entries in the revision history as the revision number indicates (i.e. none for revision 00, and so on). don't do that. it will add an unnecessary and often useless barrier to publication of I-Ds I-Ds are supposed to be a quick-and-dirty mechanism for circulating (sometimes quite rough) drafts among interested parties. we don't need to impose a complicated revision history mechanism just because we have two different cutoff dates for I-Ds. and there's certainly no need to impose such a requirement on drafts that (a) aren't WG work items and (b) are submitted before the earlier cutoff date. Keith I think I overstated what I was looking for. I often see requests like I saw -03, this is -05, what as -04 and what has changed? on the mailing lists. I was just thinking that a section like this would help (names are just examples) Change history: draft-ietf-dxs-odorimeter-0525-jun-2007 removed indirect virtual mode as no-one understood it draft-ietf-dxs-odorimeter-043-may-2007 spelling fixes, changed draft name draft-ietf-dxs-sense-032-may-2007 accepted by the DXS WG draft-mordred-sense-021-apr-2007fixed boilerplate material including copyright draft-mordred-sense-012-feb-2007merged in draft-morgan-sniffer-04 as the two were sim. draft-mordred-sense-008-jan-2007initial version Doesn't seem like this would be hard to make; it could be 'expected but not required'... -- David Singer Apple Computer/QuickTime ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: MARID back from the grave?
At 10:34 PM +0100 3/1/05, Brian E Carpenter wrote: Harald Tveit Alvestrand wrote: --On lørdag, februar 26, 2005 21:22:36 -0800 Christian Huitema [EMAIL PROTECTED] wrote: In fact, we only have two points of contentions: old personal drafts submitted as version 00 of WG drafts; and old WG drafts submitted as version 00 of new personal drafts. now that we know that the secretariat keeps track of drafts that claim to obsolete another draft, we could make this Real Simple: drafts that say they obsolete another draft get the later deadline. Harald (who won't have to decide that) That would only work if it was said in metadata that can be automatically verified. Brian Isn't that the point of a non-00 version number, and that can be verified by looking inside the document at the change log I suggested which tells you the previous I-Ds, and their existence can be independently verified. And for the truly paranoid, one could do an exhaustive search of all ID-s to assure that only one I-D is claiming descent from any given ancestor. (Under what I suggested, -00 is only used for new, fresh, drafts, and changes of name DO NOT reset the version number to 00.) -- David Singer Apple Computer/QuickTime ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: MARID back from the grave?
At 7:14 PM -0800 2/25/05, Dave Crocker wrote:
On Fri, 25 Feb 2005 09:59:19 +, Dave Singer wrote:
Ý a) renaming of the root portion of the file-name is permitted, nay
Ý encouraged, to identify whether the draft is currently individual, or
Ý owned by a group (or even to select a 'better' name for other
Ý reasons);
Ý b) the revision number is NOT reset when the name is otherwise changed;
Ý c) all drafts must include a revision history including the full name
Ý under which each draft was presented.
this is in line with some other postings, and I
think it is quite a good summary. retaining
version history is a nice touch.
Thanks. I forgot to say on (c) that there MUST
be as many entries in the revision history as the
revision number indicates (i.e. none for revision
00, and so on). Perhaps a standard format of the
revision history would help? Clearly file name,
submision date, summary of the nature of what's
new in this version...
in terms of naming, I think syntactically it reduces to:
I-D-Name = draft- owner - category = title - version
owner = author-name / ietf
; who retains change control
author-name= { last name of first author }
category = working-group / topic
working-group = { IETF working group }
topic = { term under which I-D topic fits}
title = { text specific to this I-D, to describe it }
* Version 0 must be submitted some extra amount
of time before an IETF meeting.
* Use of the working group name is authorized
by the working group chair and represents an
explicit hand-off of change-control for the
document, to the IETF.
* If a working group goes defunct, prior to RFC
publication of the I-D, ownership reverts to
the authors.
d/
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker Ýa t ...
WE'VE MOVED to: Ýwww.bbiw.net
--
David Singer
Apple Computer/QuickTime
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: MARID back from the grave?
Um, I'm maybe an innocent bystander here, but perhaps the following works? a) renaming of the root portion of the file-name is permitted, nay encouraged, to identify whether the draft is currently individual, or owned by a group (or even to select a 'better' name for other reasons); b) the revision number is NOT reset when the name is otherwise changed; c) all drafts must include a revision history including the full name under which each draft was presented. This makes clear the current status, the prior status, whether the draft is new (-00) or not, and enables the other obvious rules. IETF secretariat and others can clearly see when a draft is new or not, and everyone can (we hope) see who 'owns' the draft and its rough subject from the file name. -- David Singer Apple Computer/QuickTime ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-phillips-langtags-08, process, sp ecifications, stability, and extensions
This is similar to the reason why the language code comes before the country
code. If we had the order CH-fr, then we could end up mixing French and
German in the same page, because we would fall back (for one of the data
sources) from CH-fr to CH, which could be German.
It has to be application-specific which fallback happens. If the
user says he's swiss french, and the the content has alternative
offers for swiss german or french french, which do you present? If
the content actually differs for legal or geographic reasons ('the
legal representative in your country is', 'for copyright reasons this
edition differs in material ways from other countries'), then the
correct country but wrong language is the best answer. If the desire
is simply for maximum intelligibility, then the reverse is true.
--
David Singer
Apple Computer/QuickTime
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-phillips-langtags-08, process, sp ecifications, stability, and extensions
At 11:34 AM -0800 1/6/05, Peter Constable wrote:
From: Dave Singer [mailto:[EMAIL PROTECTED]
This is similar to the reason why the language code comes before the
country
code. If we had the order CH-fr, then we could end up mixing French
and
German in the same page, because we would fall back (for one of the
data
sources) from CH-fr to CH, which could be German.
It has to be application-specific which fallback happens. If the
user says he's swiss french, and the the content has alternative
offers for swiss german or french french, which do you present? If
the content actually differs for legal or geographic reasons ('the
legal representative in your country is', 'for copyright reasons this
edition differs in material ways from other countries'), then the
correct country but wrong language is the best answer. If the desire
is simply for maximum intelligibility, then the reverse is true.
But that is a level of decision making that goes well beyond any
algorithm that simply uses truncation of tags, which is the only case in
which the ordering of sub-tags matters.
Sorry, I should have gone on to conclude: the important aspect of
sub-tags is that their nature and purpose be identifiable and
explained (e.g. that this is a country code), and that we retain
compatibility with previous specifications. This tagging uses order
(and size) of sub-tags rather than explicit labels to say what
something is, and we're stuck with that. I don't believe that simple
truncation is a necessarily useful operation in all circumstances,
and it probably should not be in the spec. at all. For example, I'd
say that we should retain the 3066 ordering of language-country and
therefore script, if needed, comes later. However, my typesetting
subsystem doesn't care a jot about language or country, it just needs
to find the script code ('can I render this script'?).
This spec. should unambiguously allow me to extract the language,
country, script etc., should say under what circumstances two
sub-tags of any type match, state the obvious that two tags exactly
match if they have the same sub-tags and they all match, that partial
perfect matches (of tags with differing numbers of sub-tags) are
possible and may be applicable, and that the use of imperfect matches
(in which not all sub-tags match) has to be application-specific.
Examples of why on the latter would be helpful.
--
David Singer
Apple Computer/QuickTime
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-phillips-langtags-08, process, sp ecifications, stability, and extensions
At 12:14 PM -0800 1/6/05, Peter Constable wrote:
From: Dave Singer [mailto:[EMAIL PROTECTED]
Sorry, I should have gone on to conclude: the important aspect of
sub-tags is that their nature and purpose be identifiable and
explained (e.g. that this is a country code), and that we retain
compatibility with previous specifications.
Ah! Then the proposed draft ensures that the nature of subtags are
always identifiable, which RFC 3066 (as I mentioned earlier) fails to
do.
And the draft retains compatibility with previous specifications using
an assumption (thoroughly discussed and concluded on the IETF-languages
list a year ago) that, in case of left-prefix matching processes, script
distinctions are generally far more important that country distinctions.
as has been beautifully pointed out on the list, that is a view that
is lingo-centric. If what I am trying to differentiate is the price
(and the currency of the price) of an item, the country may be much
more important than the script that the price is written in. (this
is also an example for the last point below). I repeat, I don't
think truncation -- and hence prefix-matching -- is very stable or
nearly universally applicable enough to be mentioned. Whereas I do
believe compatibility of ordering with 3066 is important.
I don't believe that simple
truncation is a necessarily useful operation in all circumstances,
I don't think anyone would dispute that.
and it probably should not be in the spec. at all. For example, I'd
say that we should retain the 3066 ordering of language-country and
therefore script, if needed, comes later. However, my typesetting
subsystem doesn't care a jot about language or country, it just needs
to find the script code ('can I render this script'?).
Here I disagree. For other purposes, I think it's very clear that the
only time that choice of order matters is with matching algorithms that
use simple truncation, and for the most common implementations, which
use left-prefix truncation, the order lang-script-country will be far
more useful in the long run precisely because script distinctions are
generally far more important in matching than country distinctions. I
don't know of any case in which a tag might be used that contained all
three subtags but in which the country distinction generally matters
more than the script distinction.
--
David Singer
Apple Computer/QuickTime
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-phillips-langtags-08, process, sp ecifications, stability, and extensions
I'm sorry, this example I gave doesn't correspond to *language*
matching. My error. My apologies.
(Nor should my questions on this subject be seen as suggesting either
that I as an individual, or particularly Apple as a company, is
unhappy revising RFC 3066.)
At 12:35 PM -0800 1/6/05, Dave Singer wrote:
At 12:14 PM -0800 1/6/05, Peter Constable wrote:
From: Dave Singer [mailto:[EMAIL PROTECTED]
Sorry, I should have gone on to conclude: the important aspect of
sub-tags is that their nature and purpose be identifiable and
explained (e.g. that this is a country code), and that we retain
compatibility with previous specifications.
Ah! Then the proposed draft ensures that the nature of subtags are
always identifiable, which RFC 3066 (as I mentioned earlier) fails to
do.
And the draft retains compatibility with previous specifications using
an assumption (thoroughly discussed and concluded on the IETF-languages
list a year ago) that, in case of left-prefix matching processes, script
distinctions are generally far more important that country distinctions.
as has been beautifully pointed out on the list, that is a view that
is lingo-centric. If what I am trying to differentiate is the price
(and the currency of the price) of an item, the country may be much
more important than the script that the price is written in. (this
is also an example for the last point below). I repeat, I don't
think truncation -- and hence prefix-matching -- is very stable or
nearly universally applicable enough to be mentioned. Whereas I do
believe compatibility of ordering with 3066 is important.
I don't believe that simple
truncation is a necessarily useful operation in all circumstances,
I don't think anyone would dispute that.
and it probably should not be in the spec. at all. For example, I'd
say that we should retain the 3066 ordering of language-country and
therefore script, if needed, comes later. However, my typesetting
subsystem doesn't care a jot about language or country, it just needs
to find the script code ('can I render this script'?).
Here I disagree. For other purposes, I think it's very clear that the
only time that choice of order matters is with matching algorithms that
use simple truncation, and for the most common implementations, which
use left-prefix truncation, the order lang-script-country will be far
more useful in the long run precisely because script distinctions are
generally far more important in matching than country distinctions. I
don't know of any case in which a tag might be used that contained all
three subtags but in which the country distinction generally matters
more than the script distinction.
--
David Singer
Apple Computer/QuickTime
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-phillips-langtags-08, process, sp ecifications, stability, and extensions
At 9:14 AM -0800 1/4/05, [EMAIL PROTECTED] wrote: This whole question of what 'matches' is subtle. Consider the case when I have a document that has variant content by language (e.g. different sound tracks), and the user indicates a set of preferred languages. If the content has de-CH and fr-CH (swiss german and french), and a default en (english) and the user says he speaks de-DE and fr-FR, on the face of it nothing matches, and I fall back to the catch-all default, which is almost certainly not the best result. David, this isn't the half of it. The case you describe is actually one of the easy ones, in that it can be handled by doing a preferred match on the entire tag, with a generic match on the primary tag only having lesser precedence but higher precedence than a fallback to a default. Yes, I picked off an easy example for which the 'matching' section of the draft didn't seem adequate. This really is a tar-pit, of course. Serbo-croatian used to be a language; now it's serbian and croatian. I assume that they are mutually intelligible. Serbian is probably a better substitute for croatian than some general default (or silence), though saying this in some parts of the world might start wars. The whole question of what is a language, a variant or dialect of a language, or a suitable substitute for a language, would benefit some thought in any tagging scheme, though I agree the problem is not generally soluble. I know of two other wrinkles in the RFC 1766 world: (1) Matching may want to take into account the distinguished nature of country subtags in some way. (2) SGN- requires special handling, in that SGN-FR and SGN-EN are in fact sufficiently different languages that a primary tag match should not be taken to be a generic match. (Of course this only matters if sign languages are relevant to your situation - in many cases they aren't. In retrospect I think it was a mistake to register sign languages this way.) This proposed revision, however, opens pandora's box in regards to matching. Consider: (a) Extension tags appear as the first subtags, and as such have to be taken into account when looking for country subtags. (b) Script tags change the complexion of the matching problem significantly, in that they can interact with external factors like charset information in odd ways. (c) UN country numbers have been added (IMO for no good reason), requiring handling similar to country codes. The bottom line is that while I know how to write reasonable code to do RFC 1766 matching (and have in fact done so for widely deployed software), I haven't a clue how to handle this new draft competently in regards to matching. And the immediate consequence of this is that I, and I suspect many other, implementors are going to adopt a wait and see attitude in regards to implementing any of this. Ned -- David Singer Apple Computer/QuickTime ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-phillips-langtags-08, process, sp ecifications, stability, and extensions
The *meaning* of any given language tag would be no more or less a problem under the proposed revision than it was for RFC 3066 or RFC 1766. For instance, there is a concurrent thread that has been discussing when country distinctions are appropriate or recommended (ca or ca-ES?); this discussion pertains to RFC 3066, and part of the issue is that meanings of tags are implied rather than specified -- and always have been even under RFC 1766 (I pointed this out five years ago when we were working on preparing RFC 3066). So, for instance, when an author uses de-CH, what does he intend recipients to understand to be the difference between that and de-DE or even de? Neither RFC 1766 or RFC 3066 shed any light on this, and ultimately only the author knows for sure. Under RFC 3066, it was the *exceptional* case that a complete tags was registered, allowing some indication of the meaning of the whole (though even in that regard nothing really required that the documentation provide clear indication of the meaning). The 98% cases were those like de-CH in which it was assumed that everyone would understand what the intended meaning is. This whole question of what 'matches' is subtle. Consider the case when I have a document that has variant content by language (e.g. different sound tracks), and the user indicates a set of preferred languages. If the content has de-CH and fr-CH (swiss german and french), and a default en (english) and the user says he speaks de-DE and fr-FR, on the face of it nothing matches, and I fall back to the catch-all default, which is almost certainly not the best result. -- David Singer Apple Computer/QuickTime ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
The Font top-level MIME type registration I-D
http://www.ietf.org/internet-drafts/draft-singer-font-mime-00.txt This was posted a while back and hasn't received much comment. I suspect that it is not so much the quality of the writing as the fact that many haven't noticed it... It proposes registering a top-level font/ MIME type for font formats. Note that it is font formats, just like image formats, that we propose registering; I understand that in the past there has been some confusion that it might be fonts themselves (e.g. font/courier) that would be registered. That would be like having image/mona-lisa or audio/beethoven5th, of course. Rather, we propose font/opentype (for example). This was modelled on another recent top-level MIME type definition. All comments are gratefully received, of course. Best of the season to you all. -- David Singer Apple Computer/QuickTime ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
