Subject: [Ltru] Filtering coverture pending topics

From: Jefsey Morfin <[email-masked]>
Date: Wed, 09 Nov 2005 03:47:37 +0100

Dear Scott,
full agreement: it would be good if we could concentrate on WG-ltru topics.
This is a short list of basic concerns I have expressed concerning 
the filtering issues.

The reason why a langtag is not the expected one and may call for filtering:
- user does not know the language
- the machine does not support the language - the locale must adapt,
   - the construct of the locale is then of importance (not the same 
constraints/possibility as a user)
   - study of LDML might help?
   the Charter relation RFC 3066 bis/CLDR applies:
   - what is special about it?
   - why does it prevent other solutions (RFC 4151, ISO 11179, open 
to other SSDOs)
   - we do not know the IPRs of CLDR/LDML. We need to be sure it will 
be a stable proposition before committing to it.
- there is a concept error in RFC 3066 bis:
   - it lead to another langtag - for example RFC 4151 conformant
   - the used langtag has been refused by the IANA advisers.
- there is a new metastructural issue, due to a lingual TLD.

These points must be addressed either specifically (my proposition) 
or in security or usage considerations (probable fall back of the 
author from my acquired experience).
jfc

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Martin Duerst <[email-masked]>
Date: Fri, 11 Nov 2005 18:29:03 +0900

[co-chair hat on]

Due to Randy's mail at
http://www1.ietf.org/mail-archive/web/ltru/current/msg04032.html,
we may not hear from Jefsey again for a while. However,
to make progress on the matching draft, we have to deal
with the following mail and reach some consensus on it.

[co-chair hat off]

I think that while some of the points mentioned below are
related to filtering, none of them is affecting the
matching draft. I'll explain, point for point, but
shortly, why I think so.

At 11:47 05/11/09, Jefsey Morfin wrote:
 >This is a short list of basic concerns I have expressed concerning the 
filtering issues.
 >- user does not know the language

Yes, things like language-range can be used that way.
This is working in practice, no need to change/add anything.

 >- the machine does not support the language - the locale must adapt,

This is also an usage that is easily possible with the current
matching draft.

Construction of locales is not a topic of this WG.

 >   - study of LDML might help?

Again, locale description is not a topic of this WG.

 >   - what is special about it?

Nothing, in my view. CLDR isn't mentioned in the context
of the WG deliverable, it is mentioned in the context of
the current (soon past, I guess) RFC 3066. See
http://www.ietf.org/html.charters/ltru-charter.html.

 >   - why does it prevent other solutions (RFC 4151, ISO 11179, open to 
other SSDOs)

Nothing in the drafts of this WG does prevent somebody
else to use some other tagging system for identifying
languages in the protocols and formats that they design.
The main problem with them will be interoperability
with the well-establised RFC 1766/3066/3066bis system,
but that's up to them to decide.

 >   - we do not know the IPRs of CLDR/LDML. We need to be sure it will be 
a stable proposition before committing to it.

This WG is in no way commiting to CLDR/LDML. This is
therefore irrelevant.

 >   - it lead to another langtag - for example RFC 4151 conformant

It is a property of all standards that they in some
way limit what's possible in order to make the possible
probable and easy to use. This is in general not a
concept error.

 >   - the used langtag has been refused by the IANA advisers.

This is unrelated to filtering/matching, it is a registration
issue.

 >- there is a new metastructural issue, due to a lingual TLD.

I'm not sure how this is related to matching. I guess that
in some applications, it might be possible to try to include
or exclude some documents based on the assumption that data
served from some domains is in some languages. But that
assumption will always be very fragile, and is out of the
scope of our matching draft.

 >These points must be addressed either specifically (my proposition) or in 
security or usage considerations (probable fall back of the author from my 
acquired experience).

If these points had indeed been addressed specifically (in
particular, by proposing specific text for the matching
draft), that would have been helpful. Also, if the security-
related points above were so marked, that too would have
been helpful (I have to admit that I didn't find any
point that would be relevant to security in the context
of our matching draft). Given that these points haven't
happened, and based on my technical evaluation above,
I propose to close the above issues without any
changes to the document.

Regards,    Martin.

---

From: Mark Davis <[email-masked]>
Date: Fri, 11 Nov 2005 08:33:55 -0800

>  Given that these points haven't

Agreed.