Re: Last Call: Adding a fragment identifier to the text/csv media type (see )

[Tim Bray]

I think this is sensible, could be useful, won’t break anything, and
probably hits a huge 80/20 points for the ways people might want to address
inside spreadsheets.  Go ahead and publish it.


On Thu, Oct 10, 2013 at 11:50 AM, The IESG  wrote:

> The IESG has received a request to update the IANA registration of
> the text/csv media type, adding an optional fragment identifier.
> The request comes from a document in the Independent stream, and the
> IESG is the change controller for the text/csv media type.
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2013-10-24. Exceptionally, comments may
> be sent to i...@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> The document making the request can be obtained via
> http://datatracker.ietf.org/doc/draft-hausenblas-csv-fragment/
>

Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA

[Tim Bray]

How about a BCP saying conforming implementations of a wide-variety of
security-area RFCs MUST be open-source?

*ducks*


On Fri, Sep 6, 2013 at 2:34 PM, David Conrad  wrote:

> On Sep 6, 2013, at 2:06 PM, Måns Nilsson 
> wrote:
> >> Right, because there's no way the NSA could ever pwn the DNS root key.
> > It is probably easier for NSA or similar agencies in other countries
> > to coerce X.509 root CA providers that operate on a competetive market
> > than fooling the entire international DNS black helicopter cabal.
>
> Probably the wrong place to apply the paranoia. How much do you trust the
> AEP Keyper HSM tamperproof blackbox hasn't had a backdoor installed into it
> at the factory?
>
> > Audit and open source seem to be good starting points.
>
> Where feasible, sure. Unfortunately, the rabbit hole is deep.  How many
> billions of transistors are there in commodity chips these days?
>
> Regards,
> -drc
>
>

Re: Last Call: (Concise Binary Object Representation (CBOR)) to Proposed Standard

[Tim Bray]

On Fri, Aug 9, 2013 at 11:52 AM, Barry Leiba wrote:

> To the rest of the community: Does anyone else think it is not
> appropriate to publish CBOR as a Proposed Standard, and see who uses
> it?
>

I have two moderate concerns:

1. I haven’t seen any particularly convincing evidence that CBOR would, in
production, achieve any meaningful reductions in serialization time or
deserialization time or code footprint or memory footprint.
2. I think CBOR does too much; I’d discard half the features and see who
uses *that*.  Well, if it doesn’t take off they can always try CBOR-lite
next year.

But I do not see it as actively harmful, am not screaming or lying down in
the road; go ahead and give it an RFC number and see what happens.

I’d also like to compliment Barry on his restraint and courtesy in dealing
with Phillip here; far more than I would have been able to muster.

 -T



>
> > In this case we have a specification that I am likely going to have to
> argue
> > against as flawed in every WG which might use it.
>
> Yes, I see your arguments, and I appreciate them.  We need that kind
> of input.  I'll let the authors continue to address your comments as
> they see they need to.  But I'll also ask the rest of the community...
>
> To the rest of the community: What is your view of Phill's technical
> arguments with CBOR?  Do you agree that CBOR is flawed?
>
> Now, as I see it, a main argument you have, Phill, is that *no* new
> binary encoding should be proposed as a standard without a working
> group to study what's there, what's needed, what the goals should be,
> and what the right approach is to fulfilling those goals.  Am I
> correct?
>
> With that model, the answer that your goals are valid but are
> different to ours... would not be a valid one -- we would have to
> agree on the goals, and only develop a standard that met that
> agreement.  Am I correct?
>
> To the rest of the community: Do you agree with that concern?  Do you
> think such an analysis and selection of common goals, leading to one
> (or perhaps two) new binary encodings being proposed is what we should
> be doing?  Or is it acceptable to have work such as CBOR proposed
> without that analysis?
>
> Barry
>

Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

[Tim Bray]

Look, I don’t remotely understand the 3gpp universe, and I acknowledge John
Klensin’s point about the advantages of registering things, in general.

Having said that, I worry a little bit that URNs are URIs and there are
lots of specs out there that say “use any URI” and I sure wouldn’t want to
see these things used anywhere near any application-level protocol.

If this were an Apps-Area thing and I thought that registering it would
increase the risk that these patent-encumbered, privacy-compromising,
operationally-fragile constructs had any chance of creeping into general
use by app developers, I’d be lying in the road screaming.  As it is, I
think the issues with this draft have been raised sufficiently, so I’ll
shut up and leave further discussion to those who understand
domain-specific technical issues.

 -Tim



On Sun, Jul 21, 2013 at 12:37 AM, Andrew Allen wrote:

>
> Tim
>
> Seems the text got munged with some copy pasting so here it is corrected:
>
>
> Firstly as stated in
>
> http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/
> the use of the IMEI as a SIP Instance ID only pertains to usage of SIP
> with the 3GPP IMS and if a device is not using IMS without an IMEI then it
> will use a UUID as the SIP instance ID as per RFC 5626. If a device without
> an IMEI uses IMS then it will also still use a UUID as the SIP instance ID
> as per RFC 5626. This is specified also in the 3GPP IMS specification TS
> 24.229 as well as the above draft.
>
>
> So applications running on devices that don't have an IMEI can still use
> SIP for sessions.
>
> The IMEI which has been used in mobile devices for 20 years also survives
> device wipes for the circuit switched calling capability as used by
> billions of mobiles today with 2G and 3G networks. So again how is this
> more harmful for 4G than the current situation with 2G and 3G if a mobile
> device is transferred to a new owner?
>
> Andrew
>
>
>
>  *From*: Andrew Allen [mailto:aal...@blackberry.com]
> *Sent*: Saturday, July 20, 2013 11:48 PM Central Standard Time
> *To*: tb...@textuality.com 
> *Cc*: ietf@ietf.org 
> *Subject*: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
>
>
> Tim
>
> Firstly as stated in
>
> http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/
> the use of the IMEI as a SIP Instance ID only pertains to usage of SIP
> with the 3GPP IMS and if a device is not using IMS sing IMS without an IMEI
> uses IMS then it will still use a UUID as the SIP instance ID as per RFC
> 5626. If a device without an IMEI uses IMS then it will also still use a
> UUID as the SIP instance ID as per RFC 5626. This is specified also in the
> 3GPP IMS specification TS 24.229 as well as the above draft.
>
> So applications running on devices that don't have an IMEI can still use
> SIP for sessions.
>
> The IMEI which has been used in mobile devices for 20 years also survives
> device wipes for the circuit switched calling capability as used by
> billions of mobiles today with 2G and 3G networks. So again how is this
> more harmful for 4G than the current situation with 2G and 3G if a mobile
> device is transferred to a new owner?
>
> Andrew
>
>  *From*: Tim Bray [mailto:tb...@textuality.com]
> *Sent*: Saturday, July 20, 2013 07:01 PM Central Standard Time
> *To*: Andrew Allen
> *Cc*: scott.b...@gmail.com ; ietf@ietf.org <
> ietf@ietf.org>
> *Subject*: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
>
>  On Sat, Jul 20, 2013 at 3:20 PM, Andrew Allen wrote:
>
>> Can it please be explained how the IMEI URN when used as stated in
>> http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/
>> Is any more harmful than as the IMEI is used today by over 90% of mobile
>> phones in use today worldwide?
>>
>
>  It survives device wipes, which usually happen upon change of device
> ownership.
>
> I’m not an expert in your application domain, so pardon me if this
> question is hopelessly naive: It seems that this identifier is related in
> some way to SIP sessions.  It seems that it would be a common operation to
> launch a SIP session on a device such as a WiFi-only tablet, or an iPod
> touch, that doesn’t have an IMEI.  Is this a problem?
>
>   -T
>
>
>>
>> Andrew
>>
>> - Original Message -
>> From: Scott Brim [mailto:scott.b...@gmail.com]
>>  Sent: Saturday, July 20, 2013 03:55 PM Central Standard Time
>> To: Andrew Allen
>>  Cc: tb...@textuality.com ; ietf@ietf.org <
>> ietf@ietf.org>
>> Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
>>
>>  On Sat, Jul 20, 2013 at 4:08 PM, Andrew Allen 
>> wrote:
>> 

Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

[Tim Bray]

Fair enough.  I think it would be reasonable to ask that:

- the draft include the word “privacy”
- the draft discuss the issues around relying on an identifier that
persists across changes in device ownership

There may be an issue concerning a SIP-related identifier which is
unavailable on millions of mobile devices which do not have IMEIs, but it’s
quite possible that it’s non-applicable in the context of the draft.  -T


On Sat, Jul 20, 2013 at 6:23 PM, John C Klensin  wrote:

>
>
> --On Saturday, July 20, 2013 11:36 -0700 Tim Bray
>  wrote:
>
> > So if it's going to be used, exactly as specified, whatever
> > we do, then what value is added by the IETF process?  -T
>
> See my earlier note, but mostly to aid in getting the
> documentation right.  For example, to the extent that the recent
> discussion results in a more complete treatment of privacy
> and/or security considerations in the documentation, that is a
> net improvement and added value.
>
>   john
>
>
>
>

Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

[Tim Bray]

On Sat, Jul 20, 2013 at 3:20 PM, Andrew Allen  wrote:

> Can it please be explained how the IMEI URN when used as stated in
> http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/
> Is any more harmful than as the IMEI is used today by over 90% of mobile
> phones in use today worldwide?
>

It survives device wipes, which usually happen upon change of device
ownership.

I’m not an expert in your application domain, so pardon me if this question
is hopelessly naive: It seems that this identifier is related in some way
to SIP sessions.  It seems that it would be a common operation to launch a
SIP session on a device such as a WiFi-only tablet, or an iPod touch, that
doesn’t have an IMEI.  Is this a problem?

 -T


>
> Andrew
>
> - Original Message -
> From: Scott Brim [mailto:scott.b...@gmail.com]
> Sent: Saturday, July 20, 2013 03:55 PM Central Standard Time
> To: Andrew Allen
> Cc: tb...@textuality.com ; ietf@ietf.org <
> ietf@ietf.org>
> Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
>
> On Sat, Jul 20, 2013 at 4:08 PM, Andrew Allen 
> wrote:
> > Tim
> >
> > The quote is from RFC 5626 which also states:
> >
> > "3.1. Summary of Mechanism
> >
> > Each UA has a unique instance-id that stays the same for this UA even if
> the
> > UA reboots or is power cycled."
> >
> > Since the UUID in the instance ID is also static how is this
> significantly
> > different in terms of privacy concerns from the IMEI being used as an
> > instance ID?
>
> You're not demonstrating that an IMEI is just as good, you're
> demonstrating that a UUID is just as bad.
>
> -
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>

Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

[Tim Bray]

Except that for normal usages at the application level, the UUID is
generated by the app and placed in its private per-app storage, which is
always erased on a factory-reset.  To Andrew Allen: I strongly recommend
factory-resetting your phone before you sell it, and also factory-resetting
any phones you buy second-hand, just to be sure.  Most people do this, for
good reason. -T


On Sat, Jul 20, 2013 at 1:55 PM, Scott Brim  wrote:

> On Sat, Jul 20, 2013 at 4:08 PM, Andrew Allen 
> wrote:
> > Tim
> >
> > The quote is from RFC 5626 which also states:
> >
> > "3.1. Summary of Mechanism
> >
> > Each UA has a unique instance-id that stays the same for this UA even if
> the
> > UA reboots or is power cycled."
> >
> > Since the UUID in the instance ID is also static how is this
> significantly
> > different in terms of privacy concerns from the IMEI being used as an
> > instance ID?
>
> You're not demonstrating that an IMEI is just as good, you're
> demonstrating that a UUID is just as bad.
>

Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

[Tim Bray]

On Sat, Jul 20, 2013 at 1:08 PM, Andrew Allen  wrote:

>
> The quote is from RFC 5626 which also states:
>
> "3.1. Summary of Mechanism
>
> Each UA has a unique instance-id that stays the same for this UA even if
> the UA reboots or is power cycled."
>
> Since the UUID in the instance ID is also static how is this significantly
> different in terms of privacy concerns from the IMEI being used as an
> instance ID?
>

The difference is that the UUID (properly) vanishes when the device is
factory-reset (“wiped”), as is common when a device is passed on to a new
owner.  The IMEI persists, however.  -T



>
> Andrew
>
>  *From*: Tim Bray [mailto:tb...@textuality.com]
> *Sent*: Friday, July 19, 2013 10:58 AM Central Standard Time
> *To*: Andrew Allen
> *Cc*: ietf@ietf.org 
> *Subject*: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
>
>  On Fri, Jul 19, 2013 at 8:38 AM, Andrew Allen wrote:
>
>> I suggest you also read
>>
>> http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/
>>
>
>  Quoting from that document: “If a URN scheme other than UUID is used,
> the UA MUST only use URNs for which an RFC (from the IETF stream) defines
> how the specific URN needs to be constructed...”
>
>  Now, I’m not an expert in the 3GPP world; but the suggestion in that
> extract that UUIDs are a better choice than a (shaky, unreliable,
> privacy-problematic) device identifier certainly rings true for those of us
> who think at the apps level.  -T
>
>
>
>>
>> That will explain the primary application of this URN which is intended
>> for use in the 3GPP cellular standards.
>>
>> Andrew
>>
>>  *From*: Tim Bray [mailto:tb...@textuality.com]
>> *Sent*: Friday, July 19, 2013 10:02 AM Central Standard Time
>> *To*: IETF-Discussion Discussion 
>> *Subject*: Last call: draft-montemurro-gsma-imei-urn-16.txt
>>
>>   Just wanted to point out that both Apple (for iOS) and Google (for
>> Android) have strongly discouraged the use of IMEI to identify devices for
>> the purposes of application software.  There are privacy, quality, and
>> availability issues with their use.  Apple has removed the ability of
>> developers to work with the (often IMEI-derived) “Universal Device ID” (see
>> http://blogs.avg.com/mobile-2/apple-ios-7-puts-unique-device-ids/) and
>> Google has officially deprecated their use:
>> http://android-developers.blogspot.ca/2011/03/identifying-app-installations.html
>>
>>  I’m not sure from reading the draft what the goal of having this URN
>> namespace is, but if it involves encouraging its use by application
>> developers, I’m pretty sure it’s a bad idea.
>>
>>   -Tim
>>  -
>> This transmission (including any attachments) may contain confidential
>> information, privileged material (including material protected by the
>> solicitor-client or other applicable privileges), or constitute non-public
>> information. Any use of this information by anyone other than the intended
>> recipient is prohibited. If you have received this transmission in error,
>> please immediately reply to the sender and delete this information from
>> your system. Use, dissemination, distribution, or reproduction of this
>> transmission by unintended recipients is not authorized and may be
>> unlawful.
>>
>
>  -
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be
> unlawful.
>

Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

[Tim Bray]

So if it’s going to be used, exactly as specified, whatever we do, then
what value is added by the IETF process?  -T


On Sat, Jul 20, 2013 at 11:28 AM, Andrew Allen wrote:

>
> The URN containing the IMEI is used by all mobile phones that support
> voice over LTE. It is a dependency for 3GPP release 8 (which was completed
> about end of 2008). So yes it is going to be used and its more than 3 years
> of 3GPP work invested and is already incorporated into many devices.
>
> In the pre-existing circuit switched systems the IMEI is delivered to the
> network as the device identifier and it is also necessary to deliver the
> same device identifier to the network when using SIP so that when handover
> takes place between packet switched and circuit switched the network can
> correlate the communication as being with the same device.
>
> Regulations also require the IMEI to be delivered to the network.
> This associated draft describes how 3GPP uses the IMEI as a SIP instance
> ID and the reasons why:
>
> http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/
>
>
>
> - Original Message -
> From: Scott Brim [mailto:scott.b...@gmail.com]
> Sent: Saturday, July 20, 2013 06:23 AM Central Standard Time
> To: S Moonesamy 
> Cc: Tim Bray ; ietf@ietf.org 
> Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
>
> Thanks, SM, for finding what I said back in 2010.  I still think this
> is architected wrong, conflating devices with communication endpoints
> higher up the stack, and steers us toward a path toward eventually
> "needing" to reduce privacy even more.  However, 3GPP has apparently
> already already started marching down that path.  Could our liaison
> explain the situation there?  Is anyone actually going to use it?  Is
> this a done deal - do we have to support it because otherwise 3 years
> of 3GPP work get undone?
>
> Scott
>
> -
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>

Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

[Tim Bray]

Hm, I confess that I searched the text of the draft for the word “privacy”
and jumped to conclusions upon seeing no matches.  Probably a good idea to
work it in for impatient folk like me.

I would expand that section to point out that since the IMEI survives
device wipes and changes of possession, it shouldn’t be assumed to identify
a person.

And I really wouldn’t ever expose an IMEI at the application level, but
maybe it’s appropriate at the level this draft is addressing.  We had
endless nightmares, not only because of the wipe-survival, but because app
code would try to run on a device that didn't have an IMEI and crash, and
so on.  -T


On Fri, Jul 19, 2013 at 3:53 PM, Andrew Allen  wrote:

>
> Tim
>
> Do you not think that the text in the security considerations section::
>
> "because IMEIs can be loosely correlated to a user, they need to be
> treated as any other personally identifiable information. In particular,
> the IMEI URN MUST NOT be included in messages intended to convey any level
> of anonymity"
>
> covers the privacy issue?
>
> If not what is the additional privacy concern?
>
> Andrew
>
>  *From*: Tim Bray [mailto:tb...@textuality.com]
> *Sent*: Friday, July 19, 2013 12:07 PM Central Standard Time
> *To*: S Moonesamy 
> *Cc*: IETF-Discussion Discussion 
> *Subject*: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
>
>  On Fri, Jul 19, 2013 at 9:52 AM, S Moonesamy wrote:
>
>>
>> It would be easier to have the draft discuss the GSMA URN only.  The
>> alternative is to have the draft discuss the privacy considerations of
>> using IMEI and IMEISV.
>>
>
>  Good catch.  Assuming this is a good idea (I’m dubious) it would be
> completely unacceptable to register it without a discussion of privacy
> implications. -T
>
>
>>
>> Regards,
>> S. Moonesamy
>>
>
>  -
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be
> unlawful.
>

Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

[Tim Bray]

On Fri, Jul 19, 2013 at 9:52 AM, S Moonesamy  wrote:

>
> It would be easier to have the draft discuss the GSMA URN only.  The
> alternative is to have the draft discuss the privacy considerations of
> using IMEI and IMEISV.
>

Good catch.  Assuming this is a good idea (I’m dubious) it would be
completely unacceptable to register it without a discussion of privacy
implications. -T


>
> Regards,
> S. Moonesamy
>

Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

[Tim Bray]

On Fri, Jul 19, 2013 at 8:38 AM, Andrew Allen  wrote:

>  I suggest you also read
>
> http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/
>

Quoting from that document: “If a URN scheme other than UUID is used, the
UA MUST only use URNs for which an RFC (from the IETF stream) defines how
the specific URN needs to be constructed...”

Now, I’m not an expert in the 3GPP world; but the suggestion in that
extract that UUIDs are a better choice than a (shaky, unreliable,
privacy-problematic) device identifier certainly rings true for those of us
who think at the apps level.  -T



>
> That will explain the primary application of this URN which is intended
> for use in the 3GPP cellular standards.
>
> Andrew
>
>  *From*: Tim Bray [mailto:tb...@textuality.com]
> *Sent*: Friday, July 19, 2013 10:02 AM Central Standard Time
> *To*: IETF-Discussion Discussion 
> *Subject*: Last call: draft-montemurro-gsma-imei-urn-16.txt
>
>   Just wanted to point out that both Apple (for iOS) and Google (for
> Android) have strongly discouraged the use of IMEI to identify devices for
> the purposes of application software.  There are privacy, quality, and
> availability issues with their use.  Apple has removed the ability of
> developers to work with the (often IMEI-derived) “Universal Device ID” (see
> http://blogs.avg.com/mobile-2/apple-ios-7-puts-unique-device-ids/) and
> Google has officially deprecated their use:
> http://android-developers.blogspot.ca/2011/03/identifying-app-installations.html
>
>  I’m not sure from reading the draft what the goal of having this URN
> namespace is, but if it involves encouraging its use by application
> developers, I’m pretty sure it’s a bad idea.
>
>   -Tim
>  -
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be
> unlawful.
>

Last call: draft-montemurro-gsma-imei-urn-16.txt

[Tim Bray]

Just wanted to point out that both Apple (for iOS) and Google (for Android)
have strongly discouraged the use of IMEI to identify devices for the
purposes of application software.  There are privacy, quality, and
availability issues with their use.  Apple has removed the ability of
developers to work with the (often IMEI-derived) “Universal Device ID” (see
http://blogs.avg.com/mobile-2/apple-ios-7-puts-unique-device-ids/) and
Google has officially deprecated their use:
http://android-developers.blogspot.ca/2011/03/identifying-app-installations.html

I’m not sure from reading the draft what the goal of having this URN
namespace is, but if it involves encouraging its use by application
developers, I’m pretty sure it’s a bad idea.

 -Tim

Re: W3C standards and the Hollyweb

[Tim Bray]

On Fri, Apr 26, 2013 at 12:59 PM, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:

> 1. DRM is a fact of life, and it is therefore better that there should
> be a well-formulated standard than a free-for-all. A free-for-all is a
> guaranteed route to non-interoperability.
>

Crack cocaine, prostitution, and political corruption are also facts of
life.

OK, pardon the cheap shot, but I don’t think SDOs that have some sort of
stewardship relationship to the Internet should ever play any part
whatsoever in the facilitation of DRM.

I won’t consume your input bandwidth by backing up this position; the
arguments pro and contra DRM are not exactly secret, and I haven’t heard
any new ones in some years.  -T

Re: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-arch...@w3.org from September 2012)

[Tim Bray]

One more data point... I work on Web software all the time and have for
many years; in recent years mostly at the REST (app-to-app HTTP
conversations) rather than browser-wrangling level.  I’d have to say that
URI interoperability problems haven’t come near getting into the list of
top-20 pain points.   So either my experience is wildly untypical, or maybe
it’s a combination of being a little bit lucky, and that the pain which
exists is highly concentrated in the browser space.  -T

On Mon, Oct 22, 2012 at 5:05 PM, Ian Hickson  wrote:

> On Tue, 23 Oct 2012, Mark Nottingham wrote:
> > On 23/10/2012, at 10:40 AM, Ian Hickson  wrote:
> > > On Tue, 23 Oct 2012, Mark Nottingham wrote:
> > >>
> > >> Don't much care about the venue, as long as there's *some*
> > >> coordination / communication.
> > >
> > > Everyone is welcome to participate in the WHATWG list.
> >
> > As they are on the IETF list. The difference is that the WHATWG is run
> > by an unelected board of "members" - .
>
> "Run" is a bit of a strong word. There's basically no non-public activity
> from the charter members.
>
>
> > > Anne's spec will define "valid URL", which addressed that need.
> >
> > Why not define (or reuse) a separate term for the input stream, and
> > leave "URL" alone?
>
> Because everyone calls these things URLs (except STD 66).
>
>
> > >> Browser implementers may not care, but it's pretty obvious that lots
> > >> of other people do.
> > >
> > > Browser implementors aren't particularly special here.
> >
> > No, but your arguments are often coloured by your perspective -- just as
> > everyone else's are.
>
> Which arguments in particular are we talking about here? I've mostly been
> talking about curl, wget, GoogleBot, Perl libraries, etc.
>
>
> > If I believed that Anne was willing to and capable of re-specifying
> > RFC3986 in such a way that the definition, syntax and semantics of URLs
> > (or whatever they ends up being called) doesn't change at all, I'd be
> > less concerned.
> >
> > However, that doesn't seem very likely, especially when he isn't
> > engaging with the folks that wrote that spec (especially, Roy).
> >
> > RFC3986 is referenced by a LOT of technologies, not just Web browsers,
> > not just HTML. Replacing it unilaterally with input from the browser /
> > HTML community from an implementer perspective is very likely to break
> > most of them.
>
> I suspect it will break nothing, but I guess we'll find out.
>
> I don't really understand how it _could_ break anything, so long as the
> processing of IRI and URIs as defined by IETF is the same in the WHATWG
> spec, except where software already differs with the IETF specs.
>
> Do you have a concrete example I could study?
>
>
> > As such, they won't use your new spec, and we'll be living in a world
> > where there will be two definitions of "URL" -- the IETF one and the
> > WHATWG one [...].
> >
> > That seems a pretty bad tradeoff for the benefits you're getting -- a
> > slightly easier-to-read spec for browser implementers (a relatively tiny
> > audience).
>
> If you have any concrete concerns, please don't hesitate to e-mail the
> WHATWG list, showing the specific examples you're worried about. Browsers
> are but one of many implementation classes that are relevant.
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-arch...@w3.org from September 2012)

[Tim Bray]

On Mon, Oct 22, 2012 at 3:35 PM, Ian Hickson  wrote:

> > The notion that curl, or an HTTP cache manager, or an XML namespace
> > processor, is going to be routing around errors, strikes me on the face
> > of it as being wrong.  One of the main uses I put curl to is making sure
> > I have the URL exactly right before I drop it into chat or whatever.
>
>$ wget 'http://example.com/a b'
>--2012-10-23 00:27:43--  http://example.com/a%20b
>
># test.cgi returns a 301 with "Location: a b"
>$ curl -L
> http://damowmow.com/playground/demos/url/in-http-headers/test.cgi
>This file is:
> http://damowmow.com/playground/demos/url/in-http-headers/a%20b
>
> Software does this stuff already. We need to make sure it does it
> interoperably.
>

Hmm.  I went to tbray.org and made a file at '$ROOT_DIR/tmp/a b' - note the
space.

Then I did

curl -I 'http://www.tbray.org/tmp/a%20b'
curl -I 'http://www.tbray.org/tmp/a b'

Curl, quite properly, doesn’t fuck with what I ask it, and revealed a very
interesting fact: That my Apache httpd returns 200 for both of these, but,
with, uh, interesting variations, amounting to what I think is quite
possibly a bug.  I also pasted the version with the space into the nearest
Web browser, and it quite properly auto-corrected to a%20b.

I think it’s a bug that curl is claiming the 301 pointed at "a%20b" not "a
b".  Because suppose it had pointed at "a%20b" - I don’t want middleware
lying to me.

It seems like a good idea to document the steps by which "a b" pasted in
becomes "a%20b" in the address bar. But I don’t see the relevance outside
human-authored strings.  -T


>
>
> On Tue, 23 Oct 2012, Julian Reschke wrote:
> >
> > This always was about venue, not people. If people want to "fix" or
> > "augment" URIs/IRIs, they should come over to the IETF.
>
> I think the person doing the work has the prerogative to do it wherever he
> or she wants to do it. Maybe the IETF should consider why Anne isn't doing
> it in the IETF.
>
>
> > > The specs don't define everything that implementations have to do to
> > > be interoperable. If the IETF doesn't think that's a problem, then
> > > that's fine, but then y'all shouldn't be surprised when people who
> > > _do_ think that's a problem try and fix it.
> >
> > Yes, please fix *that*, but *just* that without messing with the basics
> > without consensus/review.
>
> Consensus isn't a value I hold highly, but review of Anne's work is
> welcome.
>
> If the IETF community didn't want Anne to do this work, then the IETF
> community should have done it. Having not done it, having not even
> understood that the problem exists, means the IETF has lost the
> credibility it needs to claim that this is in the IETF's domain.
>
> You don't get to claim authority over an area while at the same time
> telling someone else "please fix that" for the hard work that comes with
> that area. The reality is, he who does the hard work, gets the authority.
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-arch...@w3.org from September 2012)

[Tim Bray]

On Mon, Oct 22, 2012 at 2:46 PM, Ian Hickson  wrote:

> On Mon, 22 Oct 2012, Roy T. Fielding wrote:
>>
>> What you are insisting on defining as a "URL" is the input to the
>> process of making a hypertext reference (the arbitrary string typed into
>> a dialog or placed inside an href/src attribute)
>
> Or placed on a command line to wget(1), or put in an RDFa triple store, or
> in transmitted in an HTTP Location: header, or...

It seems reasonable that someone should write rules for dealing with the
kinds of errors that are observed to occur in links as embedded in resource
representations AKA HTML pages.  It also seems reasonable that WHATWG, who
speak (if I understand correctly) for browser builders, can write those
rules.

The notion that curl, or an HTTP cache manager, or an XML namespace
processor, is going to be routing around errors, strikes me on the face of
it as being wrong.  One of the main uses I put curl to is making sure I
have the URL exactly right before I drop it into chat or whatever.   -T

Re: So, where to repeat?

[Tim Bray]

Frankfurt as the Minneapolis of Europe: central, well-connected, cold,
unglamorous.  -T

On Thu, Aug 9, 2012 at 11:37 AM, Geoff Mulligan  wrote:
>
> On 08/09/2012 09:17 AM, Yoav Nir wrote:
>>
>> On Aug 9, 2012, at 6:07 PM, Dave Crocker wrote:
>>
>>> offlist.
>>
>> Not so much
>>
>>> Geoff,
>>>
>>> Frankfurt is a city in Germany.  I believe the IETF has never been there.
>>
>> Two more tidbits:
>>   - It's a huge aviation hub. There are direct flights from everywhere,
>> similar to CDG, Heathrow, or Schiphol
>>   - Unlike Paris, London and Amsterdam, it's not a great tourist
>> attraction, so conceivably it would be cheaper.
>
> I've found it relatively inexpensive, clean and very easy to get to.
>>
>>
>>> Other than those two tidbits about it, I've no idea what is to be
>>> accomplished by someone's randomly throwing out the names of cities for
>>> a discussion like this, especially when threads like these always have a
>>> great deal of trouble staying focused on the /principle/ rather than
>>> haggling the details.
>>
>> The principle would be to go to aviation hubs so as to minimize the
>> collective pain. Most people from the US going to Prague, would have a
>> connection in Frankfurt, so a meeting in Frankfurt would reduce the amount
>> of flights.
>
> This is why I threw out a "not so random" city name - Frankfurt.
>>
>>
>> Yoav
>>
>>> On 8/8/2012 12:24 PM, Geoff Mulligan wrote:

 Frankfurt?



 On Aug 8, 2012, at 12:49 PM, Dave Crocker  wrote:

>
> On 8/8/2012 11:46 AM, Geoff Mulligan wrote:
>>
>> So then why not consider, London, Paris (not the Concorde Lafayette),
>> Frankfurt, Amsterdam?
>
>
> shockingly, amsterdam can't handle the ietf.  wrong mix of resources.
> really.
>
> paris appears to have broad crime and work-ethic patterns that also are
> problematic, not just at the concorde.
>
> to be clear: i'm speaking for myself.
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net


>>> --
>>>   Dave Crocker
>>>   Brandenburg InternetWorking
>>>   bbiw.net
>>>
>>> Scanned by Check Point Total Security Gateway.
>
>

Re: Basic ietf process question ...

[Tim Bray]

I gave such a Sunday tutorial at IETF70.  The slides are here
(somewhat dated, but still useful I’d say):
http://www.tbray.org/tmp/IETF70.pdf

 -Tim

On Sat, Aug 4, 2012 at 6:34 PM, Worley, Dale R (Dale)  wrote:
>> From: Mark Nottingham [m...@mnot.net]
>>
>> What surprises me and many others is that people are still using it
>> and promoting it, when it's well-understood by almost EVERYONE who was
>> involved in using XML for protocols in the past ten years agrees that
>> it's a mistake.
>
> It sounds to me like what is needed is some sort of "best common
> practices" document regarding data aggregation and encoding, or even
> perhaps an IETF Sunday tutorial.  Lots of people who are never going
> to become experts in the field need to make good choices when
> designing protocols...
>
> Dale

Re: Oauth blog post

[Tim Bray]

I have not been involved in the OAuth design processes, but for the
last few months, I’ve been a heavy user of production OAuth2 software.
Which I felt gave me a platform to comment  on the issue:
http://www.tbray.org/ongoing/When/201x/2012/07/28/Oauth2-dead

 -Tim

On Sun, Jul 29, 2012 at 2:57 PM, Hannes Tschofenig
 wrote:
> It sounds indeed great to involve those communities that use the technology. 
> However, I don't see an easy way to accomplish that when we talk about a 
> really large community.
>
> For example, many people use TLS and they are not all in the TLS WG working 
> group. I am not even talking about providing useful input to the work (since 
> you would have to be a security expert and some people just want to get their 
> application development done as quickly as possible). They just use the 
> library.
>
> OAuth is a bit similar in that direction. Ideally, we want Web application 
> developers to just use a library and then add their application specific 
> technology on top of it rather than having to read the IETF specification and 
> to write the OAuth code themselves.
>
> On Jul 29, 2012, at 2:13 PM, Worley, Dale R (Dale) wrote:
>
>>> From: Hannes Tschofenig [hannes.tschofe...@gmx.net]
>>>
>>> Eran claims that enterprise identity management equipment manufacturer 
>>> dominate the discussion.
>>
>> There's a common problem in the IETF that the development of a standard is 
>> dominated by companies that incorporate the standard into their products, 
>> whereas the people who "really should" be involved in the development are 
>> those who will *use* the standard in operation.
>>
>> Dale
>

Re: Long discussion about IETF on the Internet Governance Caucus mailing list

[Tim Bray]

Who are these people? -T

On Mon, May 28, 2012 at 8:34 AM, Stephane Bortzmeyer  wrote:
> I believe it is relevant here since IETF is currently being discussed
> in depth on the Internet Governance Caucus mailing list (one of the
> biggest forums of the "civil society" about Internet governance).
>
> The thread is long and, for those who are not subscribed, can be found
> here on the Web:
>
> http://lists.igcaucus.org/arc/governance/2012-05/msg00380.html
>
> There are two things being discussed about the IETF:
>
> 1) Does it do a good job of creating and promoting technical
> standards?
>
> 2) If yes, can it be used as a "model" for Internet governance of
> other, more political, functions?
>

Re: Add a link to the HTML version in i-d-announce mails ?

[Tim Bray]

Not that voicing opinions on this topic has ever done any good. -T

On Tue, Mar 6, 2012 at 2:15 PM, Russ Housley  wrote:
>
>> Pictures in RFCs?
>
> Come to the RFCFORM BOF to voice opinions on this topic.
>
> Russ
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Tim Bray]

+1

On Thu, Mar 1, 2012 at 9:50 AM, Peter Saint-Andre  wrote:
> 
>
> On 2/21/12 11:10 AM, IESG Secretary wrote:
>> A modified charter has been submitted for the Hypertext Transfer
>> Protocol Bis (httpbis) working group in the Applications Area of the
>> IETF.  The IESG has not made any determination as yet.  The modified
>> charter is provided below for informational purposes only.  Please send
>> your comments to the IESG mailing list (i...@ietf.org) by Tuesday,
>> February 28, 2012.
>
> Clearly this rechartering request has triggered a lengthy discussion
> about web authentication. However, the only comment on the charter
> itself Stephen Farrell's noting that this bullet is a bit vague
> (specifically that it does not mention authentication):
>
>> * Reflecting modern security requirements and practices
>
> Stephen and I just had a chat about this matter. He and I came up with a
> proposed paragraph to add after that list of bullet points:
>
>   In the initial phase of work on HTTP/2.0, new proposals
>   for authentication schemes can be made.  The WG will
>   select zero or more of those with a goal of choosing
>   at least one scheme that is better than those available
>   for HTTP/1.x.  Non-selected schemes might be discussed
>   with the IETF Security Area for further work there.
>
> Your comments are welcome.
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Tim Bray]

On Thu, Feb 23, 2012 at 5:24 PM, Roy T. Fielding  wrote:

>> Seriously, someone needs to propose some charter language or this
>> discussion is a no-op.  -Tim
>
> "Proposals for new HTTP authentication schemes are in scope."

+1

I don’t think we’ll get one, but in the unlikely event someone can
build consensus for something, there’s no reason to brand it as
out-of-bounds.  -T
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Tim Bray]

On Thu, Feb 23, 2012 at 5:13 PM, Roy T. Fielding  wrote:

> How many times do we have to do this before we declare insanity?
> I don't care how much risk it adds to the HTTP charter.  They are
> all just meaningless deadlines anyway.  If we want HTTP to have
> something other than Basic (1993) and Digest (1995) authentication,
> then it had better be part of *this* charter so that the proposals
> can address them.

Well, Digest already isn't used by anyone :)

Seriously, someone needs to propose some charter language or this
discussion is a no-op.  -Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Tim Bray]

Your points granted, the feeling of the HTTP-using community is, by
and large, that HTTP security/authz as it stands is “good enough”.
Are you arguing that the security of HTTP 2.0 should be required to be
qualitatively better?  If so, someone is going to need to provide some
useful language to put in the draft charter so that we can argue about
specifics not armwaving.
-Tim

On Thu, Feb 23, 2012 at 10:00 AM, Leif Sawyer  wrote:
> I've got the last 2 decades of experience trying to deal with security on the 
> network.
>
> 95% is dealing with the peculiarities of the "bolt-on"  after-thoughts.
>
> I would much prefer seeing security  designed-in, with the flexibility to 
> deal with
> the future...
>
> 
> From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of RJ Atkinson 
> [rja.li...@gmail.com]
> Sent: Thursday, February 23, 2012 8:59 AM
> To: ietf@ietf.org
> Subject: Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)
>
> On 23  Feb 2012, at 11:13 , Julian Reschke wrote:
>> On 2012-02-22 18:01, RJ Atkinson wrote:
>>> Security that works well and is practical to implement
>>> needs to be designed-in, not bolted-on later.
>>
>> I would say: security needs to be orthogonal.
>
> There are at least 2 decades of experience that
> security has to be design-in, rather than bolted-on,
> for it to work well -- and for it to be practical
> to implement.
>
> I hear that you don't agree, but the IETF experience
> on this specific point really is quite clear.  Add-on
> security doesn't work.
>
> Yours,
>
> Ran
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Tim Bray]

[in-line]

On Tue, Feb 21, 2012 at 2:40 PM, Mark Nottingham  wrote:
>> And then should it include adding some new options
>> or MTI auth schemes as part of HTTP/2.0 or even looking
>> at that? (I think it ought to include trying for that
>> personally, even if there is a higher-than-usual risk
>> of failure.)
>
>
> Based on past experience, I think the risk is very high, and we don't need to 
> pile any more risk onto this particular project.

+1

HTTP's ability to be equipped with security technology has been
adequate, and I haven't heard much argument that its semantics were
the big obstacle to newer/better security.  Preserving its semantics
means its successor should be equally adequate.

Mnot is *understating* the risk of loading up the charter with this stuff. -T
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: ITC copped out on UTC again

[Tim Bray]

One consequence of your proposal, if adopted, is that there will need
to be a specification of the canonical Internet-time-to-Sidereal-time
function, so that in the long run, the time that your computer says it
is will correspond with what you observe looking out the window. The
Internet will be around long enough that this will indeed become a
problem.

I'd want to look at that specification before getting passionate pro
or contra in this argument. -T

On Fri, Jan 20, 2012 at 6:20 AM, Phillip Hallam-Baker  wrote:
> If we are ever going to get a handle on Internet time we need to get rid of
> the arbitrary correction factors introduced by leap seconds.
>
> The problems caused by leap seconds are that they make it impossible for two
> machines to know if they are referring to the same point in future time and
> quite often introduce errors in the present.
>
> 1) No machine can determine the number of seconds between two arbitrary UTC
> dates in the future since there may be a leap second announced.
>
> 2) If Machine A is attempting to synchronize with machine B on a future
> point in time, they cannot do so unless they know that they have the same
> view of leap seconds. If a leap second is announced and only one makes the
> correction, an error is introduced.
>
> 3) In practice computer systems rarely apply leap seconds at the correct
> time in any case. There is thus a jitter introduced around the introduction
> of leap seconds as different machines get an NTP fix at different points in
> time.
>
> 4) Even though it is possible to represent leap seconds correctly in
> standard formats, doing so is almost certain to exercise code paths that
> should be avoided.
>
>
> Since the ITU does not look like sorting this out, I suggest we do so in the
> IETF. There is no functional reason that Internet protocols should need leap
> seconds.
>
> I suggest that the IETF plan to move to Internet Time in 2015, immediately
> after the next ITU meeting. Internet time would be TAI plus the number of
> leap seconds that have accumulated up to the next ITU decision point. So if
> UTC drops leap seconds at the next meeting the two series will be in sync,
> otherwise there will be a divergence.
>
>
>
> --
> Website: http://hallambaker.com/
>
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: https

[Tim Bray]

I'm increasingly coming to think that *everything* should be done with
TLS unless you can prove it's harmful.  Call me paranoid, but given
the general state of the world, secure-by-default seems like the way
to go.  -Tim

On Fri, Aug 26, 2011 at 1:39 AM, t.petch  wrote:
> - Original Message -
> From: "SM" 
> To: "t.petch" 
> Cc: "IETF Discussion" 
> Subject: Re: https
>
>
>> Hi Tom,
>> At 00:18 26-08-2011, t.petch wrote:
>> >Besides all the usual hassle of TLS, today the certificate is
>> >reported by IE as
>> >expired, which sort of sums it up.
>>
>> Already reported to ietf-action@.
>>
>> Regards,
>> -sm
>>
>> P.S. My experience of ietf-action@ is that they are responsive and do
>> fix problems that are reported.
>
> Yup, but why are we using https at all?  Who decided, and please would they
> undecide?  Unexpired certificates can be circumvented, but all too often, the
> https parts of the web site just do not work and, more importantly, I think it
> wrong to use industrial grade security where none is called for.
>
> Tom Petch
>
>
>>
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Optimizing for what? Was Re: IETF Attendance by continent

[Tim Bray]

I should point out that Canada has most of the logistical advantages the usa
enjoys, while imposing quite a bit less visa pain.
- Tim
On Sep 5, 2010 3:39 PM, "Andrew G. Malis"  wrote:
> I've been to several conferences at the Hilton Hawaiian Village in
> Waikiki. Both the hotel and the attached convention center are large
> enough to host several IETFs simultaneously.
>
> Cheers,
> Andy
>
> On Tue, Aug 31, 2010 at 11:08 PM, Glen Zorn  wrote:
>> Hadriel Kaplan [mailto://hkap...@acmepacket.com] writes:
>>
>> ...
>>
>>> >
>>> > Why Kauai?  You list detailed reasons why Hawaii is logical and
>>> > solves for many of the problems, but you don't say why this island.
>>>
>>> Because it's the nicest, obviously. :)
>>
>> I strongly disagree: the leeward coast of Maui (in particular, Kihei &
>> south) is far better.  Kauai is way too rainy...
>>
>>>
>>>
>>> >
>>> >>   We can even rotate islands if people get bored.
>>> >
>>> > Well, there are extensive conference facilities on Oahu, the Big
>>> > Island, Maui, and Kauai.  I have no information as to if they would
>>> > work for a group of our size and with our need for breakout rooms.
>>>
>>> I used to attend IEEE 802 and they met in Kauai (Grand Hyatt in Poipu)
>>> every few years, but they were a smaller group.  There aren't many
>>> restaurants nearby, but I certainly don't remember anyone ever
>>> complaining about it. ;)
>>
>> 3GPP2 used to (still does?) meet in Wailea every December.  Although that
is
>> also a much smaller group than the IETF, the hotels dwarfed it so it
might
>> be possible to find a reasonable venue for the IETF.  However, I think
that
>> this is just an idle fantasy: the IETF has too much moral fiber to meet
>> someplace that might actually be fun ;-).
>>
>>>
>>> -hadriel
>>> ___
>>> Ietf mailing list
>>> Ietf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf
>>
>>
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Ok .. I want my IETF app for my iPad ..

[Tim Bray]

On Sun, Apr 4, 2010 at 11:38 AM, Mark Nottingham  wrote:
> Step-by-step instructions (with illustrations) for Americans to use their 
> credit cards overseas.

Anyhow, it has to be an iPad app, rather than iPhone/iPod-touch,
because the smaller devices can't display 80-char-66-line ASCII
properly.  -T

>
>
> On 04/04/2010, at 1:11 PM, Ole Jacobsen wrote:
>
>>
>> And what, pray tell, does an IETF app actually do?
>>
>> Generate random travel topics that we can argue about?
>>
>> Display RFCs?
>>
>> Doesn't this new toy of yours already have a browser?
>>
>> You want emacs on it?
>>
>> xml2rfc for the iPad?
>>
>> A list of local restaurants in Minneapolis?
>>
>> What do you want?
>>
>> Ole
>>
>>
>> Ole J. Jacobsen
>> Editor and Publisher,  The Internet Protocol Journal
>> Cisco Systems
>> Tel: +1 408-527-8972   Mobile: +1 415-370-4628
>> E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj
>>
>>
>>
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>
>
> --
> Mark Nottingham     http://www.mnot.net/
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Advance travel info for IETF-78 Maastricht

[Tim Bray]

What Iljitsch doesn't say, and should be said,  is that Maastricht is a
lovely and charming place in the summer; its central square is one of the
nicer places in Europe to linger over lunch or dinner.
When I went I rented a car in Frankfurt and enjoyed the Autobahn experience.
Not a complicated route at all.
- T

On Mar 28, 2010 8:45 PM, "Melinda Shore"  wrote:

Chris Elliott wrote:
>
> Google Maps lists several restaurants in the 2-3km range walking. That's
do...
During meetings I appreciate opportunities to get off my can and
get out of the venue but I hope there will be meal options for
people who aren't able-bodied and who aren't able to walk a
couple of miles during a 1.5-hour lunch break.

Melinda


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.or...
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Data points with screenshots, on specification publishing formats

[Tim Bray]

If you add up the numbers, about a quarter of a million seriously
Internet-capable mobile devices are being sold every day between
iPhone, Android, and Blackberry.  I'd like to illustrate the
experience with some screenshots from such a device - this happens to
be a Nexus One Android, which is a typical example of such a thing,
roughly comparable in display capabilities to current iPhones.  I'm
told that Blackberries are a little behind but catching up.

Just suppose, for example, that I wanted to look up the link
relationships defined in RFC4287.  Taking the direct path, if I type
"rfc4287" into google and take the first hit, I get to
http://www.ietf.org/rfc/rfc4287.  After I page through several screens
of line breakage to get to the TOC, I see
http://www.tbray.org/reflowable/tvh4.jpg

So, I need to page through 21 80-column 66-line pages; tedious, and
when I was doing this today I went past it by accident, got totally
lost.  Anyhow, eventually I got to this discussion of the link
relationships: Ugly, and I have to work around the page headers:
http://www.tbray.org/reflowable/tvh5.jpg

Finally, I get to the list of link relationships:
http://www.tbray.org/reflowable/tvh6.jpg

Now, I happen to know where to find a sensible minimal-HTML version; a
couple of flicks of the screen get me to the TOC:
http://www.tbray.org/reflowable/tvh1.jpg

I tap directly on the link for section 4.2.7 which gets me this:
http://www.tbray.org/reflowable/tvh2.jpg

Here's list of relationships: http://www.tbray.org/reflowable/tvh3.jpg

Yeah, it's not perfect, I have to do a bit of side-scrolling here and
there; turning the phone sideways is often helpful.  But anyhow, I got
what I wanted in a highly readable format in a small number of seconds
with a couple of taps and swipes.  The browsers are getting better all
the time.

When I raised this as a use case, the defenders of the status quo
essentially suggested that I shouldn't want to use IETF specifications
this way.  I do.

The current format was designed to work well on paper and VT100s.

 -Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Make HTML and PDF more prominent, was: Re: Why the normative

[Tim Bray]

So you would argue that RFCs should normally be used in paper form? This is
the only way I can see to avoid requiring internet access.

This idea seems sane to me. Given the  current policy, the documents are
already not usable on the hundreds of millions of net-capable mobile
devices;  a high quality paper version would avoid making the false promise
that RFCs are "available online".

On Mar 20, 2010 11:18 AM, "Donald Eastlake"  wrote:

On Fri, Mar 19, 2010 at 5:33 PM, Martin Rex  wrote:
>
> ...
>
>
>
>
> And if we should change anything about the Author's Address section,
> then it would be to...
No. I have no problem with *supplementing* it with such a URL but any author
listed on the front page should have an email address, a postal address, and
a telephone number listed in the RFC. The model for an RFC is that of a
permanent book, not an ephemeral web page. I am opposed to the migration of
more of RFC content to links requiring Internet access and perpetual
maintenance.


> ...
>
> -Martin
>

Donald


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Why the normative form of IETF Standards is ASCII

[Tim Bray]

On Thu, Mar 18, 2010 at 12:24 PM, Iljitsch van Beijnum
 wrote:

> If we really want to do something in this space first of all we need to agree 
> on the problem, then on the requirements and THEN we can have a useful 
> discussion. So far the only thing I hear is assertions offered without any 
> foundation that the current format is problematic, while every personal 
> computer operating system sold (or given away for free) the past decade can 
> display it without the need to install additional software.

OK, one more time, let me enumerate the problems with the current
format.  I agree that you may not perceive them as problems, but they
are problems for me:

1. I cannot print them correctly on either Windows or Mac.
2. I cannot view them at all on the mobile device with a highly
competent web browser with which I do an increasing proportion of my
information consumption.
3. I cannot enter the name of an author correctly if that name
includes non-ASCII characters.
4. I cannot provide an actual illustrative working example of the use
of non-ASCII text in Internet Protocols.

I have no problem with people disagreeing on the way forward, but I'm
getting a bit short-tempered when I hear people claim that nobody's
said what the current problems are.

The following are things that I am NOT asking for:
1. Graphics
2. PDF
3. The use of non-English languages in spec text

- Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Why the normative form of IETF Standards is ASCII

[Tim Bray]

On Sun, Mar 14, 2010 at 10:35 AM, Jari Arkko  wrote:

> I don't want to enter a discussion about the merits of PDF/A over HTML at
> this time.

For the record, if the IETF were to entertain the notion of blessing a
format other than legacy-ASCII, I'd be strongly against any form of
PDF.   It seems obvious that a simple constrained dialect of HTML is
maximally portable, accessible, and usable compared to anything else.

 -Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Why the normative form of IETF Standards is ASCII

[Tim Bray]

On Fri, Mar 12, 2010 at 10:43 AM, Martin Rex  wrote:

Martin describes a planet on which nroff formatting semantics are
considered to have current relevance, in which it's hard to look at 4
or 5 HTML documents simultaneously, in which people don't care which
characters are used to write their names, in which worrying about i18n
in protocols is a bad idea, in which people worry about viewing RFCs
on DSL routers but not mobile phones, in which printing HTML "just
doesn't work", in which it takes "fancy gadgets with lots of CPU
horsepower" to render HTML...

I congratulate SAP for their bold vision in extending their operations
beyond the bounds of planet Earth. -Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Why the normative form of IETF Standards is ASCII

[Tim Bray]

On Thu, Mar 11, 2010 at 4:11 PM, Martin Rex  wrote:

> Btw. printing out I-Ds and RFCs on paper (even 2-up and double sided)
> has always been working just fine for me with tools like a2ps.

Just for the record, because I think it's a data point that's relevant
to this discussion: I have never been able to get text-format RFCs to
print properly on either Windows or Mac.  With HTML it always Just
Works with no requirement for tools like anything.

Oh, and it should also be noted that legacy 80-column 66-line ASCII
offers very poor usability on the mobile devices which a large and
increasing number of people, including me, rely on for a high
proportion of information access.  Once again, with HTML there is no
problem.

Because I *enjoy* beating my head against pointy rocks,  -T
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Why the normative form of IETF Standards is ASCII

[Tim Bray]

On Thu, Mar 11, 2010 at 8:54 AM, Martin Rex  wrote:

> The existing plaintext ASCII format is easy and univerval.  Any more
> fancy document formats come with plenty of problems and infinitesimal
> close to zero benefit.

ARRRGGH

... which is the only contribution a relatively sane person can make
to this debate at this point in history.

Oh, except for this data point. I have offered, and now repeat the
offer: At the point the IETF decides to improve the
internationalization, usability, accessibility, and longevity of its
specification format by recognizing some of the progress of the last
thirty years, I will commit to offering some cycles to help with tools
and specs, as appropriate.  I'm sure there are others as well.  -Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Announcing Clouds bar BoF during IETF-77 (March, 2010, Anaheim, CA)

[Tim Bray]

> If you're proposing OGF you should look at the 6 or 7 other SDOs doing
> useful work on clouds, e.g. the DMTF.  It's a complex situation.

I would have said "ridiculous" actually.  So much standards energy, so
little shipping technology. -Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Request for community guidance on issue concerning a future meeting of the IETF

[Tim Bray]

On Mon, Sep 28, 2009 at 6:07 PM, Dave CROCKER  wrote:

> A number of people have indicated that they believe the draft contract
> language is standard, and required by the government.
>
> It occurs to me that we should try to obtain copies of the exact language
> used for meetings by other groups like ours.

I think the exact language is entirely irrelevant.  This is after all
an authoritarian government that historically just doesn't operate in
a rules-based manner.  The language we've seen is extremely vague. De
facto, if a political threat is perceived, a strong unpleasant
reaction is to be expected, and lawyers won't be invited to table to
construe the finer meanings of the rules.  My impression is that it's
highly unlikely that the doings of the IETF will be perceived as
politically threatening, but if I'm wrong on that, an appeal to
section 3.8.7(a) of the agreement is unlikely to be material.

 -T
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Request for community guidance on issue concerning a future meeting of the IETF

[Tim Bray]

On Sun, Sep 20, 2009 at 10:55 AM, Marshall Eubanks  wrote:

>  Politeness and respect towards the Host, yes, of
> course. Censorship of technical discussions, pre or otherwise, no.

Perhaps you'd like to rephrase that.  It is an incontrovertible fact
that there are many people who feel the PRC government is corrupt and
authoritarian, sends its armed forces to shoot down peaceful
protesters, brutally oppresses national minorities, invades some
neighbors and threatens to invade others, kidnaps and locks up people
for expressing their opinions; is essentially barbarous and thus has
forfeited any right to respect from civilized people.  To be fair, you
can find people who have a gripe with any government in the world,
although China's is unusually controversial.  In any case, respect for
any particular governing body really can't be imposed as a
precondition of attending any meeting anywhere.

 -Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [IAB] Request for community guidance on issue concerning a future meeting of the IETF

[Tim Bray]

On Fri, Sep 18, 2009 at 12:29 PM, Henk Uijterwaal  wrote:

> I think it is safe to assume that the government did run some checks
> on what the IETF is doing and, if we did keep ourselves busy with
> things they do not like, then I seriously doubt that they would
> have given the host permission to invite us in the first place.

Um... I really doubt the government of the PRC has much understanding
of the behavior or culture of the IETF.

And the more I think of it, the more I think that even the slightest
hint of a suggestion that the attendees comport themselves in such a
manner as to please the Chinese government is very apt to provoke
deliberate provocations from some members of our community  -Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Request for community guidance on issue concerning a future meeting of the IETF

[Tim Bray]

On Fri, Sep 18, 2009 at 8:42 AM, Marshall Eubanks  wrote:

> The Chinese government has imposed a rule on all conferences held
> since 2008 regarding political speech.

Perhaps more material to this discussion, the government has imposed
severe and wide-ranging restrictions on people's access to the
Internet.  This bites most sharply at the Web/HTTP level.

[Non-rhetorical information-seeking question: Is IRC access unrestricted?]

Thus, operators of a Web-centric conference might have to decide
between declining to go, based on the Web's being restricted to a
crippled subset of itself, or alternatively to use an event there as a
teaching platform as to the benefits of an uncensored Web.

Also, bear in mind that there are a large number of people around the
world who are very angry at the Chinese government, and are looking
for opportunities to stage protests as visibly as possible.  It is not
inconceivable that some of them are IETF attendees and might choose to
try to do this in the IETF context.  The thought of the IETF or hotel
being held liable for what the government perceives as illegal action,
or on the other hand being forced to be a party to trying to prevent
what I'd see as a legitimate protest, are both extremely unattractive.

Finally, it wouldn't be that surprising if there was some amused news
coverage about the IETF meeting in the world capital of Internet
censorship.

 -Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: RFC archival format, was: Re: More liberal draft formatting standards required

[Tim Bray]

On Tue, Jul 7, 2009 at 1:42 PM, John C Klensin wrote:

> I do not believe that we can reach agreement on even the last
> statement.

I am afraid that you may be correct. I am flabbergasted that consensus
on the superior usability of HTML over IETF legacy plain-text (all
other related issues aside) seems unlikely, but apparently there are a
large number whose experience of online information differs
dramatically from the people I hang out with.

> Similarly, some of us believe that a plain ASCII format with
> directly-encoded "hard" line endings is extremely stable as well
> as extremely suitable for direct search and extraction of
> material (e.g., by copy-and-paste operations).

As to copy-and-paste, your statement is probably not a majority
viewpoint.  A high proportion of my copy-and-pastes are either into
something that'll be delivered via browser (the line-ends silently
vanish) or in an email (where they cause unpredictable breakage
depending on the settings of my email authoring and the recipient's
email reading software.

> We draw some comfort from
> the facts that it does not have to be interpreted by programs
> for display,

I really hope you didn't mean what that sentence apparently says. No
file may be displayed without the invention of one or more computer
programs.  I think that what you're saying is that IETF legacy
plain-text displays correctly in a terminal emulator (and incorrectly
in a browser).  This is clearly correct but many of us feel that
correct display in a browser is of higher utility to a greater number
of potential spec users.

 -T
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)

[Tim Bray]

On Mon, Jul 6, 2009 at 12:18 AM, Lars Eggert wrote:

> since you asked: I have absolutely no problems with xml2rfc.
>
> I used to edit in nroff, which wasn't compatible with my brain, and I used
> Joe's Word template, which works OK, but I prefer something ASCII-based for
> collaborative editing (for svn, diff, etc.)
>
> I'm fully open to trying something new once someone creates a different
> ("better") tool, but until then, xml2rfc is OK.

What Lars said. -T
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: RFC archival format, was: Re: More liberal draft formatting standards required

[Tim Bray]

On Sun, Jul 5, 2009 at 9:02 PM, Doug Ewell wrote:
> Tim Bray  wrote:
>
>>  I introduce by example the huge number of mobile
>> devices that handle HTML effortlessly and IETF legacy ASCII not at all.
>>  Also, the large number of standard office printers that print HTML
>> instantly and correctly at the touch of control- or command-P, but can
>> render IETF legacy ASCII on paper only with various gyrations and sidesteps.
>
> I'd still be more confident that the differences between the issues were
> understood if the above text read "IETF legacy plain-text" instead of "IETF
> legacy ASCII."

You're entirely correct, and my poor phrasing is less forgiveable
because I was just giving Melissa a hard time for her assertions about
"ASCII".  Sorry.

>  If we moved from ASCII to UTF-8 tomorrow, but otherwise kept
> the current plain-text format with its lines separated by CRLF and its pages
> separated by FF, and all of the other rigid formatting constraints, the same
> complaints about plain-text versus HTML would exist.

Right.  As many have pointed out here, there are three separate issues here:
1. Usability
1.a Reader usability
1.b Author usability
2. Internationalization
3. Graphics

My argument is that 1.a. and 2. would be dramatically improved by the
introduction of HTML, while 1.b. would not on average change much
across the universe of I-D authors.  And that 3 is a less urgent issue
than 1 and 2.

-Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: RFC archival format, was: Re: More liberal draft formatting standards required

[Tim Bray]

On Sun, Jul 5, 2009 at 9:05 AM, Melinda Shore wrote:

> You're heading into new territory, here.

No, I disagreed with an unqualified assertion you made using the
extremely well-defined term"ASCII".  As others have pointed out,
progress is being impeded by the conflation of a bunch of different
issues, so let's try and be careful about our assertions.

>  Right now
> IETF documents are written in English and they're
> displayable on a wider variety of hardware than HTML
> is.

I don't think that the second part of your assertion is correct.  I'm
not trying to be difficult. I introduce by example the huge number of
mobile devices that handle HTML effortlessly and IETF legacy ASCII not
at all.  Also, the large number of standard office printers that print
HTML instantly and correctly at the touch of control- or command-P,
but can render IETF legacy ASCII on paper only with various gyrations
and sidesteps.

> As I mentioned in the mail to which you're responding,
> I think the choice of formats tends to support more
> openness and accessibility.  I think you're implicitly
> arguing that that's not the right tradeoff, and frankly
> I think it's exactly the right tradeoff, myself.

I think that we're in agreement as to objectives: openness,
accessibility, and usability. My claim is that a carefully considered
and constrained flavor of HTML would meet those objectives better than
IETF legacy ASCII.  I claim that this is true exclusive of whatever
consensus develops around the issues of i18n and the introduction of
graphics.

(There may be a disagreement in that I would tend to place more weight
than some others on the needs of spec consumers compared to those of
producers.)

 -Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: RFC archival format, was: Re: More liberal draft formatting standards required

[Tim Bray]

On Sun, Jul 5, 2009 at 6:27 AM, Melinda Shore wrote:

> Right now ascii text is probably the most widely-supported
> display format.

This statement is violently counter-intuitive and shouldn't be
accepted unsupported by evidence.

- ASCII is not usable for the languages of a large majority of the
world's population.
- For electronic consumption of texts longer than SMS messages, HTML
is the most widely-used display format, probably followed by PDF.
- For print consumption, the use of modern typographic techniques -
real quotation marks, dashes, accented characters if only for usages
like café and coöperate - is generally seen as required, so ASCII is
very seldom used.

ASCII-only is a primitive leftover from the
typographically-impoverished dawn of computing.  Can we get over it
already?  -T
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: RFC archival format, was: Re: More liberal draft formatting standards required

[Tim Bray]

On Thu, Jul 2, 2009 at 2:01 AM, Iljitsch van Beijnum wrote:

> A much better solution would be HTML, if it's sufficiently constrained. HTML
> allows for the reflowing of text, solving issues with text and screen sizes.
> It's also extremely widely implemented, so it's easy to display reasonably
> well without special tools. It also allows for semantic tagging, allowing
> for easy scraping.

This seems obviously true everywhere outside the IETF mailing list.

> Last but not least, just filter out anything between < and > and replace a
> few &xxx; sequences and you're back to plain text. We could probably even
> format RFCs such that if you remove the HTML, you're left with the current
> ASCII format.

Yes and no.  Yes, removing markup leaves useful text, but no, it
wouldn't be anything like the line-broken, paginated,
headered-and-footered, legacy text format.  -Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: More liberal draft formatting standards required

[Tim Bray]

On Sun, Jun 28, 2009 at 10:45 AM, Phillip Hallam-Baker wrote:

> The TXT versions do not print on my printer and have not printed
> reliably on any printer I have ever owned.

Yes, and that history goes back a couple of decades for me.

> I know that some UNIX folk just love to rub the noses of the rest of
> us in this dog poop but it gets tiresome. Just because it works for
> some people does not mean that it is the best way to do things.

Hey, I'm as Unix-y a person as there is, and simultaneously as fierce
a despiser as you can find of 80-character 66-line hard-to-read
impossible-to-print ignores-decades-of-advances-in-publishing-tech
i18n-oblivious ASCIIlicious IETF worst practices.

Another data point, by the way.  I am a major consumer of the Internet
through a mobile device (an Android phone in my case, but whatever).
RFCs are essentially unusable on this device in the legacy text
format, but work fine in xml2rfc-generated HTML.

I think that in the big picture, usability on a mobile device is
several times as important as usability on the hypothetical
ASCII-capable line printer that presumably must have once existed
somewhere.

> The W3C has worked out how to print professional looking standards in
> a format that we can safely assume will be readable for the next
> thousand years at least. We will lose the ability to read bits long
> before we lose the ability to read HTML, or for that matter reverse
> engineer PDF.

Yes, although I wouldn't recommend adopting their publishing system.
Can we please join the current millennium?  I'd be happy to help.

 -Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Abstract on Page 1?

[Tim Bray]

On Wed, Mar 4, 2009 at 7:33 AM, Margaret Wasserman  wrote:
>
> I would like to propose that we re-format Internet-Drafts such that the
> boilerplate (status and copyright) is moved to the back of the draft, and
> the abstract moves up to page 1.

Oh, yes please.  That would immensely increase the usability of RFCs.  -Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Changes needed to Last Call boilerplate

[Tim Bray]

On Thu, Feb 12, 2009 at 3:31 PM, Noel Chiappa wrote:

> I've heard from a number of the FSF thundering herd people to the effect of
> 'but the announcement says send email to ietf@ietf.org". (They're
> conveniently ignoring the fact that it says "the IETF community" all over
> the
> place in the Last Call, but never mind.)
>
> So clearly we need to change it to say something like:


For the record, I strongly oppose this change.  The problem seems neither
very common nor very serious, and the "solution" seems unduly complex and
likely to result in unintended side-effects.  -Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: FWIW: draft-housley-tls-authz-extns-07.txt to Proposed Standard

[Tim Bray]

On Mon, Feb 9, 2009 at 5:50 PM, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:

> FWIW (and it would be good if other actual
> IETF participants care to indicate +1 if they agree):
>
> The actual words in RedPhone's current disclosure:
>
> "RedPhone Security hereby asserts that the techniques for
> sending and receiving authorizations defined in TLS Authorizations
> Extensions (version draft-housley-tls-authz-extns-07.txt) do not
> infringe upon RedPhone Security's intellectual property rights (IPR)..."


I'm wondering why you reproduced this paragraph and omitted the following
six.  This is not a rhetorical question. -Tim


>
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: how to contact the IETF

[Tim Bray]

On Mon, Feb 9, 2009 at 4:07 PM, Noel Chiappa wrote:

>> From: Alex Loret de Mola 
>
>> However, these are people who are upset, and want to make thier
>> opinions known... it is good to know (and see) that so many people are
>> interested and have a strong opinion about this subject.
>
> Give me an effing break. These people have simply been programmed by the
> FSF
> to show up and complain. This is not individuals who have something of
> substance to contribute, it's just a chorus of sheep.


Speaking only for myself, Noel, I find your comment extremely offensive.
 The vast majority of these FSF-solicited comments have been respectful and
polite in tone.  The FSF claims that there is a significant probability that
progressing the current draft could lead to a tollbooth on TLS, which
everyone agrees would be a bad thing.  It seems to me a useful point of
information that there is intense and apparently fairly widely-held concern
on this point.  If the concern (as I certainly hope) is unfounded, the
concern will have been unnecessary.

I also would have preferred if they'd organized a wiki page somewhere and
had a thousand people sign it and send one pointer to i...@ietf.org.  But
really, they are keeping it polite.

  -Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Advice on publishing open standards

[Tim Bray]

On Fri, Nov 28, 2008 at 11:28 AM,  <[EMAIL PROTECTED]> wrote:
> Hi -
>
> There are several issues with Unicode.

Many of the world's standards organizations, including the IETF to
some degree, have more or less outsourced issues of character
definition and specification to Unicode. Were your writing system to
be accepted into Unicode, that would greatly increase the chances that
providers of rendering and display software would look seriously at
shipping implementations.

Of course, you would lose control of the standard (you would retain
the ability to provide input, but you'd lose control). This is a good
thing.

> First, Unicode is written in stone.  Our latest symbol set may be our
> last, but maybe not.  In 2 or 3 years, we may update our symbol set.  This
> would cause problems because Unicode is not allowed to change.

Unicode lets you add but neither delete nor change.  This is a good
thing; such a constraint would be highly beneficial for your users.

> Second, Unicode is used with sequential scripts: one character after
> another. Our script is spatial: the words are characters written in space
> based on coordinates.  The words are sequential, but not the characters.
> Even if we were part of the Unicode standard, I do not believe existing
> applications could properly edit or display the words.

There are lots of scripts in Unicode which act in surprisingly
non-sequential ways given certain character combinations.  The benefit
to finding a way around this problem are huge.

> Right now, we believe the best way forward is to create open standards
> with our own character encoding model.  This CEM will server as an
> excellent reference when/if we become part of the Unicode standard.

I agree with others here that the IETF is ill-suited to host this
work.  If you're hell-bent on going through a standards process, you
might want to look at OASIS, which is has a relatively relaxed and
open process, and is less tightly focused than the IETF.  -Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: placing a dollar value on IETF IP.

[Tim Bray]

On Fri, Oct 24, 2008 at 8:27 AM, TS Glassey <[EMAIL PROTECTED]> wrote:
> Since there is now a specific value estimated by the LINUX community at 1.4B
> for the kernel itself

Hey, I've done an analysis and found that my toenail clippings are
worth $3.8762 billion.  That kernel-valuation exercise is the silliest
kind of science fiction.  Let me let you in on a little secret:
Everything in the world has a value, and that value is exactly what
people are prepared to pay for it.  No more, no less.

On payment of a generous consulting fee, I would be delighted to
"estimate a specific value" for any given RFC or even I-D.  I'll even
issue gold-framed certificates you can mount on the wall.  -Tim

> , the IETF can no longer hide its head in the sand
> claiming that its workproduct has no specific value. This also means that
> ANY AND ALL contributions to the IETF no matter when they happened now need
> to be formally acknowledged for their financial value at the time of their
> contribution.
>
> This is not an OPTION.
>
> Todd Glassey
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Publishing RFCs in PDF Formal

[Tim Bray]

On Wed, Aug 27, 2008 at 9:53 AM, Julian Reschke <[EMAIL PROTECTED]> wrote:

>> I'm not saying [X]HTML RFCs are an inherently bad idea, just that
>> they're not as simple to get right as it might seem.
>
> That's true, but I would expect *less* discussions as compared to just
> using PDF (for everything).

Agreed on all points.  For those of us who spend any significant
amount of time working with RFCs on-screen, it seems like a minimal,
clean, HTML presentation has been the best available technology for
about a decade now.  -Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

I18n of I-Ds (was Simpler than...)

[Tim Bray]

On Mon, Aug 25, 2008 at 4:23 PM, John C Klensin <[EMAIL PROTECTED]> wrote:

> I see some fairly significant problems with most of the "RFCs in
> UTF-8" or equivalent proposals I have seen, many of them having
> to do with environments in which UTF-8 is not as ubiquitous as
> one might like to believe.

I actually haven't seen any concrete proposals in the admittedly-brief
(5-year) time I've been reading this list.  Which actually supports
your second point, I believe:

>   But I don't any point in trying to
> discuss or critique such proposals until there is one... and
> "proposal" in the IETF continues to mean "write an I-D", not
> "sketch an idea on a mailing list" or "express outrage that
> something isn't possible/ permitted".

OK, then.  Maybe I'm weird, but I've developed quite a bit of
affection and respect for the IETF and this ASCII-only policy seems to
me a major problem in the context of the the Internet in 2008.   On
the occasions I've brought the idea of doing something about this in
up conversation, the conversational reaction has been along the lines
of "Ha-ha, Unicode is imperfect and i18n is a bikeshed, get lost."

So, WTF, I'll go draft something and float it.  So at least when I
complain about this (which I seem unable to avoid doing) there'll be a
specific proposal for the IETF to sneer at.

 -T
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Simpler than draft-rfc-image-files-00.txt

[Tim Bray]

>Documents in the RFC series normally use only plain-text ASCII
>characters and a fixed-width font.  However, there is sometimes a
>need to supplement the ASCII text with graphics or picture images.

Pardon my reverse-parochialism, but I think the need to be able to
spell editors' and contributors' names correctly, and give examples of
messages containing payloads which are not expressible in 7-bit
characters, dwarfs in importance the need to decorate RFCs with
pictures.  -Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: New schemes vs recycling "http:" (Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08)

[Tim Bray]

On Thu, Aug 7, 2008 at 4:47 PM, Keith Moore <[EMAIL PROTECTED]> wrote:

> That's ridiculous.
>
> First of all it's not as if HTTP is an optimal or even particularly
> efficient way of accessing all kinds of resources - so you want to
> permit URI schemes for as many protocols as can use them.

Well, it's not as if the presence of the "http:" scheme requires you
to use the protocol, and in fact a very high proportion of all
accesses to such resources go sideways through various caching schemes
and so on.   The notion that the scheme implies the protocol is a
common and very old misconception.

>  But it's silly to say that existing URI schemes are sufficient for all
> purposes.

Nobody has ever said such a thing.  I and others have repeatedly
argued that one or another specific proposal for a new URI scheme has
a lousy cost-benefit ratio.  That is the totality of this debate.  -T
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: New schemes vs recycling "http:" (Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08)

[Tim Bray]

On Thu, Aug 7, 2008 at 3:55 PM, Lisa Dusseault <[EMAIL PROTECTED]> wrote:

>> Right, but there's a contradiction lurking here.  You probably
>> wouldn't bother to use URI syntax unless you expected fairly wide
>> utilization, or to benefit from the plethora of existing URI-parsing
>> and -resolving software.  The notion of wanting to use URI syntax but
>> simultaneously requiring a new scheme is often a symptom of fuzzy
>> thinking.
>
> Don't browser and OS libraries dispatch on URI scheme?  I guess it's
> probably not as easy to extend as adding a new handler for a new
> Content-Type, but it's at least possible for a new URI scheme to start
> appearing (in email, Web pages, local docs, etc)  and for the user to
> install an application which registers

Well, yeah, but a lot of the infrastructure is deployed on dumb
devices and, more important, if you stick to existing URI schemes and
use them properly, it All Just Works.

I know it seems like Those Web Guys Hate URI Schemes, and I get tired
of quoting http://www.w3.org/TR/webarch/#URI-scheme at people, and I
admit being prejudiced by the fact that a high proportion of
new-uri-scheme proposals have historically been poorly-considered (not
all, see RFC4151).  But there's no getting around it: the cost of new
schemes is very high, if you want to be part of the Web.

  -Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: New schemes vs recycling "http:" (Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08)

[Tim Bray]

On Thu, Aug 7, 2008 at 10:23 AM, Keith Moore <[EMAIL PROTECTED]> wrote:

>> The TAG is in fact clearly correct when they state that introduction
>> of new URI schemes is quite expensive.
>
> To me it seems that this depends on the extent to which those new URI
> schemes are to be used in contexts where existing URI schemes are used.  New
> URI schemes used in new contexts or applications are not overly burdensome.

Right, but there's a contradiction lurking here.  You probably
wouldn't bother to use URI syntax unless you expected fairly wide
utilization, or to benefit from the plethora of existing URI-parsing
and -resolving software.  The notion of wanting to use URI syntax but
simultaneously requiring a new scheme is often a symptom of fuzzy
thinking.

And in the specific case of XRI, which seems designed as an extremely
general-purpose thing, the cost is clearly very high, so the benefits
need to be compelling.

> It should also be recognized that overloading URI schemes (as well as
> overloading HTTP) is also expensive, though in a different way.  The
> consequence of overloading is that functionality is reduced and
> interoperability suffers.

Got an example?  I'm having trouble thinking of any problems I've run
across that could be ascribed to this.  -Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: New schemes vs recycling "http:" (Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08)

[Tim Bray]

On Thu, Aug 7, 2008 at 1:56 AM, Harald Alvestrand <[EMAIL PROTECTED]> wrote:

>> Well. There's definitively a total disconnect between that IESG
>> recommendation, and the W3C TAG's point of view (see ongoing discussion on
>> the TAG mailing list about the "xri" scheme).

That discussion is just too long and gnarly to summarize, but without
touching on any of the actual technical issues:

There is a strong perception among quite a few people, notably
including the TAG, that the XRI people don't understand the
technologies they're trying to replace; many of their statements
beginning "XRI is needed because..." have been challenged as being
simply technically wrong.

The TAG is in fact clearly correct when they state that introduction
of new URI schemes is quite expensive.  So it comes down to a matter
of cost/benefit, and a lot of people are not convinced that a real
benefit has been established for XRI, relative to the existing Web.

>> If a new URI scheme is defined, it needs to state what it identifies, and
>> how it is resolved. If it identifies an HTTP resource, and resolution is
>> done via HTTP, then it seems to me you don't need it.

Actually, no.  There are lots of identifiers that do not have a
"resolution" requirement.

> Certain usages of HTTP (in particular, the use of HTTP URLs for XML schemas)
> have tended to denigrate this implication, and say "you should regard this
> as an identifier". Still, the usage is prevalent enough that people have
> complained that servers identified in popular XML schemas are getting hit
> with enough extra traffic to cause operational problems.

This has happened, usually due to clueless implementors.  The most
famous case is the DTD URIs appearing in the HTML , which
certain developers who will remain nameless tried to retrieve every
time they parsed an HTML page.  Surprise surprise, it didn't work.

It's a real risk.  Any identifier that can be used to retrieve
something will so be used, whether that's appropriate or not, and
that's a risk we have to work into our plans.

 -Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-snell-atompub-bidi (Atom Bidirectional Attribute) to Experimental RFC

[Tim Bray]

On Fri, Apr 11, 2008 at 12:03 PM, The IESG <[EMAIL PROTECTED]> wrote:
> The IESG has received a request from an individual submitter to consider
>  the following document:
>
>  - 'Atom Bidirectional Attribute '
> as an Experimental RFC

The name of this draft is a little misleading.  Shouldn't it be
"atom-bidi" not "atompub-bidi"?  It doesn't have anything to do with
the protocol, which is what atompub stands for in most people's minds.
-Tim
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Call for Comments: What Makes For a Successful Protocol?

[Tim Bray]

On Wed, Mar 26, 2008 at 10:11 AM, IAB Chair <[EMAIL PROTECTED]> wrote:
>What Makes For a Successful Protocol?
>draft-iab-protocol-success-03
>
>  as an informational RFC.Before doing so the IAB wants to solicit from
>  the community any last comments on this document.
...
>  The document can be found at:
>  http://www.ietf.org/internet-drafts/draft-iab-protocol-success-03.txt

The first illustration in section 1.2.1 is misleading.  The narrative
about the success of HTTP is correct, but the selection of "VPN" and
"Firewall traversal" for inclusion is troubling.  To start with, I
don't see why VPN is included at all, and there's no explanatory text.
 Second, it seems to me that perhaps the most interesting/important
success for HTTP outside its original design space is in software
integration in general and "Web Services" in particular.  As for
firewall traversal... while accurate, this is not something that the
IETF is very comfortable with.

A.1.1 "HTML encumbrance only surfaced later".  What HTML encumbrance?
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-duerst-iana-namespace-00.txt

[Tim Bray]

On Sun, Mar 2, 2008 at 3:23 PM, Ned Freed <[EMAIL PROTECTED]> wrote:
>  > Contrary to that, XML processors do not resolve namespace URIs, they are
>  > purely used as identifiers.
>
>  That's certainly how things are supposed to work. It may or may not be how 
> they
>  actually work.

I agree with Ned that the Security considerations or some other piece
of the doc should explicitly cover this issue.  -Tim
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)

[Tim Bray]

On 5/18/07, Robert Sayre <[EMAIL PROTECTED]> wrote:

I think the substituted text is inadequate, because it is not clear
which TLS version implementors MUST support. As I understand it, the
fact that it is "tricky", implying there may be trade-offs, is not
sufficient to avoid specifying a single, mandatory-to-implement TLS
version.


Well Rob, I think the community at large and the IESG in particular
would welcome suggestions on what to do with this one.  In fact, we
know what's going to happen: implementors will use the default TLS
library for whatever platform they're on, and this will do the job,
most times.  However, I think that we have better-than-rough consensus
that the specification landscape is a mess, making normative
references  a bitch, and that this will probably bite nearly
everything in the Apps area from here on in.

I hope someone with the necessary expertise will take this bull by the
horns.  -Tim

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Prague

[Tim Bray]

I haven't been following this discussion closely, but in case nobody
else has made the point: the bad news is that the Prague taxi-driver
community is (in my personal experience)  crooked, while on the other
hand Prague public transit is quite efficient.  Last time I was there
I arrived late and paid some taxidriver/pirate a huge sum to get me to
my hotel; I was flying out at a civilized time and figured out how to
take the tram+train combo to get me to the airport at approximately
1/50 of the cost. Also the people on public transit are more
interesting. -Tim

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Protest: Complexity running rampant

[Tim Bray]

On 2/19/07, John C Klensin <[EMAIL PROTECTED]> wrote:


For the record, I would have no problems with Informational or
Experimental publication of this collection -- it is the
proposed decision to standardize that bothers me.


Exactly.   Under no circumstances should it ever be OK to use IETF
reputational leverage to pressure someone to use something as (to be
charitable) unproven as this.

-Tim

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-wilde-text-fragment (URI Fragment Identifiers for the text/plain Media Type) to Proposed Standard

[Tim Bray]

On 2/14/07, The IESG <[EMAIL PROTECTED]> wrote:

The IESG has received a request from an individual submitter to consider
the following document:

- 'URI Fragment Identifiers for the text/plain Media Type '
as a Proposed Standard


Editorial point:

Section 2.2.1 says "Character position counting starts with 0, so the
character position
  before the first character of a text/plain MIME entity has the
  character position 0"

but the example in section 5 says "http://example.com/text.txt#char=100

  This URI identifies the position after the 100th character of the
  text.txt MIME entity."

If "character counting starts at 0" I take it that the initial
character is the 0th character, thus char=100 is before not after the
100th, right?  In fact the spec is perfectly correct according to the
normal meaning of "100th" but it took me a minute to get that, and I
suspect a little clean-up in the example description would be useful.

Substantive point:

Each of the addressing schemes is easy to understand, but the ways
they combine are hard to explain and understand, and I'm unconvinced
that being able to identify things like

  This URI identifies the first line and all occurrences of the regular
  expression 'searchterm' in the MIME entity.

are worth the effort.  I'd strongly recommend simplifying the spec by
allowing only one scheme, which might turn out to hit a very desirable
80/20 point.

 -Tim

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: +1

[Tim Bray]

On Jul 15, 2006, at 4:13 AM, Michael Thomas wrote:

Is it just in my part of the ietf woods, or is this becoming a  
widespread

phenomenon? If so, is this a good thing or a bad thing?


Over in Atompub, this has become the normal idiom for reacting to  
proposals, with common usages such as +/- 0 and 0.5.   We even use it  
to do WG surveys when there are multiple apparently-plausible options  
on the table.  "Rough consensus" may occasionally be deduced from the  
presence of quite a few +1's and almost no -1's.  It seems to work OK.


For example, "-0" is an awful lot fewer bytes than "I don't like  
that, but I won't lie down in the road over it".


Obviously, everyone multiples the numeric quantity by their own  
estimate of the credibility of the person uttering it.


 -Tim




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: are we willing to do change how we do discussions in IETF? (was: moving from hosts to sponsors)

[Tim Bray]

On Jun 24, 2006, at 8:55 AM, Keith Moore wrote:

That's not quite sufficient, because most WGs aren't proceeding  
according to good engineering discipline (e.g. they're doing things  
in the wrong order, like trying to define the protocol before the  
problem space is understood)


I'd generalize that.  I have never seen *any* standards org do a good  
job of inventing new technology.  I've been working with the soon-to- 
wind-down Atompub group for a couple of years and we got a pretty  
good result I think (if you can judge by implementations &  
deployments).  There were a few things in our favor - a high level of  
interest and energy, lots of experience on the WG, decent editors -  
but the key thing was there was a ton of hands-on experience in the  
space (syndication technology).  A whole lot of the key arguments  
could be resolved by appeal to example and experience.


When standards orgs go out to invent stuff in unexplored territory  
you get disasters like OSI networking, CORBA, and in the current  
landscape, WS-*.  I suppose there are exceptions but I don't know of  
any.


 -Tim

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Propose d Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))

[Tim Bray]

On Jun 20, 2006, at 11:02 AM, Bob Braden wrote:

  *> Quite true. But as long as the RFC Editor finds it necessary  
to use a
  *> multi-stage process to produce RFCs with hand tweaking of the  
output at
  *> different stages, I doubt that they will be willing to do this  
because the
  *> input document will not in fact reproduce what's in the RFC.  
This is why tool
  *> improvement to eliminate the need for hand tweaking is so  
important. But
  *> in the meantime, I would hope the RFC Editor would be willing  
to hand back
  *> the xml2rfc source to the author. It's a stopgap, but a useful  
stopgap.


We are willing to do so, and have been doing so. You just have to ask.


Yes, but what you get back doesn't correspond to the RFC, because of  
the downstream edits.  A volunteer just went through a fairly  
laborious process to reconstruct the XML version of RFC4287 so that  
an HTML version could be made available  (Yes, I know only the ASCII  
version is normative).  To me it seems that this work should not be  
necessary.-Tim




In the current process we have to include a disclaimer that the final
AUTH48 corrections and formatting niceties may not be included in the
XML source we give back.  However, it is still useful as a starting
point for later documents.  Note that this is potentially a little
dangerous, though, because people might start archiving the
almost-correct XML and later regenerate an almost-correct copy of the
document.

  *>
  *> I don't know what needs to be done to make xml2rfc better, but  
I sure wish the
  *> RFC Editor would spend whatever time it takes with the folks  
who work on

  *> xml2rfc to accomplish this.

As we have announced at several plenary reports (does anyone ever pay
attention??), the RFC Editor has been trying to work with the xml2rfc
fraternity to make xml2rfc into an effective document formatting tool.
It has not been quick or easy.  I just checked with one of our  
editors,

Alice Hagens, who uses xml2rfc regularly.  She tells me that she
entered several issues into the xml2rfc tracker, but she does not  
think

"anyone is looking at it any more."  There is unfortunately a
fundamental disconnect: philosophically, the xml2rfc folks don't WANT
it to be an effective markup language, which is essentially what is
needed.

Bob Braden

  *>
  *> >In addition to giving us some concrete evidence of how
  *> > many RFCs use each source format, it would greatly simplify
  *> > the process of writing new drafts...
  *>
  *> Sure - a central repository makes it easy for anyone to come  
along and produce
  *> a document revision. Depending on authors preserving input  
sources is not

  *> nearly as flexible.
  *>
  *> Ned
  *>
  *> ___
  *> Ietf mailing list
  *> Ietf@ietf.org
  *> https://www1.ietf.org/mailman/listinfo/ietf
  *>

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Propose d Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))

[Tim Bray]

On Jun 20, 2006, at 12:25 PM, Carl Malamud wrote:

May I make a suggestion to both the office of the RFC Editor and to  
the

IESG?  This sounds like a classic case for leadership.  How about
starting up a working group?  Give it a capable chair, support from
the AD (Brian), and twist some arms


I'd find some cycles for such a project.  -Tim


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Tim Bray]

On Jun 19, 2006, at 7:05 PM, Anthony G. Atkielski wrote:


It's true that Unicode font support is somewhat spotty.


It's worse than spotty; it is quite poor.


It's pretty good on modern Mac & Windows boxes.   When I go to a page  
in Devanagari or Chinese or Russian, it usually displays OK.   -Tim



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Formatin AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Tim Bray]

On Jun 16, 2006, at 3:46 PM, Joe Touch wrote:


Forcing the input format means one of two things:

- edit source code (argh - back to the stone age)


I think we would generally get better results if Internet Standards  
were authored by people who are comfortable editing source code.



- force a limited set of editing software


That's a fair complaint.

But for what it's worth, professional reference publishing  
organizations, who care a whole lot about the longevity and re- 
usability of the material they create, generally do standardize on  
the editable input format, and assume there will be a variety of  
output formats generated to meet consumer needs, which change from  
place to place and time to time.  -Tim



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin

[Tim Bray]

On Jan 18, 2006, at 4:34 AM, Scott Hollenbeck wrote:

The IESG plans to make a decision in the next few weeks, and  
solicits final
comments on this action.  Please send any comments to the  
iesg@ietf.org or

ietf@ietf.org mailing lists by 17 February 2006.


Ban him.  Openness and inclusiveness are virtues, but not absolutes.  
This ban seems to me an expression of respect for the time and energy  
of many dedicated and talented participants here, which are currently  
being wasted by JFC; such respect is also a virtue and on balance in  
this case, a substantially greater one. -Tim




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Troubles with UTF-8

[Tim Bray]

On Dec 28, 2005, at 5:05 AM, Masataka Ohta wrote:


That problem is that Unicode is stateful with complex and
indefinitely long term states


Has this ever caused a real problem to a real programmer in real life?

I have written a whole bunch of mission-critical code that reads and  
generates UTF-8, and any correct implementation will have to deal  
with the fact that there is no necessary connection between the  
number of glyphs on the screen and bytes in its encoding.  It would  
be perfectly reasonable for an implementation to declare a  
limitation, for example that it will not process than 32 trailing  
modifiers on any character, and this would not cause problems in  
production because sequences of such a length do not occur in the  
encoding of any known text.


Which is to say, Ohta's statement about statefulness is true, but the  
conclusion that this is a "problem" is erroneous. -Tim




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Troubles with UTF-8

[Tim Bray]

On Dec 28, 2005, at 12:46 PM, Randy Presuhn wrote:

Reserving NUL as a special terminator is a C library-ism.  I think  
that

history has shown that the use of this kind of mechanism, rather than
explicitly tracking the string's length, was a mistake.


I used to think so too, but I don't any more; twenty years of doing  
text processing has convinced me that C's null-terminated strings  
simply cannot be improved on in a low-level programming language.   
For more on the subject see http://www.tbray.org/ongoing/When/200x/ 
2003/04/13/Strings  -Tim



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Troubles with UTF-8

[Tim Bray]

On Dec 28, 2005, at 7:16 AM, Julian Reschke wrote:

The 'illegal syntax' is not yet an RFC but is in draft-ietf- 
netconf-ssh-05.txt

which says
   "As the previous example illustrates, a special character  
sequence,
]]>]]>, MUST be sent by both the client and the server after  
each XML


Why don't you use an illegal *character* instead, such as Formfeed?  
That's certainly easier to parse...


Or NULL, U+, which is illegal in XML. -Tim


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Troubles with UTF-8

[Tim Bray]

I agree with everything Ned said, this is a non-problem.

On Dec 23, 2005, at 10:13 AM, Ned Freed wrote:


(Unicode
lacks a no-op, a meaningless octet, one that could be added or  
removed without

causing any change to the meaning of the text).


NBSP is used for this purpose.


I think actually U+FEFF ZERO WIDTH NO-BREAK SPACE is appropriate in  
many situations.  Yes, I know it's also a BOM.


The reason many of our standards documents refer to ISO 10646 is  
that at one
time there was concern that Unicode wasn't sufficiently stable, and  
it was felt

that reference to the ISO document would offer some protection against
capricious change. I think in retrospect this concern has been  
shown to be
unwarranted, and all things being equal I would prefer to see  
references to the
more readily available Unicode materials. (Given the wide  
deployment of Unicode
now there is effectively no chance of a major change along the  
lines of the

Hangul reshuffle between V1 and V2.)


Yes.  It's intellectually satisfying that 10646 still exists, but for  
al practical purposes, Unicode is plenty stable enough, and widely  
accessible.  -Tim


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Examples of translated RFCs

[Tim Bray]

On Dec 6, 2005, at 10:56 PM, Masataka Ohta wrote:


You should admit that ISO 10646 useless for internationalization.


Hogwash.

Which is to say, for the benefit of those who have not had to  
internalize the complicated world of standardization and  
internationalization: Mr. Ohta's point of view represents the  
position of a tiny minority; huge swathes of widely-deployed  
standards and technology rely totally on 10646/Unicode, and they tend  
to work well, and they tend to deliver high-quality experiences to  
their users, including Japanese users. -Tim


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: I-D file formats and internationalization

[Tim Bray]

On Dec 1, 2005, at 3:16 PM, Keith Moore wrote:


 the
the ability to read and print UTF-8 in the field is still  
significantly

worse than the ability to read and print ASCII.


That assertion could use a little empirical backing.  Empirically,  
there are people who find the ASCII versions easier to deal with; you  
are one.  Empirically, there are those who simply do not observe  
problems with UTF-8; I am one.  I could say "There are more like me  
than like you" and while I suspect that is correct, I have no  
evidence to back it up, so I won't assert it.  I will state with some  
confidence however that the group of people in your position is  
shrinking, while that in mine is growing.


And I will freely admit that I find the notion that a group of people  
designing global infrastructure think it's OK to use ASCII so morally  
and and aesthetically offensive that it probably interferes with my  
evaluation of the trade-offs.


I will now shut up.  It is clearly the case that there is tremendous  
resistance within the IETF to leaving their comfy ASCII enclave.  -Tim




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: I-D file formats and internationalization

[Tim Bray]

On Dec 1, 2005, at 12:16 PM, Keith Moore wrote:


Also, the vast majority of printers in use don't natively support
printing of utf-8, thus forcing users to layer each of their computer
systems with more and more buggy cruft just to do simple tasks like
printing plain text.  Perhaps those are buggy also?


Uh, I print UTF-8 documents all the time.  Normally I do it from the  
app in which I'm viewing them (word processor, web browser, RSS  
reader, xml editor, whatever).



These days, your best bet for getting utf-8 files to print is to use a
web browser's print command, which is doable but can be fairly
cumbersome as compared to typing a simple "lpr" command.


Hmm; control-P, enter.


Unfortunately,
most web browsers fail to preserve page breaks (FF characters) when
printing flat text files, which makes the resulting documents hard to
read.


Turn this around; when printing HTML, the browser inserts appropriate  
page breaks depending on the combination of font, styling, and paper  
size that's in effect.  This has the effect that when you're arguing  
about some text, you have to say "Look at 5.2.1.3, 2nd para" rather  
than "Look at page 13, 2nd para".  It's not clear that this is any  
better or worse.



HTML with utf-8 actually displays and prints more portably than plain
text with utf-8, though it's not clear how many browsers support the
style sheet extensions enough to print page breaks in the right
places.


Given the above, I agree with the first half of the sentence.  In  
fact, I am sitting behind a desk on which there's a macintosh and an  
Ubuntu linux box, and I wouldn't really know how to print plain-ASCII  
text on either of them, and when I've tried, the page breaks usually  
come out wrong.  On either of them, I can and do print HTML  
effortlessly and with excellent results.



  Also, HTML is still somewhat of a moving target and it is
somewhat unclear whether any particular subset of HTML that is used
today will still be effectively presented 10-20 years from now.


I think it is crystal clear that if you stick to HTML4 Strict or  
Transitional, that has an excellent chance of survival at least for  
decades.



  The
biggest problems with HTML are (a) no way to include images in the
document without external links (yes I know about MHTML but it's  
not as

widely supported); (b) difficulty in finding authoring tools that will
produce output in a subset of HTML that we define; (c) avoiding
the temptation to make the documents pretty rather than readable.


I grant problem (a).  (b) and (c) can be solved using automated tools  
and compulsory stylesheets (or by using xml2rfc).



It's hard to escape the conclusion that we're trying very hard to make
our document processing much more complex for a very marginal gain.


There are two large populations for whom the gain is not "marginal".

1. Those, like me, who can't print ASCII files easily
2. Those whose names can't be spelled properly in ASCII.

I claim that both those groups either already do, or will soon,  
constitute large majorities of the interested population. -Tim



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: I-D file formats and internationalization

[Tim Bray]

On Nov 30, 2005, at 2:54 PM, Frank Ellermann wrote:


As Bob said raw UTF-8
characters won't fly with `cat rfc4567 > /dev/lpt1` and other
simple uses of RFCs.


1. I wonder what proportion of the population prints things this way?
2. If the file is correctly encoded in UTF-8 and the above doesn't  
work, then your operating system is buggy.  I print stuff with non- 
ASCII characters all the time on Linux, Windows, and Macintosh  
computers.  Granted, I don't use "cat > /dev/anything" to do it.


 -Tim


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: ASCII art

[Tim Bray]

On Nov 21, 2005, at 7:05 AM, Paul Hoffman wrote:

As others have pointed out on this thread, the ASCII art in IETF  
specs is (or should be) optional to implementers. The corollary is:  
why bother to go to a format that uses something other than ASCII  
art, if it is an optional component? Other than prettiness, what is  
the advantage for our intended audience of protocol developers?


The advantage is that you can correctly represent words which come  
from languages other than English.


In terms of accessibility, I advance the hypothesis that validated  
html-strict or even html-transitional is at this point in history  
*more* generally accessible than ASCII.  I call it a hypothesis  
because I can't off the top of my head think of an experiment to  
validate/falsify it. -Tim



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: [dnsop] [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

[Tim Bray]

On Sep 24, 2005, at 8:28 PM, Dean Anderson wrote:


None of my emails have been abusive.


Speaking as a 99.% passive observer around here, I consider  
Dean Anderson's emails, in aggregate, abusive. They consume precious  
mental bandwidth, in many cases with no material technical content,  
and thus make it more difficult for me (and I assume many others) to  
follow the flow of IETF discussion.


Strictly a personal opinion.  -Tim


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: BitTorrentvs MBONE

[Tim Bray]

On Sep 15, 2005, at 7:34 PM, Hallam-Baker, Phillip wrote:


Sure bittorrent is probably not great design by many standards.


For the record, I think bittorrent is a superb design, especially  
when seen as a first cut.  It will improve. -Tim



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Unicode points

[Tim Bray]

On Feb 24, 2005, at 2:53 PM, Bruce Lilly wrote:
o 16-bit Unicode matched well with 16-bit wchar_t
wchar_t is 32 bits on all the computers near me.  This is one reason 
why UTF-16 is irritating for the C programmer.

o while the raw data size doubles in going from 16 bits per character
  to 32 bits, the size of tables (normalization, etc.) indexed by
  character increases by more than 4 orders of magnitude. [yes,
  table compression can be used -- provided the locations and sizes
  of "holes" is guaranteed -- but that requires additional
  computational power]
Unicode data is usually persisted as either UTF-8 or UTF-16, so the 
fact that 21 bits are potentially available is irrelevant to the space 
actually occupied.  For everyday in-memory character processing, 
consensus is building around UTF8 (in C/C++ land) and UTF16 (in Java/C# 
land).  I expect wchar_t to be become increasingly irrelevant.

It would be convenient if you could use 64k bitmaps to define character 
classes, but you can't, so naive implementations are simply not 
suitable.

My experience since 1996 is that the Unicode people are neither 
capricious nor malicious.  I gather yours is different. -Tim

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: draft-farrel-rtg-morality-requirements-00.txt

[Tim Bray]

On Nov 16, 2004, at 3:57 PM, Bob Hinden wrote:
We should be proactive and create a morality area in the IETF.  The 
morality ADs can review and vote Discuss if the Morality 
Considerations section in drafts being reviewed by the IESG is not 
adequate.
I would volunteer for such a job, bearing in mind that the Morality ADs 
would need to conduct intensive and detailed research on *im*morality 
to provide the necessary background context, involving extended 
excursions to New Orleans, Las Vegas, and Vladivostok.  -Tim

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

Re: Air condition ...

[Tim Bray]

On Nov 12, 2004, at 7:51 AM, JORDI PALET MARTINEZ wrote:
Believe me, I know the difference between a big rat and a squirrel
Everybody knows there are lots of rats in Washington, as in any capital 
city. -T

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

Re: Shuffle those deck chairs!

[Tim Bray]

On Oct 21, 2004, at 7:59 AM, Eric S. Raymond wrote:
Brian E Carpenter <[EMAIL PROTECTED]>:
I don't think we can require the IESG to negotiate anything. There are
all kinds of legal issues there. To my knowledge, both WGs and the 
IESG
do think carefully about this, but often conclude that the default 
IETF
conditions (RAND) are realistic and acceptable.
If IETF continues to believe this, groups like Apache and Debian will 
continue
to have to end-run IETF
I'm with ESR on this one.  The W3C bit the bullet and built a 
patent/IPR policy that has integrity and is based on the notion that 
the Net works properly when important components can be built by 
un-funded independents without worrying about getting their asses sued 
by someone with a patent portfolio.  If the IETF wants to ignore 
history and build an Internet where that doesn't hold, feel free, but 
it's not a very interesting kind of place.  -Tim


smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Shuffle those deck chairs!

[Tim Bray]

On Oct 19, 2004, at 10:49 PM, Paul Vixie wrote:
i think that the ensuing ietf-isoc-malamud hairball should pay for IPR
searches of all final-drafts
In my experience, such searches, to be of any use, require the services 
of an intelligent (i.e. expensive) person, ideally with domain 
expertise, are quite time-consuming, and produce lots of false 
negatives.  Also, an attorney should be consulted about the possible 
legal consequences; there are scenarios where one is better off not 
knowing of the existence of a patent whose owner might think you're 
infringing.

Having said that, if the org can afford the money and the process can 
afford the time and the legal risk is acceptable, this would be an 
excellent thing to do. -Tim


smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'The APPLICATION/MBOX Media-Type' to Proposed Standard

[Tim Bray]

On Aug 10, 2004, at 4:19 AM, Ian Jackson wrote:
The IESG writes ("Last Call: 'The APPLICATION/MBOX Media-Type' to 
Proposed Standard "):
 * Since mbox files are text files (assuming that any binary messages
   in the mailbox are themselves encoded) and can be read sensibly
   with the naked eye, the content type should be text/* not
   application/*.  This will also remove ambiguity surrounding line
   endings.
I'm not very close to this problem, but I'd like to point out that 
using text/anything gets you into i18n issues... if the server has 
trouble getting the charset= right and doesn't provide it, then the 
rules say the client MUST assume US-ASCII, which in a high proportion 
of cases is going to be wrong; and by the way the client is forbidden 
to use any other heuristics to figure out what the encoding might be.  
text/* also blesses intermediate transcoders which can create all sorts 
of problems.

Maybe these issues don't apply to mbox data, in which case feel free to 
ignore me -Tim


smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Multicast doesn't work

[Tim Bray]

The OS X version doesn't work if you have NeoOffice/J installed, 
because it Neo thinks it owns one of the extensions (sdp or something).

So I went to a totally vanilla patched up to date Win/XP box with an 
up-to-date Quicktime and Quicktime refused to handle .QT.esm files, so 
I downloaded the ESM .exe files, not that there's any indication of 
what to do with them, and they didn't do anything either.

So I won't be watching the multicast. -Tim

smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF60: time needed for check-in at San Diego?

[Tim Bray]

On Jul 21, 2004, at 2:48 PM, Iljitsch van Beijnum wrote:
What is Canada like in this regard? Seems to me this would be a 
perfect compromise for the North American meetings: reasonable 
distance for the US attendees, reasonable treatment of foreign 
nationals for everyone else (AFAIK).
I noted to Harald off-line that I think Canada would be an attractive 
choice for IETF meetings.  The tourism/conference biz is important to 
us, we're quite a bit cheaper than the U.S., and the border officials 
quite a bit softer-edged.  (To be fair to the U.S., we're also on fewer 
terrorist hit-lists).  I would think for something with the IETF's 
prestige, we might even be able to arrange a friendly nod from the 
Canadian feds, particularly if they could get a little marketing 
mileage out of the deal.

-Tim (writing from Vancouver, Canada)


smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf