> within
>the host) so I think you mean "whether IE and Windows people would do
> so".
>I think it's probably safe to assume the answer is "No" because it may
> result
>in breaking applications. That's not something that's worth it
t; From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> Brian E Carpenter
> Sent: Sunday, July 15, 2012 12:58 AM
> To: ipv6@ietf.org
> Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt]
>
> Without consulting my co-author, here's
On Mon, Jul 16, 2012 at 11:51:13AM +0100, Brian E Carpenter wrote:
> > RFC 6021 clearly uses a textual format on the wire.
>
> Yes, but there's a problem IMHO. 6021 says:
>
> " The canonical format for the zone index is
>the numerical format as described in RFC 4007, Section
>11.2."
>
Regards
Brian Carpenter
On 16/07/2012 10:58, Juergen Schoenwaelder wrote:
> On Mon, Jul 16, 2012 at 08:03:03AM +0100, Brian E Carpenter wrote:
>> Juergen,
>>
>>> The "%"
>>> separator is also embedded in other IETF standards-track specifications;
>> Can you be specific about that? The conte
On Mon, Jul 16, 2012 at 08:03:03AM +0100, Brian E Carpenter wrote:
> Juergen,
>
> > The "%"
> > separator is also embedded in other IETF standards-track specifications;
>
> Can you be specific about that? The context here is very specific and
> I am not aware of any other standards that are relev
Juergen,
> The "%"
> separator is also embedded in other IETF standards-track specifications;
Can you be specific about that? The context here is very specific and
I am not aware of any other standards that are relevant to IPv6 literals.
There clearly isn't consensus in the WG on a change to the
On Sun, Jul 15, 2012 at 05:19:36PM +0100, Brian E Carpenter wrote:
> ... OK, as a result of Dave's comments, we now say:
>
> " Section 11 of RFC 4007 is updated to allow "-" as well as "%" as the
>preceding delimiter of a ZoneID."
>
> What we do *not* say is to recommend or suggest that all
On 15/07/2012 12:34, Simon Perreault wrote:
> On 07/15/2012 03:57 AM, Brian E Carpenter wrote:
>> Unfortunately there is no way to resolve the discrepancy between
>> the two approaches mentioned above (raw "%" versus "%25") and
>> therefore we recommend general implementation of the new
On 07/15/2012 03:57 AM, Brian E Carpenter wrote:
Unfortunately there is no way to resolve the discrepancy between
the two approaches mentioned above (raw "%" versus "%25") and
therefore we recommend general implementation of the new "-" syntax
defined by this document. This will a
Without consulting my co-author, here's my personal suggestion for
a change to the draft. There's just time to submit an update before
the cutoff, if people respond immediately.
OLD
In recent years, web browsers have evolved considerably and now
accept and parse many forms of input that are
On 07/14/12 13:04, Brian E Carpenter wrote:
So obviously browser implementers should be involved in this discussion?
We shouldn't be "telling" them, we should be discussing with them.
Yes, but I think that's outside the scope of the present draft.
I understand that there is forum for such discu
On 14/07/2012 15:39, Simon Perreault wrote:
> On 07/14/2012 04:41 AM, Brian E Carpenter wrote:
>> On 12/07/2012 23:34, SM wrote:
>>> Hi Simon,
>>> At 12:47 12-07-2012, Simon Perreault wrote:
Suggestion:
On input, applications MUST accept the formal syntax and MAY accept
another synta
On 07/14/2012 04:41 AM, Brian E Carpenter wrote:
On 12/07/2012 23:34, SM wrote:
Hi Simon,
At 12:47 12-07-2012, Simon Perreault wrote:
Suggestion:
On input, applications MUST accept the formal syntax and MAY accept
another syntax.
On output, applications MUST use the formal syntax and MUST NOT u
On 12/07/2012 23:34, SM wrote:
> Hi Simon,
> At 12:47 12-07-2012, Simon Perreault wrote:
>> Suggestion:
>> On input, applications MUST accept the formal syntax and MAY accept
>> another syntax.
>> On output, applications MUST use the formal syntax and MUST NOT use
>> another syntax.
>
> As long as
On 07/13/2012 12:00 PM, SM wrote:
Hi Simon,
At 05:35 13-07-2012, Simon Perreault wrote:
Have you heard of Postel's law?
I try to be liberal in accepting arguments arguments from by
implementers.
My proposal stemmed from Dave Thaler's argument... not sure what you're
implying.
I am conser
Hi Simon,
At 05:35 13-07-2012, Simon Perreault wrote:
Have you heard of Postel's law?
I try to be liberal in accepting arguments arguments from by
implementers. I am conservative when it comes to usage of RFC 2119 key words.
Regards,
-sm
--
On 07/12/2012 06:34 PM, SM wrote:
Hi Simon,
At 12:47 12-07-2012, Simon Perreault wrote:
Suggestion:
On input, applications MUST accept the formal syntax and MAY accept
another syntax.
On output, applications MUST use the formal syntax and MUST NOT use
another syntax.
As long as an implementati
Hi Simon,
At 12:47 12-07-2012, Simon Perreault wrote:
Suggestion:
On input, applications MUST accept the formal syntax and MAY accept
another syntax.
On output, applications MUST use the formal syntax and MUST NOT use
another syntax.
As long as an implementation supports the formal syntax, th
On 07/12/2012 03:16 PM, Dave Thaler wrote:
Because it's completely unpredictable without having
browser-specific knowledge which I think is inappropriate here, I
don't think it should recommend either one. Making a recommendation
in this document will just increase the likelihood of interoperab
Brian and Bob already heard this but wanted list discussion before making
any changes to the doc, so posting publically...
Section 3 states:
> For example:
>
> http://[fe80::a%en1]
>
> It seems that modern browsers can be adapted to parse this because it
> is inside of the "[" "]"'s.
Th
20 matches
Mail list logo
