Re: Getting to Quebec City

[Glen Zorn]

On 6/18/2011 8:31 AM, Andrew Sullivan wrote:
> On Sat, Jun 18, 2011 at 12:08:52AM -, John Levine wrote:
> 
>> By train: there are four trains a day from Montreal to Quebec.
>> Although there is a train station in Dorval, close to the airport, it
>> doesn't have any through trains to Quebec so it's easier to go
>> downtown.
> 
> Note that if you plan to use Via Rail, you should treat the train
> timetables as rough guidelines rather than something on which to rely.
> The train usually does not run exactly on time, although the
> timetables might be close enough for IETF arrival purposes.  But
> worse, there are occasional equipment failures that make things fail
> in big ways.  Via runs on tracks shared with (and owned by) the
> freight lines, so if Via has an equipment failure that causes them a
> delay, they can miss a window completely.  I have arrived over 4 hours
> late on a trip that should not have taken 4 hours total.

Sounds like air travel in China ;-)

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

Re: Getting to Quebec City

[Glen Zorn]

On 6/18/2011 7:08 AM, John Levine wrote:

> As you may have noticed, flying to Quebec City (YQB) is incredibly
> expensive.  

Hmm.  My ticket to QC was only ~$40 CAD > than the equivalent one to
Montreal, far less than R/T bus or train fare...

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

Re: Getting to Quebec City

[Hamza GHARSALLAH]

Perhaps, the real surface is becoming smaller and smaller due to green house
effect! I wonder if Eye Pi Vee Six is greener!

On Sat, Jun 18, 2011 at 1:50 AM, Melinda Shore wrote:

> On 06/17/2011 04:32 PM, Eric Rescorla wrote:
>
>> Quebec:   Land area=1,365,128 km2   Water Area=176,928 km2
>> Alaska:  Land Area: 1,481,347 km2  Water Area=236,507 km2
>> Perhaps you meant Continental US.
>>
>
> Until recently if you tried to sign up for Google Voice
> from Alaska you were informed that the service is not
> available in your country.  People ask what the local
> currency is.  John's oversight is a trivial one by
> comparison.
>
> Melinda
>
> __**_
> 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: Getting to Quebec City

[Andrew Sullivan]

On Sat, Jun 18, 2011 at 12:08:52AM -, John Levine wrote:

> By train: there are four trains a day from Montreal to Quebec.
> Although there is a train station in Dorval, close to the airport, it
> doesn't have any through trains to Quebec so it's easier to go
> downtown.

Note that if you plan to use Via Rail, you should treat the train
timetables as rough guidelines rather than something on which to rely.
The train usually does not run exactly on time, although the
timetables might be close enough for IETF arrival purposes.  But
worse, there are occasional equipment failures that make things fail
in big ways.  Via runs on tracks shared with (and owned by) the
freight lines, so if Via has an equipment failure that causes them a
delay, they can miss a window completely.  I have arrived over 4 hours
late on a trip that should not have taken 4 hours total.

One history of Canada suggests that we were only stitched together in
order to enable the CPR to be built.  Now we can barely run trains.
Sir Sanford Fleming must be unhappy.

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Getting to Quebec City

[Melinda Shore]

On 06/17/2011 04:32 PM, Eric Rescorla wrote:

Quebec:   Land area=1,365,128 km2   Water Area=176,928 km2
Alaska:  Land Area: 1,481,347 km2  Water Area=236,507 km2
Perhaps you meant Continental US.


Until recently if you tried to sign up for Google Voice
from Alaska you were informed that the service is not
available in your country.  People ask what the local
currency is.  John's oversight is a trivial one by
comparison.

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

Re: Getting to Quebec City

[Eric Rescorla]

On Fri, Jun 17, 2011 at 5:08 PM, John Levine  wrote:
> As you may have noticed, flying to Quebec City (YQB) is incredibly
> expensive.  That's because it's a regional airport with little
> competion.  Flying to Montreal is usuallly a lot cheaper.  Getting
> from Trudeau airport in Montreal involves some planning, but it's not
> hard.  The trip is about four hours; Quebec is big, bigger than any
> state in the US.

Nitpick alert:

http://en.wikipedia.org/wiki/Quebec
http://en.wikipedia.org/wiki/List_of_U.S._states_and_territories_by_area

Quebec:   Land area=1,365,128 km2   Water Area=176,928 km2
Alaska:  Land Area: 1,481,347 km2  Water Area=236,507 km2

Perhaps you meant Continental US.

Best,
-Ekr
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Getting to Quebec City

[John Levine]

As you may have noticed, flying to Quebec City (YQB) is incredibly
expensive.  That's because it's a regional airport with little
competion.  Flying to Montreal is usuallly a lot cheaper.  Getting
from Trudeau airport in Montreal involves some planning, but it's not
hard.  The trip is about four hours; Quebec is big, bigger than any
state in the US.

By bus: Orleans Express has five buses a day.  You can buy tickets
online or at the ICE America desk in the airport lobby:

   https://www.orleansexpress.com/search.aspx

By train: there are four trains a day from Montreal to Quebec.
Although there is a train station in Dorval, close to the airport, it
doesn't have any through trains to Quebec so it's easier to go
downtown.  The 747 city bus runs every 10 to 15 minutes express to
downtown.  Get off at Mansfield for the central train station.  The
fare is $8, most easily paid by getting a day transit pass, which also
costs $8, at the currency exchange booth in the airport lobby.  For
train schedules and fares, see the Via Rail web site.

The Quebec train station is a medium walk or a short taxi trip from
the convention centre.

   http://www.stm.info/english/info/a-747.htm
   http://www.viarail.ca

You can rent a car and drive, but unless you're planning to do som
touring before or after the meeting, e.g., to the Saguenay fjord,
Montreal to Quebec not a very interesting drive so I wouldn't bother.

R's,
John
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [codec] Last Call: (Codec Requirements) to Informational RFC

[Donald Eastlake]

On Thu, Jun 16, 2011 at 4:42 PM, Christian Hoene  wrote:
> Hello,
>
> In this draft, the editors of draft are not named as editors but as authors.
> Thus, I would suggest to follow the example given in
> http://www.rfc-editor.org/rfc/rfc5620.txt and add an ", Ed." behind the
> names. A list of authors is given in the acknowledgement section of the
> draft.

If everyone listed at the upper right of the first page is going to be
an Editor, then adding "Ed." after their name is completely
superfluous and adds only clutter.

Traditionally, those listed at the upper right of the first page of an
RFC have been called "authors" in most cases, regardless of their
actual role, and those listed in an Acknowledgements section have
frequently been called "contributors" or the like. So I think it s
perfectly fine the way it is in regards to this non-issue.

Donald

> With best regards,
>
>  Christian Hoene
>
>
>> -Original Message-
>> From: codec-boun...@ietf.org [mailto:codec-boun...@ietf.org] On Behalf
>> Of The IESG
>> Sent: Thursday, June 16, 2011 9:24 PM
>> To: IETF-Announce
>> Cc: co...@ietf.org
>> Subject: [codec] Last Call:  (Codec
>> Requirements) to Informational RFC
>>
>>
>> The IESG has received a request from the Internet Wideband Audio Codec
>> WG
>> (codec) to consider the following document:
>> - 'Codec Requirements'
>>    as an Informational RFC
>>
>> 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 2011-06-30. 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.
>>
>> Abstract
>>
>>
>>    This document provides specific requirements for an Internet audio
>>    codec.  These requirements address quality, sampling rate, bit-rate,
>>    and packet loss robustness, as well as other desirable properties.
>>
>>
>>
>>
>> The file can be obtained via
>> http://datatracker.ietf.org/doc/draft-ietf-codec-requirements/
>>
>> IESG discussion can be tracked via
>> http://datatracker.ietf.org/doc/draft-ietf-codec-requirements/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>> ___
>> codec mailing list
>> co...@ietf.org
>> https://www.ietf.org/mailman/listinfo/codec
>
> ___
> 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: Last Call: (The 'about' URI scheme) to Proposed Standard

[John C Klensin]

Given the controversies, I decided I needed to do a careful
reading of this document.  While I respect and appreciate what
the authors are trying to do, as a would-be standards track
specification, it is pretty troubling.  It is troubling
editorially as well.

I think all or most of the specific issues have been identified
by others, so let me try a different perspective and a 10 km
view.

(1) There seems to be consensus that registering this URI as a
mechanism for accessing built-in functionality and configuration
information such as application information, preferences, or
settings.   (Text derived from the Abstract with "configuration
information", which may mean more to some readers, added and
"easter eggs" dropped.  Dropping "easter eggs" reflects other
comments on the list and my opinion that it isn't worth the
trouble to define.

Recommendation: Let's get it registered.


(2)  The document itself reflects an attempt to define the
undefinable.  There is no cross-implementation interoperability
issue here; if anything, the document should me more clear that
it would be stupid to assume it.  The document, nonetheless,
tries to define what is done with some specific URIs in some
places and then has to turn around and indicate that they may be
used in entirely different ways in other places and should not
be relied upon.  In the process, it skips back and forth between
being descriptive and being normative, with some definitions
becoming circular in the process.   That just isn't a good
combination and some of it actually looks pretty silly.  

"about:blank" is particularly troubling in that regard because
the text essentially says that it is reserved except where it
isn't.

Recommendation:  Choose one of the following and redo the
document to match.

Option 1: Do this descriptively.  Strip it down as much as
possible, more or less repeating the suggested language above.
If the Wikipedia article really contains a better and more
authoritative list of applications than the I-D text (and
especially if it is being kept up to date), just reference it as
a place where a non-normative listing and examples can be found.
The effect of doing this at all would be to reserve the name for
purposes internal to particular implementations of particular
applications, not unlike RFC 1918 addresses.

Option 2: Really try to make this normative wrt some subset of
URI values.  In this approach, stop the extremely confusing
circling around.  Indicate explicitly that "about" URIs have
been used enough and in enough different circumstances that no
application should assume that an "about" URI, if encountered,
is actually its own and that due caution needs to be taken about
non-conforming implementations.  Then explicitly reserve, not
only "about:blank", but  everything the authors think is worth
listing in Examples _and_ create an IANA registry for more of
them.  

But, even the second approach is taken, the document should be
really clear that all that the use of "about:" really tells
someone is that it is application-specific and that a particular
implementation of a particular application may do whatever it
pleases with them.


  
Smaller issues:

(i) Section 6, Normalization, sadly really doesn't belong here
unless the authors can show that everyone interprets "about:"
according to those rules.  Otherwise, it would be better to say
that the URI is interpreted in an implementation-specific way
and that implementations would be well-advised to conform to
normal URI syntax rules unless there is a strong reason not to.

(ii) IMO, Section 7, Security Considerations, should be modified
to include an explicit statement that, since these things are
intended for convenience use within an implementation of an
application, passing them between systems (embedded in files or
otherwise) is very risky behavior and should generally be
discouraged except, possibly, in documentation contexts.

(iii) I know this is partially a problem with the general URI
and IRI definitions, but I'm supposed to know something about
i18n and  encoding and Section 4, Encoding Considerations, is
almost incomprehensible to me.  It isn't quite clear what "this
syntax" refers to (if it is "the 'about' variation on the
general URI syntax described in Section 3", say that).   Then I
think it says I may use any Unicode character, but I have to
%-encode it, but, if it isn't unreserved, it shouldn't be
%-encoded.  If there isn't a clearer way to say that, I suggest
that almost anyone trying to figure out how to use this URI from
the spec is in trouble.  And, fwiw, I've seen "about:" URIs that
use non-ASCII strings without %-encoding.   Whether one calls
those IRIs, URIs, or pumpkins, I see absolutely no reason why an
implementation that knows it is UTF-8 capable (and clean) should
require that an xRI that is intended only for internal use
should require %-encoding of UTF-8 strings... especially since,
in practice, these URIs are often expected to be direct user
in

Re: Last Call: (The 'about' URI scheme) to Proposed Standard

[Julian Reschke]

On 2011-06-17 06:32, Boris Zbarsky wrote:

...

and because the
normalization is not defined in the spec.

Normalization is defined in RFC 3986.


Browsers don't actually implement RFC 3986 in practice because it's not
compatible with web content, last I checked Pretending like they do
doesn't seem to be productive.
...


It would be very helpful for the IRI WG if browser vendors actually 
reported what this incompatibility is; and whether UAs indeed agree on 
what the "right" thing to do is.


So far I'm aware of certain kinds of preprocessing, and workarounds for 
specific schemes like "data" and "file", but that's it...


Best regards, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (The 'about' URI scheme) to Proposed Standard

[Boris Zbarsky]

On 6/17/11 12:03 AM, Mykyta Yevstifeyev wrote:

not
clearly compatible with the web security model,

How?


"about:blank" in particular is magic with respect to security on the web 
in various ways (e.g. it can end up same-origin with http:// pages).  So 
I think we do need to specify exactly when this magic security behavior 
takes place.


The question is what existing UAs do and what assumptions web authors 
make, as well as what assumptions should be safe for them to make.


Note that "not clearly compatible" doesn't mean "not compatible"; it 
just means it needs sorting out.


Note that this is also an exception to the general claim that about: is 
only used internally.   That's not the case for about:blank.


So I think we do need a Standards Track document that pins down how 
about:blank works; I will be happy to make whatever changes are needed 
to Gecko here to achieve interop assuming that the result has been 
vetted in terms of the security implications.


For other about: URIs, I don't know whether Standards Track necessarily 
make sense.



and because the
normalization is not defined in the spec.

Normalization is defined in RFC 3986.


Browsers don't actually implement RFC 3986 in practice because it's not 
compatible with web content, last I checked  Pretending like they do 
doesn't seem to be productive.


Or is the point that the algorithms to be used are just the ones defined 
in 3986 and those are sufficiently ok that browsers do actually use 
them?  That wasn't clear to me from the current draft.


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

RE: [codec] Last Call: (Codec Requirements) to Informational RFC

[Christian Hoene]

Hello,

In this draft, the editors of draft are not named as editors but as authors.
Thus, I would suggest to follow the example given in
http://www.rfc-editor.org/rfc/rfc5620.txt and add an ", Ed." behind the
names. A list of authors is given in the acknowledgement section of the
draft.

With best regards,

 Christian Hoene


> -Original Message-
> From: codec-boun...@ietf.org [mailto:codec-boun...@ietf.org] On Behalf
> Of The IESG
> Sent: Thursday, June 16, 2011 9:24 PM
> To: IETF-Announce
> Cc: co...@ietf.org
> Subject: [codec] Last Call:  (Codec
> Requirements) to Informational RFC
> 
> 
> The IESG has received a request from the Internet Wideband Audio Codec
> WG
> (codec) to consider the following document:
> - 'Codec Requirements'
>as an Informational RFC
> 
> 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 2011-06-30. 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.
> 
> Abstract
> 
> 
>This document provides specific requirements for an Internet audio
>codec.  These requirements address quality, sampling rate, bit-rate,
>and packet loss robustness, as well as other desirable properties.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-codec-requirements/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-codec-requirements/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> ___
> codec mailing list
> co...@ietf.org
> https://www.ietf.org/mailman/listinfo/codec

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

Re: Last Call: (The 'about' URI scheme) to Proposed Standard

[Boris Zbarsky]

On 6/16/11 4:59 AM, Lachlan Hunt wrote:

Mykyta, we do need to make this spec document reality, particularly
where implementations are unwilling to make changes


To be clear, in the normalization case we (Gecko) may be willing to make 
changes, but not if it causes conflicts with existing security 
assumptions on the web.  And that's something that needs to be 
investigated _before_ this spec if finalized, clearly.


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

Re: Last Call: (The 'about' URI scheme) to Proposed Standard

[Barry Leiba]

>    Barry> internally, and, therefore, has no interoperability
>    Barry> requirements.  As best I can tell, the issue here is to let
>
> It does.  It's an RFC1918-type use, and for the same reason we had to
> document those networks, we have to document this URI.
> This document prevents someone else from creating "about:" scheme which
> is NOT internal.

Oh, yes: to be clear here... I am NOT suggesting that we shouldn't
register the URI scheme.  I'm only saying that the registration
doesn't require a great deal of standards-track documentation.  A
short Informational doc should do.

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

Re: Last Call: (The 'about' URI scheme) to Proposed Standard

[Michael Richardson]

> "Barry" == Barry Leiba  writes:
>> More substantively, I fail to understand how this specification
>> proposes to create a class of "reserved" about: URIs when the
>> about: scheme seems to be internal information to an
>> application.  I think the Security Considerations section doesn't
>> address any of that, and probably ought to, particularly in light
>> of the proposal to add text that users ought not to depend on
>> "standard" behaviour.

Barry> Yes... I'm actually very confused about the point of this
Barry> document.  It's documenting a URI scheme that's used ONLY
Barry> internally, and, therefore, has no interoperability
Barry> requirements.  As best I can tell, the issue here is to let

It does.  It's an RFC1918-type use, and for the same reason we had to
document those networks, we have to document this URI.
This document prevents someone else from creating "about:" scheme which
is NOT internal.

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (The 'about' URI scheme) to Proposed Standard

[Lachlan Hunt]

On 2011-06-17 06:32, Boris Zbarsky wrote:

On 6/17/11 12:03 AM, Mykyta Yevstifeyev wrote:

not
clearly compatible with the web security model,

How?


"about:blank" in particular is magic with respect to security on the web
in various ways (e.g. it can end up same-origin with http:// pages). So
I think we do need to specify exactly when this magic security behavior
takes place.


The spec is not meant to imply that the special same-origin behaviour 
for about:blank is to be inherited by any other about URI, even if other 
URIs also return a blank document.  Perhaps, I need to make that clearer 
in the spec.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf