dependent, the only restriction
being that % and null are disallowed.
draft-ietf-6man-uri-zoneid-02 is explicit that it refers to the
URI
character set, which is ASCII:
A zone_id SHOULD contain only ASCII characters classified
in RFC 3986 as unreserved.
The draft isn't clear
On Thu, Aug 09, 2012 at 02:31:24PM -0700, Stuart Cheshire wrote:
At the meeting in Vancouver, Dave Thaler made a point that I found
convincing:
Where is the character set for IPv6 zone IDs specified? If we accept
that future interface names might include non-roman characters, then
we have
On 11/08/2012 18:14, Dave Thaler wrote:
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Brian E Carpenter
Sent: Saturday, August 11, 2012 3:40 AM
To: Dave Thaler
Cc: Bob Hinden; ipv6@ietf.org
Subject: Re: draft-ietf-6man-uri-zoneid-02
that, but the context to me implies ASCII. We could argue
about that for a long time, so let's not bother...
So it's completely implementation dependent, the only restriction being
that % and null are disallowed.
draft-ietf-6man-uri-zoneid-02 is explicit that it refers to
the URI character set, which
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Brian E Carpenter
Sent: Saturday, August 11, 2012 3:40 AM
To: Dave Thaler
Cc: Bob Hinden; ipv6@ietf.org
Subject: Re: draft-ietf-6man-uri-zoneid-02
Dave,
On 11/08/2012 03:59, Dave Thaler
Stuart,
On 09/08/2012 22:31, Stuart Cheshire wrote:
At the meeting in Vancouver, Dave Thaler made a point that I found
convincing:
Where is the character set for IPv6 zone IDs specified?
RFC 4007 doesn't do so, but can be read to imply ASCII.
draft-ietf-6man-uri-zoneid-02 is explicit
Stuart == Stuart Cheshire chesh...@apple.com writes:
Stuart This argues in support of what Microsoft already did: Encode
Stuart '%' as % 25.
okay.
May a browser process the %-escaped UTF-8 in the interface name for the
purpose of display them?
If it does that, and a user then
(this is just supporting that you say that the parse must be tolerant of
a bare %)
First please solve the mystery of how such a parser can tell whether %251 is
an escaped %1 or an unescaped %251.
IETF IPv6 working group
that % and null are disallowed.
draft-ietf-6man-uri-zoneid-02 is explicit that it refers to
the URI character set, which is ASCII:
A zone_id SHOULD contain only ASCII characters classified
in RFC 3986 as unreserved.
But it allows percent encoding in a URI, which is necessary because
At the meeting in Vancouver, Dave Thaler made a point that I found
convincing:
Where is the character set for IPv6 zone IDs specified? If we accept
that future interface names might include non-roman characters, then
we have to assume that to allow safe unambiguous use in URIs,
interface
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 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
On 01/08/2012 18:16, Juergen Schoenwaelder wrote:
On Wed, Aug 01, 2012 at 09:42:44AM -0700, Tassos Chatzithomaoglou wrote:
Wouldn't it be an option to have all applications systems accept
as input both formats, but only give as output the new one?
i.e. browsers already rewrite URIs.
There
On Thu, Aug 2, 2012 at 12:29 PM, Juergen Schoenwaelder
j.schoenwael...@jacobs-university.de wrote:
On Thu, Aug 02, 2012 at 11:10:40AM +0100, Brian E Carpenter wrote:
I see no value in introducing a new separator.
The value is providing a long-term path to cut and paste. Otherwise,
I
Wouldn't it be an option to have all applications systems accept as
input both formats, but only give as output the new one?
i.e. browsers already rewrite URIs.
--
Tassos
IETF IPv6 working group mailing list
ipv6@ietf.org
On Wed, Aug 01, 2012 at 09:42:44AM -0700, Tassos Chatzithomaoglou wrote:
Wouldn't it be an option to have all applications systems accept
as input both formats, but only give as output the new one?
i.e. browsers already rewrite URIs.
There are other standards that currently state that % is
On 16 Jul, 2012, at 20:50, Mark Andrews wrote:
Stuart,
your mail client botched the Content-type line generation.
You may want to report it.
Content-type: image/png; x-unix-mode=0644; name=Whatis#39;
?.png=
Content-transfer-encoding: base64
Content-disposition:
In message d41807cf-b7f5-4770-8fb5-f0630aa4f...@apple.com, Stuart Cheshire wr
ites:
On 16 Jul, 2012, at 20:50, Mark Andrews wrote:
Stuart,
your mail client botched the Content-type line generation.
You may want to report it.
Content-type: image/png; x-unix-mode=0644;
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 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 relevant to
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 context here is
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.
That
-ietf-6man-uri-zoneid-02.txt]
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
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/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 allow
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 - syntax
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 tools that
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 an
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
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 syntax.
On output,
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
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
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/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
Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Brian E Carpenter
Sent: Wednesday, July 11, 2012 5:30 AM
To: 6man
Subject: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt]
This version includes changes for the recent comments from Dave Thaler
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,
) : Brian Carpenter
Robert M. Hinden
Filename: draft-ietf-6man-uri-zoneid-02.txt
Pages : 10
Date: 2012-07-11
Abstract:
This document describes how the Zone Identifier of an IPv6 scoped
address can be represented
syntax defined
above.
The URI list raised no objection to the formal syntax change.
Brian + Bob (as author)
Original Message
Subject: I-D Action: draft-ietf-6man-uri-zoneid-02.txt
Date: Wed, 11 Jul 2012 05:23:52 -0700
From: internet-dra...@ietf.org
To: i-d-annou...@ietf.org
Sorry - thought I'd deleted the cc to the list.
Regards
Brian Carpenter
On 10/07/2012 14:54, Brian E Carpenter wrote:
Bob (as co-author) and Dave (as reviewer),
Here's a proposed update and a diff file.
Please let me know ASAP if this is OK for you, as the cutoff is approaching.
38 matches
Mail list logo
