On Mar 6, 2012, at 5:44 PM, Brian E Carpenter
wrote:
> On 2012-03-07 11:26, Carsten Bormann wrote:
>> On Mar 6, 2012, at 23:08, Brian E Carpenter wrote:
>>
>>> Was there a real reason that you went for this?
>>> IPv6zone-id = 1*( unreserved / sub-delims / ":" )
>>
>> I'm not Bill, but RFC 3986 sa
On Mon, Mar 5, 2012 at 7:15 PM, Brian E Carpenter
wrote:
> Carsten,
>
> On 2012-03-06 12:22, Carsten Bormann wrote:
>> On Mar 6, 2012, at 00:00, Brian E Carpenter wrote:
>>
>>> No, I think it's exactly *not* confused on this point. There's
>>> a distinction between the idealised URI and the produc
2010/4/19 Tina TSOU :
> In RFC 4293,
> - ipAddressTable is described as writable, this table uses address
> as index, but the critical information for configuring address, the
> address prefix ipAddressPrefix node is read-only. It seems
> contradict to me.
Worse, the whole ipAddressPrefixTable is
[sorry if you get duplicates, replying from an address that actually
*works* this time]
2010/4/19 Tina TSOU :
> In RFC 4293,
> - ipAddressTable is described as writable, this table uses address
> as index, but the critical information for configuring address, the
> address prefix ipAddressPrefix n
My off-the-cuff answer is that the udpEndpointInstance
exists in order to distinguish between multiple UDP Endpoints
that are otherwise identical, so its specific value doesn't
matter at all (otherwise than that it's unique, which is
required by the fact that it's in the INDEX). One imagined
impl
>My understanding is that we then made a consensus about
>questions -1 and 0 with the answer of "YES", and hence this version.
>(Is my understanding correct?)
Yes.
>Now I'm surprised to see the new version provides the answer to
>questions 1-3 with removing alternatives. Have we already made a
>...I didn't understand the proposal
>assumed additional requirements for URL/URI parsers, so I didn't
>understand its usefulness. **If we can allow that**, I see this can
>be useful, while it should be minor usage ...
Certainly, it's envisioned to be a small niche, which is why I am
not ready t
>So, I guess the appropriate next step for this work is to make
>consensus on this, which mostly equals to my question -1:
>
> -1. are we okay with forcing URL/URI parsers to understand the
> detailed semantics of the scoped address syntax and to strip the
> zone ID (+ delimiter) part b
On Mon, 04 Apr 2005 16:33:00 +0900,
JINMEI Tatuya <[EMAIL PROTECTED]> said:
>Is my understanding now correct?
Yes, that looks right. And even if getaddrinfo took whatever
form directly (either the separator is '%' or getaddrinfo is
modified to accept the URI character as well), I think it's
reas
>>>>>> On Sun, 3 Apr 2005 11:17:17 -0800,
>>>>>> Bill Fenner said:
>> Since this format is unique and is only used for scoped
>> addresses, the application doesn't have to decide based on the address -
>> it's already been told b
>The essential point is, at least to me, is that we did not want to
>force applications (like URI/URL parsers) to be aware of scope zones
>and/or the dedicated syntax for scoped addresses.
My reading was that we don't want applications to have to examine an
arbitrary address and decide whether or
You're right, we were out of sync;
>3. the parser passes "fe80::1_de0" to getaddrinfo(), and gets a
> sockaddr_in6 structure (whose sin6_addr member is "fe80::1" and
> sin6_scope_id member is the link ID corresponding to interface
> "de0"). The browser uses the sockaddr_in6 structure with
>Then the browser (parser) implementation would first extract
>"fe80::1_de0" and pass it to getaddrinfo(3) for converting it to an
>IPv6 address. So far, so good, but then the browser would also need
>to modify the entire URL to:
>
> http://[fe80::1]/
>
>before sending it to the web server on th
> square bracket does not fit the RFC3986 abnf anyways. therefore,
> i do not think addition of "v6." or use of "_" would really help.
Please look again at the IP-Literal and IPvFuture productions.
> i would say we should stick to current
> http://[fe80::1%fxp0]:
I usually think of the small home router configuration problem -
buy a box, plug it in, it wants you to configure it using a web
page, and it's probably fe80::1. I don't have any systems in my
house that have fewer than two non-loopback interfaces. Since
this is presumably a one-off, I guess the
Dear all,
At the IETF meeting in Minneapolis, I talked about the URI format for
scoped addresses, described in
http://www.ietf.org/internet-drafts/draft-fenner-literal-zone-01.txt
I had 3 questions prepared, but the time didn't really allow for
asking them in a sensible way (and Dave Thaler
FYI: I updated this draft based on the discussion on the ipv6
mailing list. There are still no strong conclusions. The
discussion on the ipv6 list petered out after dropping the Cc:
of the URI list and asking questions that people on the URI list
would be best suited to answer. Perhaps this upd
Percent encoding in the host part is an idn/i18n extension only;
the grammar is more permissive than the text. The text restricts
percent-escaping to UTF-8 encoding of non-ASCII names.
This was part of a significant rewrite of the grammar from an ad-hoc
BNF to ABNF; see appendix D of draft-field
The Full Standard URI spec (draft-fielding-uri-rfc2396bis-07.txt)
and the Proposed Standard IRI spec (draft-duerst-iri-11.txt) both
specify percent-encoding in the host part, particularly for support
of internationalization.
It's a shame that the [EMAIL PROTECTED] list got dropped off of the cc l
Good point. I replaced the last sentence with:
Therefore, care must be taken to not pass these URIs blindly between
systems. When both systems are aware of the relevant Zone IDs, e.g.,
an SNMP manager that is aware of the zone ID configuration of an agent,
it is acceptable to pass these URIs be
>p.s. I've noticed the draft-ietf-ipv6-scoping-arch-02.txt has been in
>the RFC editor queue for over 3 months. Is anyone know whether this
>is a usual delay or the issues with the URI syntax is working as a
>showstopper?
The RFCs that have been published over the last couple of months have
had
I've added the following pieces to the draft to try to capture the
conversation so far.
[at the end of section 2.1:]
o Use '%' in the URI
Pro:
+ "%" is the same character.
+ Can copy and paste between forms.
Con:
+ '%' is fundamentally special in URIs
>There were >100 e-mails on the ipng ML at December 1999 about the
>representation. Actually we considered the all possible characters.
>One reason to reject '_' was that it should be used for .
There are very few messages (around 10) in the archive that actually
discuss the specifics of delimit
>> I agree that getting "cut and paste" is a big usability win. Does "_"
>> create any other problems?
>
> You mean apart from it [not] being part of some character sets.
I'm sorry, I have to plead ignorance; I thought all character sets
(other than EBCDIC) were supersets of US-ASCII.
I
>I think loosing the ability to cut and paste these addresses is a
>problem. The % is in widespread usage today.
Indeed, that's why this whole thing is a sticky issue and there's
no obvious answer. My FreeBSD and MacOS machines all use the % too,
and have for years.
>My dump question (that ex
Folks,
When looking at the URI/IRI literal scoped address format (nee RFC 2732,
now rolled into the uri/iri specs), we noticed that there was a small gap -
you can't specify a zone ID. Since some implementations require a zone ID
to connect to a possibly-ambiguous scoped address even if it's n
26 matches
Mail list logo
