RE: IASA BCP -02 Designated Donations - section 5.3

2004-12-15 Thread Wijnen, Bert (Bert) 
Inline
Biran answered me:
> 
> Wijnen, Bert (Bert) wrote:
> > I am not a real accountant and kind of simple-minded.
> > 
> > So when you say:
> > 
> >>>"Lynn" == Lynn St Amour <[EMAIL PROTECTED]> writes:
> >>
> >>Lynn> over 80% of ISOC's org. members donate less than $10K
> >>Lynn> annually and managing these in a 'restricted accounting
> >>Lynn> manner' requires more effort and overhead.  Also,
> >>Lynn> organizations/donors expect recognition appropriate to their
> >>Lynn> contribution and that implies differing levels of value and
> >>Lynn> distinction.
> >>
> > 
> > I then wonder 
> > 
> > - if there is s separate or special bank account for IASA/ETF
> > - if I can just deposit my donation into that bank account
> > - What then is the "more effort and overhead" ??
> > 
> > I just do not understand.
> > 
> 
> Bert, I'm sure Lynn will answer this too, but from when the ISOC was
> discussing accounting practices for individual member subscriptions
> and donations, I remember that the bank account aspect is the least
> of the worries (and anyway, we already reached consensus not to
> have a separate bank account).

I am not even talking about "separate bank account" as we did in an 
early rev of the iasa-bcp doc. I am talking about an ISOC bank account
that will ONLY receive donations targeted for a specific purpose.
By depositing money on the specific bank account, you IMPLICITLY tell
ISOC that the money is intended for a specific purpose, in this case
IETF.  Again it must be the simple-minded me who does not understand.

Bert
> he issue is that accounting entries
> have to be made in a very specific way for money which is tied to
> a specific purpose, and while that is a small overhead if someone
> donates $100k, it becomes a significant overhead if 100 people
> donate $1k. It can end up eating money for accounting actions
> that really serve no useful purpose but have to be done to follow
> thr accounting rules. So I think Lynn is correct and we have to
> give ISOC the necessary flexibility.
> 
> Brian
> 

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: IASA BCP -02 Designated Donations - section 5.3

2004-12-15 Thread Brian E Carpenter 
Bert, that does not change the need for the ISOC accountants
to generate a separate entry for each case and for the auditors
to check each of those entries. It's a real cost, because
accountancy and auditing cost real money.
   Brian
Wijnen, Bert (Bert) wrote:
Inline
Biran answered me:
Wijnen, Bert (Bert) wrote:
I am not a real accountant and kind of simple-minded.
So when you say:

"Lynn" == Lynn St Amour <[EMAIL PROTECTED]> writes:
  Lynn> over 80% of ISOC's org. members donate less than $10K
  Lynn> annually and managing these in a 'restricted accounting
  Lynn> manner' requires more effort and overhead.  Also,
  Lynn> organizations/donors expect recognition appropriate to their
  Lynn> contribution and that implies differing levels of value and
  Lynn> distinction.
I then wonder 

- if there is s separate or special bank account for IASA/ETF
- if I can just deposit my donation into that bank account
- What then is the "more effort and overhead" ??
I just do not understand.
Bert, I'm sure Lynn will answer this too, but from when the ISOC was
discussing accounting practices for individual member subscriptions
and donations, I remember that the bank account aspect is the least
of the worries (and anyway, we already reached consensus not to
have a separate bank account).

I am not even talking about "separate bank account" as we did in an 
early rev of the iasa-bcp doc. I am talking about an ISOC bank account
that will ONLY receive donations targeted for a specific purpose.
By depositing money on the specific bank account, you IMPLICITLY tell
ISOC that the money is intended for a specific purpose, in this case
IETF.  Again it must be the simple-minded me who does not understand.

Bert
he issue is that accounting entries
have to be made in a very specific way for money which is tied to
a specific purpose, and while that is a small overhead if someone
donates $100k, it becomes a significant overhead if 100 people
donate $1k. It can end up eating money for accounting actions
that really serve no useful purpose but have to be done to follow
thr accounting rules. So I think Lynn is correct and we have to
give ISOC the necessary flexibility.
   Brian


___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

"connection latching" -- comments on rfc2401bis (draft-ietf-ipsec-rfc2401bis-04.txt)]

2004-12-15 Thread Nicolas Williams 
"Connection latching" is a simple concept: connections, for connection-
oriented protocols, such as TCP or SCTP, that are run over IPsec should
be 'bound' to the same quality of protection parameters and initiator
and responder IDs for their duration.

IOW, the SPD should be modified dynamically as a TCP (or SCTP)
connection is attempted/connected/torn down so that during its lifetime
the connection's IP packets are protected only with comparable SAs.

The more I think about it, the more I think that "connection latching"
a) seems very much related to the "populate from packet" feature of
2401bis, b) should be an integral part of the IPsec architecture, c) is
absolutely necessary in situations where applications drive policy
(e.g., through IPsec APIs), particularly where GSS-API and other channel
binding to IPsec is to be used.

BTW, and for full disclosure, there exist implementations of this
concept, in Solaris 9 and 10, for example.

Nico
-- 

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: New Last Call: 'Tags for Identifying Languages' to BCP

2004-12-15 Thread Bruce Lilly 
>  Date: 2004-12-13 02:05
>  From: "Peter Constable" <[EMAIL PROTECTED]>
>  To: [EMAIL PROTECTED], [EMAIL PROTECTED]

> > > If for whatever reason ISO and the UN decided that "US" should
> > > be used to designate the country of France[...]

> > The only way that would be likely to happen would be if
> > there were no longer a "US" *and* if the ISO and UN
> > representatives of France were to initiate a request for
> > such a change.[...]

> This scenario is not hypothetical; it actually occurred in the case of
> CS.

In the case of "CS", but *NOT* "US" a country had quite
some time earlier ceased to exist.  That is what makes
your "US" scenario hypothetical.

> This is a situation we do not intend to repeat.

That is precisely what would be repeated, and the problem
would remain.  "CS" currently means "Serbia and Montenegro",
and its use in accordance with RFC 3066 has precisely that
meaning.  Changing "CS" to mean something else at some
future time (if/when the proposed draft goes into effect)
would result in at least as many different definitions as
exist at present, and adds yet another time epoch that
needs to be considered in order to determine the meaning
of "CS".

> > > The usability flaw in treating ISO 639 and ISO 3166 as
> human-readable is
> > > evident in the confusion between ja and JP (or is it jp and JA?),
[...]
> It is not uncommon for users to confuse "JA" and "JP". 

Which clearly demonstrates why mere codes in the absence
of definitions associated with the codes is a pointless
proposition. And it illustrates the fact that the only
practical way for a code to become associated with a
particular piece of text is by way of the associated
definition (or something derived from it) rather than
directly.

> > > As for what is silly, if the UN country ID for Canada changed to
> > > CN (and that for PRC changed to something else)[]

> > And it is precisely because of such problems that it is
> > as unlikely to happen as your hypothetical FR->US change.
> 
> Again, not hypothetical at all.

Last time I checked, "US" didn't mean France, and "CN"
didn't mean Canada -- I suggest that you might want to
brush up on the definition of hypothetical, as it is
difficult to have a rational discussion unless we're in
agreement on basic definitions (just as it is difficult
to have effective communications about what language is
indicated by a code without agreement on the *definitions*
of the codes).

> If you're really wanting to know what the meaning of "CS" would be per
> the proposed draft, the proposal is that it will forever remain valid
> with the meaning "Czechoslovakia" as it was originally defined in ISO
> 3166.

But the current meaning under RFC 3066 is quite different.  What
about maintaining the "stability" of that meaning?

> > I haven't specifically discussed "display names"; that is your
> > assertion, and not my basis for objection.
> 
> You didn't use the term "display names", but it is clearly implied by
> your reference to bilingual implementations.

Your inference (which you incorrectly claim as my implication)
is different from my claim.  My claim is that under RFC 3066,
the definitions of the country and language codes is available
in two languages (yes, it's true -- but irrelevant to that
point -- that the IANA registered complete tags do not have
that characteristic), and that the proposed registry would
lack that characteristic of the current BCP (unnecessarily).
 
> > I refer to the
> > definitions and the need to map to and from those definitions
> > at either end of the communications channel. ÂWhether or not
> > that happens by "display" is incidental to the issue of the
> > number of languages that the definitions are provided in.
> 
> Definitions in multiple languages are not a requisite to establishing
> the denotation of a coded element.

True but irrelevant to the point.  We now have definitions of
specific types of elements (viz. country and language tags) in
multiple languages, and the objection is to the unnecessary
removal of that characteristic.

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: New Last Call: 'Tags for Identifying Languages' to BCP

2004-12-15 Thread Bruce Lilly 
>  Date: 2004-12-13 01:05
>  From: "Peter Constable" <[EMAIL PROTECTED]>
>  To: [EMAIL PROTECTED], [EMAIL PROTECTED]

> RFC 3066 does not impose any restrictions on what its replacements might
> do. This is the case with any specification: a given technical
> specification is not a specification of human behaviour and cannot keep
> us from revising the spec or replacing it in any way we may choose.

It's not clear exactly who is meant by "us", but I'll leave
that to a separate message.  It is considered bad practice
for a document which obsoletes another document to depend
on the obsoleted document for definitions or other interpretation
of the meaning of what is contained in the successor document.
 
> You have mentioned conflict with RFCs 2047 and 2231. RFC 2047 does not
> make reference to language tags. The ABNF of RFC 2231 does not impose
> any limit on the length of language tags. RFC does contain an implicit
> length issue in that it updates RFC 2047, allowing language tags within
> encoded words, but it does not explicitly identify any upper bound on
> the length of language tags. By reading both RFC 2047 and RFC 2231, one
> finds that they assume that a language tag must be at most 64 characters
> long:

You have missed several important and not-so-subtle points.
One of which is that RFC 2231 explicitly amends RFC 2047; it
clearly so states in the first page heading and in the text,
and is also indicated in the RFC Index. Another is that
neither uses ABNF; both use EBNF as defined in RFC 822.
More details on specific missed points below:

> - the shortest charset names are 2 characters long (e.g. "IT")

Not all charsets have 2-character names. Not all two-character
names which might be assigned are suitable for MIME use. Where
a preferred MIME name is indicated, that should be used.

> - the minimum encoded-text length is 1 character long

That is strictly only true for text that meets all of the
following conditions:
a) is representable in a specified subset of ANSI X3.4, and
   therefore requires no encoding
b) does not use any encoding, even if unnecessary
c) does not use a charset and character sequence involving
   shift sequences (e.g. as in ISO 2022-like charsets)

It also misses the point that using 76+ octets to represent
a single octet is rather wasteful.

Any use of B encoding will require a multiple of 4 octets
of encoded text. Q encoding has some special cases, but
typically requires 3 octets or more.

> An encoded-word must contain at least 11 characters that are not part of
> the language tag and have a total length of no more than 75 characters.
> Therefore, an upper bound on language tags that can be used in an RFC
> 2047/2231 encoded-word production is 64 characters.

That is a best case upper bound, for text which requires
no encoding at all, one character per encoded-word.

> In many cases, where 
> the charset tag or encoding is longer, the upper bound on the length of
> languages tags will be less, but the RFC gives no estimate or indication
> of how much less.

The worst case appears to be the charset named
Extended_UNIX_Code_Fixed_Width_for_Japanese (43 characters),
which in fact uses ISO 2022-like sequences. That is the
primary name for that charset; there is no preferred MIME
alias, and the only other alias is the one specified for
printer MIB use. Shifted characters are represented by two
octets, each of which requires encoding. The shift sequences
are 3 octets each, and RFC 2047 requires that an encoded-word
start and begin in unshifted state.  Therefore the
minimum amount of encoded text for a single character in
a shifted subset consists of an encoding of: a 3 octet
shift sequence (one of which requires encoding), 2 octets
representing the single character (both requiring encoding),
and 3 octets restoring the unshifted state (one requiring
encoding). Using B encoding results in 12 octets of encoded
text as a minimum (Q-encoding would require a minimum of 16
octets). So a single character in a shifted subset of that
particular charset, using B encoding, leaves at most 12 octets
for a language-tag.  As mentioned, use of an encoded-word
plus the necessary whitespace around it to represent a
single character is rather wasteful, so a brief language tag
is indicated; fortunately "ja" suffices for text likely to
be used with that charset.
 
> This is a constraint on an application of RFC 3066; it is not a
> constraint on RFC 3066 itself. It is possible that other applications of
> RFC 3066 may impose limits that may be longer or shorter than that
> imposed by RFC 2047/2231.

Yes, and it is sometimes desirable to transfer text and
tag from one application to another.  For example, text in
the body of a message can have language indicated by a
Content-Language header field, where there is up to 997
octets available for a language tag.  However a response
regarding some portion of that message might well indicate
the topic of the response in the response message's Subject
field

Re: New Last Call: 'Tags for Identifying Languages' to BCP

2004-12-15 Thread John Cowan 
Bruce Lilly scripsit:

> > I see no reason why limits must be added as a 
> > constraint in a revision of RFC 3066.
> 
> The primary reason for specifying limits is due to the
> proposed removal of the review/registration process
> which currently limits the length of non-private-use
> tags.

The current process does *not* limit the length of non-private-use
tags.  It's true that the process does not permit the registration of
unlimited-length tags, as we do not have enough universe to represent them in 
full.

But absolutely nothing except his good sense prevents Michael from registering
en-the-dialect-spoken-on-the-bowery-between-1933-and-1945-by-alcoholic-drug-users-who-live-in-flophouses.

-- 
John Cowan  [EMAIL PROTECTED]  www.reutershealth.com  www.ccil.org/~cowan
"It's the old, old story.  Droid meets droid.  Droid becomes chameleon. 
Droid loses chameleon, chameleon becomes blob, droid gets blob back
again.  It's a classic tale."  --Kryten, Red Dwarf

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

RE: New Last Call: 'Tags for Identifying Languages' to BCP

2004-12-15 Thread Peter Constable 
> From: [EMAIL PROTECTED] [mailto:ietf-languages-
> [EMAIL PROTECTED] On Behalf Of John Cowan


> But absolutely nothing except his good sense prevents Michael from
> registering
>
en-the-dialect-spoken-on-the-bowery-between-1933-and-1945-by-alcoholic-
> drug-users-who-live-in-flophouses.

Sub-tags can be at most 8 chars long, so Michael would ask for it to be
changed to something like
en-the-dialect-spoken-on-the-bowery-between-1933-and-1945-by-alcoholc-dr
ug-users-who-live-in-flophses. :-)


Peter Constable
Microsoft Corporation

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Issue #719: Transparency/Openness of the IAOC (IASA transition te

2004-12-15 Thread Scott Bradner 

> I actually wonder if this is an issue for the IASA BCP document,
> because it is about the Transition Team Transparency.


I do not think it is

> So I propose to remobve it from the iasa-bcp queue or declare it
> as "No change needed".


makes sense to me

Scott

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Organizationed spam RE: [Sip] WiMAX Summit'05 - Paris - France

2004-12-15 Thread Thomas Gal 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Harald and community,

Observation/Comment from a concerned member. I've never really
complained about anything before, but if I search over the last couple of
months (I did a searchback to Oct 1) across the following mailing lists to
which I'm subscribed:

XCON,AVT,IPSEC,IPTEL,SIP,SIPPING,MMUSIC etc

I get notices from Peter Lewis and Gunther Palmer, sometimes I get
5+ copies of these notices. For example I have 11 notices about the summer
'05 wimax summit in paris france that I haven't deleted floating around my
mailbox! 5 Just today between SIMPLE,XCON,SIPPING,MMUSIC, and SIP! Who
knows how many more went out. I thought this was a little bit
unacceptable(I'm trying to be polite for some reason I guess) as the IETF
itself has 1 announce list for announcing things, and as far as I'm
concerned this is basically spam. I sent a message on November 11th which is
attached basically saying to the principals of this organization that:

- -I'm receiving multiple notices, 
- -think it's unreasonable, 
- -the people sending the notices are not participants on the lists so are
clearly exploiting the mailing list
- -that the IETF has an announce list which they should work out appropriate
submission and distribution through, as I'm sure that IETF memebers would in
fact like to be notified of their events, but appropriately.

I'm copying them on this message again as well, and personally I
feel that if you look at 

http://tinyurl.com/6mvnc
- -and-
http://tinyurl.com/452e5

You can see that peter lewis has been sending bulk unsolicited email
through IETF lists for some time, and Gunter Palmer appears to be a new up
and coming distributor. 

That said, I never got a response, so I'm inclined to say we should
boot them from IETF mailing lists, and ideally get a response and arrange to
have them submit 1 notice 1 time to go out to the IETF announce list, or
perhaps even a separate list which is specifically for folks wishing to
address the IETF population at large. Certainly only willing participants to
the IETF/IETF announce list should be getting these notices. I do recall a
gentleman mentioning in DC something about coordinating reasonable official
submissions, and I feel this falls in line with that request. There's enough
of a problem with spam that we can't do anything about, and I think dealing
with this situation properly could have the potential to not only reduce
some junk mail, but also allow that information to go out in an appropriate
fashion to willing recipients, and perhaps educate some people (who's
company supposedly caters to technology folk) along the way of proper
edicate for such matters. And if they don't respond, who cares, just boot em
and let them suffer the consequences.

Perhaps comments from a few more IETF folk could establish that this
crap is not welcome, or is it just me? 

And to the principals of this orgnaization. Who are you to not
respond to something like this? This is very indicative of pathetic business
practices, and makes me inclined to say bad things about your organizations
morals, and the organization itself, and frankly the people on top who don't
respond as well. Don't you realize that the people who get the most spam and
are more annoyed than anyone by it are the audience you supposedly are
catering to?



- -Tom

[EMAIL PROTECTED]  


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Gunter
> Sent: Wednesday, December 15, 2004 6:28 AM
> To: [EMAIL PROTECTED]
> Subject: [Sip] WiMAX Summit'05 - Paris - France
> 
> . What is the business model for WiMAX? 
> . What do we learn from earlier deployments? 
> . What about the future extensions of the standard? 
> . How is addressed the interoperability challenge? 
> 
> These questions, among others, will be addressed during the 
> second edition of the WiMAX Summit to be organised in Paris 
> next 5-8 April 2005.
> 
>  
> 
> Get all details at:
> 
> http://www.upperside.fr/wimax05/wimax2005intro.htm 
>  
> 
>  
> 
>  
> 
> 
-BEGIN PGP SIGNATURE-

iQA/AwUBQcDmA+q9bQOx/5ayEQLGFACeLMNxzQyiRwgB0n5KdxPHD0s3LxAAnRcl
NfKI62xgIbF44qYivQyJ4Dmj
=IY/A
-END PGP SIGNATURE-
From: Thomas Gal [EMAIL PROTECTED]
Sent: Friday, November 05, 2004 10:05 AM
To: 'Gunther Palmer'
Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]';
'[EMAIL PROTECTED]'
Subject: RE: [Sipping] WiMAX Summit: Call for proposals

I got three copies of this, and a couple for the SSL conference. I 
think stuff like this could be in 1 email sent to general(announce or ietf) 
list? 
Now I checked and it seems you've never posted to a WG(from this 
email), AND the IETF itself doesn't send notices for meetings to every meeting 
to all the working groups. Frankly this seems to me to be spam more or less. 
That’s what the announce list is for. I'm sure there

Re: Organizationed spam RE: [Sip] WiMAX Summit'05 - Paris - France

2004-12-15 Thread Randy Presuhn 
Hi -

> From: "Thomas Gal" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL 
> PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Wednesday, December 15, 2004 5:35 PM
> Subject: Organizationed spam RE: [Sip] WiMAX Summit'05 - Paris - France
...
> Perhaps comments from a few more IETF folk could establish that this
> crap is not welcome, or is it just me?
...

I think it depends on the conference / CFP, the mailing list, and how specific
the posting is.  For example, if someone were to post information on a paper
directly relevant to my working group's work that was going to be presented
at some conference, I'd welcome such a posting.  If someone posted a generic
CFP for a conference with no keywords in common with what my working group
is doing, I'd object.  Between those two extremes are many shades of grey,
but for the working group lists I'm subscribed to, it hasn't been a real problem
for me.

Randy



___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Assuring ISOC commitment to AdminRest

2004-12-15 Thread Brian E Carpenter 
Eric Rescorla wrote:
Brian E Carpenter <[EMAIL PROTECTED]> writes:
I respectfully disagree. The legal thread for our entire standards
process hangs on the Board motions that approved 2026 etc. 

I don't agree with this assessment. IETF's legitimacy as a standards
body depends on people both inside and outside the IETF recognizing
and implementing its standards, not on whether ISOC ratifies
the process or not.
I *did not* say legitimacy, on which I agree with you. But if you want
the liability insurance that protects you against personal liability
for your actions as part of the IETF leadership to hold up in court,
I assure you that those ISOC Board motions will be very, very
important to you (and me, as a current WG Chair).


Having
sweated hard as ISOC Chair to get the last major updates to the
by-laws through, I don't think it's reasonable to ask them for
a by-law about this - at least not as a prerequisite for the
kickoff. I will trust a Board motion.

Maybe it's just that I'm a security guy, but the word "trust" here
makes me very uncomfortable. We're setting up a situation in which the
IETF's ability to operate is completely conditional on ISOC behaving
in the way indicated in the BCP. Given that, I think it's quite
appropriate to have ISOC constrained to behave substantially in that
fashion. Sure, changing your bylaws is hard, but that's precisely why
a bylaw change and not just a board motion is what we need.
I'm not saying a bylaw change would be a bad thing, in due time.
But ISOC can get a Board motion through in about 2 weeks, whereas a bylaw
change takes several months. Making it a prerequisite would cause us
to lose precious time.
Brian
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: IASA BCP -02 Designated Donations - section 5.3

2004-12-15 Thread Brian E Carpenter 
Wijnen, Bert (Bert) wrote:
I am not a real accountant and kind of simple-minded.
So when you say:
"Lynn" == Lynn St Amour <[EMAIL PROTECTED]> writes:
   Lynn> over 80% of ISOC's org. members donate less than $10K
   Lynn> annually and managing these in a 'restricted accounting
   Lynn> manner' requires more effort and overhead.  Also,
   Lynn> organizations/donors expect recognition appropriate to their
   Lynn> contribution and that implies differing levels of value and
   Lynn> distinction.
I then wonder 

- if there is s separate or special bank account for IASA/ETF
- if I can just deposit my donation into that bank account
- What then is the "more effort and overhead" ??
I just do not understand.
Bert, I'm sure Lynn will answer this too, but from when the ISOC was
discussing accounting practices for individual member subscriptions
and donations, I remember that the bank account aspect is the least
of the worries (and anyway, we already reached consensus not to
have a separate bank account). The issue is that accounting entries
have to be made in a very specific way for money which is tied to
a specific purpose, and while that is a small overhead if someone
donates $100k, it becomes a significant overhead if 100 people
donate $1k. It can end up eating money for accounting actions
that really serve no useful purpose but have to be done to follow
thr accounting rules. So I think Lynn is correct and we have to
give ISOC the necessary flexibility.
   Brian
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Issue #719: Transparency/Openness of the IAOC (IASA transition te am question)

2004-12-15 Thread Wijnen, Bert (Bert) 
AS recorded at: https://rt.psg.com/Ticket/Display.html?id=719

I actually wonder if this is an issue for the IASA BCP document,
because it is about the Transition Team Transparency.

So I propose to remobve it from the iasa-bcp queue or declare it
as "No change needed".


Bert


___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: New Last Call: 'Tags for Identifying Languages' to BCP

2004-12-15 Thread Bruce Lilly 
>  Date: 2004-12-13 04:37
>  From: Mark Crispin <[EMAIL PROTECTED]>

> Silliness aside, the file may well have embedded language tags in the text 
> of the file. ÂHave you forgotten Plane 14?

No, but I note that its introduction strongly discouraged
its general use (specifically mentioning ACAP as the
intended scope of usage, IIRC); the current version of the
Unicode document continues that strong discouragement and
further reinforces it by emphasis via italics.

Another issue is that both RFC 3066 and the draft proposal
call for language tags to be expressed in a subset of ANSI
X3.4, corresponding to a subset of the first half of a
particular Unicode plane -- and not plane 14.  There may
be an ambiguity as to whether such deprecated Unicode 3.x
tags are in fact compliant with 3066 or the draft under
discussion.

> > I'm not "eager to abolish" "uniqueness". ÂThere never was
> > any guarantee that codes would never change. Both RFCs
> > 1766 and 3066 specifically mention changes as a fact of
> > life.
> 
> That's what's now being fixed.

No the problem will remain. Currently sr-CS has a specific
meaning under RFC 3066; it has had for some time.  For that
meaning to remain stable, it will be necessary to take any
change in the (current) meaning of the "-CS" part into
account. I.e. for a future parse of language tags to do the
right thing, it will have to recognize sr-CS generated under
the RFC 3066 rules per the 3066/639 definitions.
 
> Why is this vestige of colonialism important in the IETF context?

You seem to be making an incorrect assumption, one which
renders your question meaningless.

> What magic attribute is there to French that provides "definitiveness" 
> that is absent in English, or Mandarin, or Hindi, all of which are far 
> more significant languages to the world?

No such attribute of the language was claimed.  It is the
attribute of being used in the official ISO lists that
provides the characteristic.
 
> A mandatory French translation to an English definition does not 
> significantly increase the information content, and certainly does not 
> double it.

You are again making incorrect assumptions.  The languages
used in ISO documents are considered "separate but equal",
not "a mandatory [...] translation of" some other language.
That is in fact why ISO is called "ISO" and not "OIN" or
"OIS" -- you might wish to visit the ISO web site for
details.
 
[more nonsense about "mandatory translation" elided]

> > You have not explained how the code came to be "embedded
> > within the text itself" -- surely the author didn't say
> > (or write, or sign) "this text is in language QZ"; most
> > likely the language was indicated by name, or by some proxy
> > representing the name (such as a locale).
> 
> Plane 14.
> 
> HTML and other markups.

That provides no explanation of how a *code* came to be
embedded in text -- authors in general do not refer to
language by codes, and codes do not embed themselves by
magic.

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: "connection latching" -- comments on rfc2401bis (draft-ietf-ipsec-rfc2401bis-04.txt)]

2004-12-15 Thread Joe Touch 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nicolas Williams wrote:
| "Connection latching" is a simple concept: connections, for connection-
| oriented protocols, such as TCP or SCTP, that are run over IPsec should
| be 'bound' to the same quality of protection parameters and initiator
| and responder IDs for their duration.
|
| IOW, the SPD should be modified dynamically as a TCP (or SCTP)
| connection is attempted/connected/torn down so that during its lifetime
| the connection's IP packets are protected only with comparable SAs.
|
| The more I think about it, the more I think that "connection latching"
| a) seems very much related to the "populate from packet" feature of
| 2401bis, b) should be an integral part of the IPsec architecture, c) is
| absolutely necessary in situations where applications drive policy
| (e.g., through IPsec APIs), particularly where GSS-API and other channel
| binding to IPsec is to be used.
|
| BTW, and for full disclosure, there exist implementations of this
| concept, in Solaris 9 and 10, for example.
|
| Nico
There's nothing in IPsec that knows about TCP connections now, and there
shouldn't be.
There might be utility to coordinating TCP with IKE, but that means that
the SA used by a packet needs to be set explicitly by the upper layer
rather inferring it from policy rules.
I.e., TCP may need to know about IPsec, not the other way around.
Joe
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD4DBQFBwHq5E5f5cImnZrsRAl1LAJ9kRkYChjk8TFVhv+x9q492r6OfdwCUCPgg
YZTAlDSygZP4nfg/sKUhcA==
=gUAc
-END PGP SIGNATURE-
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: "connection latching" -- comments on rfc2401bis (draft-ietf-ipsec-rfc2401bis-04.txt)]

2004-12-15 Thread Nicolas Williams 
On Wed, Dec 15, 2004 at 09:56:09AM -0800, Joe Touch wrote:
> There's nothing in IPsec that knows about TCP connections now, and there
> shouldn't be.
> 
> There might be utility to coordinating TCP with IKE, but that means that
> the SA used by a packet needs to be set explicitly by the upper layer
> rather inferring it from policy rules.
> 
> I.e., TCP may need to know about IPsec, not the other way around.

Connection latching should, indeed, be initiated by TCP -- but that does
not mean the matter shouldn't be mentioned in the IPsec architecture
doc.

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

RE: New Last Call: 'Tags for Identifying Languages' to BCP

2004-12-15 Thread Peter Constable 
> From: [EMAIL PROTECTED] [mailto:ietf-languages-
> [EMAIL PROTECTED] On Behalf Of Bruce Lilly


> > This is a situation we do not intend to repeat.
> 
> That is precisely what would be repeated, and the problem
> would remain.  "CS" currently means "Serbia and Montenegro",
> and its use in accordance with RFC 3066 has precisely that
> meaning.

And that is a significant problem we wish to remedy as there is some
unknown amount of data or implementations out there that use "CS" but
with a different meaning intended.


> > > > The usability flaw in treating ISO 639 and ISO 3166 as
> > human-readable is
> > > > evident in the confusion between ja and JP (or is it jp and
JA?),
> [...]
> > It is not uncommon for users to confuse "JA" and "JP".
> 
> Which clearly demonstrates why mere codes in the absence
> of definitions associated with the codes is a pointless
> proposition.

I believe you have confirmed my point, that codes are not meant to be
human readable.

As for your concern regarding definition, it has been clearly pointed
out that codes will not be lacking definitions -- the same definitions
they have today from the same sources (with references made to the same
sources) will still be available.


> > Again, not hypothetical at all.
> 
> Last time I checked, "US" didn't mean France, and "CN"
> didn't mean Canada -- I suggest that you might want to
> brush up on the definition of hypothetical...

The case is hypothetical, but the hypothetical case serves to illustrate
a general scenario, and the general scenario is not hypothetical.



> > You didn't use the term "display names", but it is clearly implied
by
> > your reference to bilingual implementations.
> 
> Your inference (which you incorrectly claim as my implication)
> is different from my claim. My claim is that under RFC 3066,
> the definitions...

You have failed to quote what you originally wrote which I claimed made
this implication: you spoke not of definitions but of bilingual
applications.



> > Definitions in multiple languages are not a requisite to
establishing
> > the denotation of a coded element.
> 
> True but irrelevant to the point.

Oh? Simply because you make this assertion?


> We now have definitions of
> specific types of elements (viz. country and language tags) in
> multiple languages, and the objection is to the unnecessary
> removal of that characteristic.

The definitions we have now will remain, they will continue to be
referenced and available. I do not see how you say they are being
removed?


Peter Constable
Microsoft Corporation

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

RE: New Last Call: 'Tags for Identifying Languages' to BCP

2004-12-15 Thread Peter Constable 
> From: [EMAIL PROTECTED] [mailto:ietf-languages-
> [EMAIL PROTECTED] On Behalf Of Bruce Lilly


> Currently sr-CS has a specific
> meaning under RFC 3066; it has had for some time.

The meaning "Serbia and Montenegro" was introduced relatively recently
(a little more than a year ago), was immediately received with alarm by
many in the IT sector. There were vain attempts to get it reversed, and
that failure was an impetus to introduce protection against such changes
in the revision of RFC 3066. I am not aware of "CS" being used in the IT
sector with the new meaning, though cannot guarantee that.


Peter Constable
Microsoft Corporation

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

RE: New Last Call: 'Tags for Identifying Languages' to BCP

2004-12-15 Thread Peter Constable 
> From: [EMAIL PROTECTED] [mailto:ietf-languages-
> [EMAIL PROTECTED] On Behalf Of Bruce Lilly


> > By reading both RFC 2047 and RFC 2231, one
> > finds that they assume that a language tag must be at most 64
characters
> > long...

> > - the shortest charset names are 2 characters long (e.g. "IT")
> 
> Not all charsets have 2-character names...

In determining the longest language tag permitted, one must identify the
shortest possibilities for all other components. 


> > - the minimum encoded-text length is 1 character long
> 
> That is strictly only true for text that meets all of the
> following conditions...

Hey, I just said what the EBNF said.



> > An encoded-word must contain at least 11 characters that are not
part of
> > the language tag and have a total length of no more than 75
characters.
> > Therefore, an upper bound on language tags that can be used in an
RFC
> > 2047/2231 encoded-word production is 64 characters.
> 
> That is a best case upper bound...

I identified it as such.


> The worst case appears to be the charset named
> Extended_UNIX_Code_Fixed_Width_for_Japanese (43 characters)...

> As mentioned, use of an encoded-word
> plus the necessary whitespace around it to represent a
> single character is rather wasteful, so a brief language tag
> is indicated; fortunately "ja" suffices for text likely to
> be used with that charset.

Of course, the length limitations must be balanced between the charset
tag, the language tag and the encoded-word itself.


> > I see no reason why limits must be added as a
> > constraint in a revision of RFC 3066.
> 
> The primary reason for specifying limits is due to the
> proposed removal of the review/registration process
> which currently limits the length of non-private-use
> tags.

The review/registration process for RFC 3066 registrations does not
impose pre-defined limits that implementers of RFC 3066 can assume in
their parsers.



> > It would be a good idea, however,
> > to point out in section 2.1 of the draft that some applications of
this
> > specification may impose limits on the length of accepted language
tags,
> > and perhaps to cite RFC 2231 as an example.
> 
> As a general principle, that's fine, however I would point
> out that given the inability of experts to be able to
> accurately point out the limits quickly...  I do
> not think it is sufficient merely to state the fact that
> there are limits, with or without a pointer to RFC 2231 as
> an example.  Some indication of the magnitude of worst-case
> restrictions is at least advisable...

How is it possible to identify what is the worst-case bound assumed in
implementations that are out there?

How is it possible to predict ahead of time what is the worst-case
length for a RFC3066-registered language tag?

Neither is possible. In light of that, I think it best to make sure
implementers of the revised RFC 3066 be reminded that some
implementations may impose limits (whether those implementers be
constructing tags or passing them from one process to another), and for
implementers to incorporate robustness into their implementations so
that they can respond gracefully if an unexpectedly-long tag is
encountered -- after all, no matter what limit could be imposed in a
revision to RFC 3066, there's no way to stop malware from sending bad
data.

(How *do* encoded-word parsers react if a bogus charset or language tag
that's 2k octets long is encountered? The encoded-word spec already
allows for segmenting long strings; could it not also be revised to
allow segmenting for the parameters, which would also make it more
robust?)


Peter Constable
Microsoft Corporation



___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf