04 AM, Harald Alvestrand wrote:
On 08/15/2013 11:04 AM, Graham Klyne wrote:
Hi Harald,
On 14/08/2013 19:49, Harald Alvestrand wrote:
On 08/13/2013 12:14 AM, Graham Klyne wrote:
[...]
But, in a personal capacity, not as designated reviewer, I have to ask *why*
this needs to be a URI. As f
;This URI scheme is intended for use in very specific NAT traversal
environments, and should not be used otherwise on the open Web or Internet."
Would such a comment run contrary to your expectations for its use?
#g
--
On 15/08/2013 11:04, Harald Alvestrand wrote:
On 08/15/2013 11:04 AM,
Hi Harald,
On 14/08/2013 19:49, Harald Alvestrand wrote:
On 08/13/2013 12:14 AM, Graham Klyne wrote:
[...]
But, in a personal capacity, not as designated reviewer, I have to ask *why*
this needs to be a URI. As far as I can tell, it is intended for use only in
very constrained environments
From: The IESG
To: IETF-Announce
Reply-to: iesg-secret...@ietf.org
Subject: Last Call: (Traversal
Using Relays around NAT (TURN) Uniform Resource Identifiers) to Proposed
X-C5I-RSN: 1/0/934/11413/12177
The IESG has received a request from an individual submitter to consider
the following docu
From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call: (URI Scheme for
Session Traversal Utilities for NAT (STUN) Protocol) to Proposed Standard
The IESG has received a request from an individual submitter to consider
the following document:
- 'URI Scheme for S
On 22/10/2012 23:35, Ian Hickson wrote:
Consensus isn't a value I hold highly,
!
#g
--
late.
First, if IETF Last Call is too late to make serious technical
comments
on drafts, then I think we have to rename it to IETF Too-Late Call.
Second, designated experts are there to check for minimum requirements
for a registration, and to give advice as they see fit (and have
time).
I
On 12/06/2012 15:56, Dave Crocker wrote:
On 6/12/2012 7:19 AM, Peter Saint-Andre wrote:
it's not the role of the designated expert to
act as a gatekeeper with respect to the technical merits of the
technologies that trigger registration requests. It might be good to
have a wider discussion abou
e advice as they see fit (and have time).
I'm myself a designated expert on "Character Sets", and I have
definitely in the past approved, and would again in the future approve,
registrations for stuff on which I would complain strongly if the
question was "is this a good technical
Hi,
At 180-ish pages, it's a pretty daunting spec. At a cursory glance, it mostly
seems to be yet another schema language for XML - I didn't see anything in the
introduction to suggest otherwise:
This document describes the syntax and semantics of the YANG
language, how the data model def
RC for recording and remote participants.
#g
----
Graham Klyne
For email:
http://www.ninebynine.org/#Contact
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
This bit of hacking by Dan Connolly maybe of interest to some...
http://lists.w3.org/Archives/Public/public-ietf-w3c/2005Feb/0003.html
#g
Graham Klyne
For email:
http://www.ninebynine.org/#Contact
___
Ietf mailing list
Ietf@ietf.org
https
ermail/libraries/2003-November/001541.html
(but there are other views "nearby")
Graham Klyne
For email:
http://www.ninebynine.org/#Contact
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
earrangement of punctuation to ensure appropriate
grouping of the requirements.)
...
#g
----
Graham Klyne
For email:
http://www.ninebynine.org/#Contact
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
r.org/rfc/std/std1.txt
But I agree it's not obvious unless you know that STD 1 is the list of
standards.
#g
--------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailma
essage, so I think it's really worth administering mailing lists in such a
way that URIs remain persistently dereferencable.
#g
Graham Klyne
For email:
http://www.ninebynine.org/#Contact
But that will
have to wait awhile...
___
This message was passed through [EMAIL PROTECTED], which
is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on
what to pass are made solely by IETF_CENSORED ML Administrator
([EMAIL PROTECTED]).
information about DRIS could be found in
http://www.lib.hust.edu.cn/dl-lib/English/main.htm
Ask for more advices. Thanks
___
This message was passed through [EMAIL PROTECTED], which
is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on
what t
ISO reaffirms free-of-charge use of its country, currency and language codes:
http://www.iso.org/iso/en/commcentre/pressreleases/2003/Ref871.html
#g
Graham Klyne
[EMAIL PROTECTED]
fc3066.txt
--------
Graham Klyne
[EMAIL PROTECTED]
I've just received a spam addressed to an email address that I used (only)
for registering a past IETF meeting. I don't know what is the current
policy for releasing such email addresses.
Just offering a datum, not making any concrete suggestions.
#g
--------
Graham Kl
o! DSL - Now only $29.95 per month!
---
Graham Klyne
<[EMAIL PROTECTED]>
PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E
urity is compromised, then the cert gets revoked and the genuine
owner has to buy another one. Hey, don't we occasionally lose theatre
tickets? Tough, but not disastrous -- we just have to buy another one.
Anyway, I think your Passport Scheme needs some more work.
I'm sure it does!
#g
--
ant.
Maybe crazy, just thinking aloud...
#g
---
Graham Klyne
<[EMAIL PROTECTED]>
PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E
am box. The point of this is
that legitimate email marketing is suffering by failing to be sufficiently
distinct from the unsolicited spam.
I don't claim all this proves anything, but I think I have cause to believe
forgery of email headers is involved in a significant portion of the spam I
receiv
if a mailing list is archived with simple web access
for each message, Google can be remarkably good at finding old messages.
#g
---
Graham Klyne
<[EMAIL PROTECTED]>
ou review this:
http://www.w3.org/DesignIssues/Fragment.html
#g
-------
Graham Klyne
<[EMAIL PROTECTED]>
to the meeting.
/mtr
-
This message was passed through [EMAIL PROTECTED], which
is a sublist of [EMAIL PROTECTED] Not all messages are passed.
Decisions on what to pass are made solely by Raffaele D'Albenzio.
---
Graham Klyne
<[EMAIL PROTECTED]>
had an appreciably-clearer view of what Layering meant than has
been presented here, yet the ARMS exists. We can only guess what
goes on in the design meetings for protocols to become members of
the ISORM suite (ISORMS), but it doesn't seem likely that having
more layers could possibly decrease the number of arguments
]]
... seems kind-of apposite ;-)
#g
---
Graham Klyne
<[EMAIL PROTECTED]>
At 11:21 PM 7/23/02 +0100, Lloyd Wood wrote:
>I'm just waiting for someone to log a workgroup chat session and send
>it in for publishing as minutes or a draft.
That happens all the time in W3C working groups.
#g
-------
Graham Klyne
<[EMAIL PROTECTED]>
issue is not so much one of process and
precedent, but core competence. And if that isn't clear, or is distributed
across organizations, there are plenty of examples of collaborative efforts.
#g
-------
Graham Klyne
<[EMAIL PROTECTED]>
conflict" here.
#g
-------
Graham Klyne
<[EMAIL PROTECTED]>
mple free-standing description of what constitutes an IDN (to
be simple, such a description may have to be slightly more restrictive than
that allowed by the ACE algorithm).
#g
---
Graham Klyne
<[EMAIL PROTECTED]>
ture developments to embed IDNs directly into DNS
don't get lumbered with legacy ACE code simply to determine what is a valid
IDN.
#g
---
Graham Klyne
<[EMAIL PROTECTED]>
#x27;t like about it but it really was designed to have exactly
> > >this property.
> >
> > Based on a December 2001 article
> > (http://www.dlib.org/dlib/december01/blanchi/12blanchi.html), it seems to
> > me that Handles too depend on some syntactic structure to partition the
> > search space -- based on dynamic content types and metadata schema.
>
>Handles have evolved a bit since first envisioned - as I understand it the
>problem wasn't the inability of the non-partitioned search service to scale
>up to the number of queries but rather the difficulties associated with
>everybody trusting a centrally maintained flat search service.
>
>Someone from cnri might be able to fill in more detail.
>
> > Ah yes, and according to the internet draft on handles:
> >http://www.ietf.org/internet-drafts/draft-sun-handle-system-09.txt
> > there *is* a clear syntactic structure:
>
>Yes, but the searching isn't (didn't used to be) federated according to that
>structure. The scalability of the searching didn't depend on it -
>federating actually slowed things down unless you happened to consult the
>right server first. (locality does affect search speed)
>
> > But I think the general idea still holds here -- if you
> > want to reliably and quickly dereference an identifier with Internet
> scope,
> > it cannot be completely opaque.)
>
>Hashing is faster than tree searching, especially if the tree is distributed.
>you federate the lookup because of trust issues (which are a kind of scaling
>issue, but not in terms of bandwidth or cpu cycles) and ease-of-cost-recovery
>issues, not to make the lookup more efficient or cheaper.
>
>Keith
---
Graham Klyne
<[EMAIL PROTECTED]>
At 10:12 AM 7/3/02 -0700, [EMAIL PROTECTED] wrote:
>Language preferences are, I believe, already defined as something you can get
>out of feature algebra.
Yup. RFC 2987.
#g
---
Graham Klyne
<[EMAIL PROTECTED]>
according to the internet draft on handles:
http://www.ietf.org/internet-drafts/draft-sun-handle-system-09.txt
there *is* a clear syntactic structure:
[[
2. Handle Namespace
Every handle consists of two parts: its naming authority, otherwise
known as its prefix, and a unique local name under the naming
authority, otherwise known as its suffix. The naming authority and
local name are separated by the ASCII character "/". A handle may
thus be defined as:
::= "/"
]]
How each naming authority deals with scaling within its domain of authority
doesn't seem to be specified.
(Actually, when I wrote the above, I later realized that I misspoke
slightly, because some systems work in constrained contexts -- I was
referring to systems operating at global Internet scale without further
contextualization. But I think the general idea still holds here -- if you
want to reliably and quickly dereference an identifier with Internet scope,
it cannot be completely opaque.)
#g
---
Graham Klyne
<[EMAIL PROTECTED]>
in this case, I agree that the identifier should generally be
treated as opaque.
Also, I think (d) contradicts your goal (a): I cannot conceive any
scalable resolution mechanism that does not in some sense depend on
syntactic decomposition of the name.
#g
---
Graham Klyne
<[EMAIL PROTECTED]>
At 02:58 PM 5/29/02 -0700, Dave Crocker wrote:
>At 09:10 PM 5/29/2002 +0100, Graham Klyne wrote:
>>At 08:53 AM 5/29/02 -0700, Dave Crocker wrote:
>>> Certainly we do not have to worry about whether there is
>>> sufficient community interest in IPR. What
lems need to be resolved.
OK, here's a question:
How do we best approach the design of Internet technologies so that
IPR-related obstructions to their deployment will be minimized?
#g
-------
Graham Klyne
<[EMAIL PROTECTED]>
,
#g
---
Graham Klyne
<[EMAIL PROTECTED]>
alls
for a change in the rules so much as maybe engendering a slight sense of
urgency. Sometimes, it's appropriate to nag folks to deliver on their
promises in timely fashion (and I know I'm not entirely innocent of needing
such prodding, on occasion).
#g
---
Graham Klyne
<[EMAIL PROTECTED]>
tracking, WG deliverable tracking, etc.
capable of both consuming and providing information for tools used by other
parties in the overall process (IESG, IANA, RFC editor, etc.)
#g
---
Graham Klyne
<[EMAIL PROTECTED]>
red in other W3C documents, for exampe XML Base.
It would appear that "RFC3275" is a "Googlewhack" ;-)
(Not for long, methinks.)
#g
---
Graham Klyne
<[EMAIL PROTECTED]>
ion and wandering off to find food and
drink. Finally, there's a matter of logistics -- IETF meetings typically
overrun the available lunch facilities (lunches not being provided in the
package); I assert that laying out a buffet is a more efficient way of
feeding and watering the numbers involved.
#g
---
Graham Klyne
<[EMAIL PROTECTED]>
es (with
emphasis on the former), but the IETF meeting fee is really a small part of
the overall cost involved in doing this -- my typical total costs for past
IETF meetings have been around $2500, with advance planning. (And that has
often been while working for a small startup.)
#g
---
Graham Klyne
<[EMAIL PROTECTED]>
>> >>a product for testing, but obtaining UL certification isn't free.
>> >>UL's certification program is successful, because when consumers
>> >>like Valdis (and me) see a UL label, they believe in its value. As
>> >>Valdis points out, the value of the label has limits.
>> >>
>> >>Certification isn't the work of a volunteer organization like the
>> >>IETF. It could be the work of an organization like Underwriters
>> >>Labs. This would be a good thing for Internet standards, imho.
>> >>
>> >>One idea proposed multiple times in this meandering discussion is
>> >>that those advocating testing should put up or shut up -- create a
>> >>testing organization or move on to other topics. I concur with both
>> >>those suggestions. I'm sure you'll all be pleased this is my last
>> >>word on the topic.
>> >>
>> >>best,
>> >>--
>> >>
>> >>john noerenberg
>> >>[EMAIL PROTECTED]
>> >> --
>> >> While the belief we have found the Answer can separate us
>> >> and make us forget our humanity, it is the seeking that continues
>> >> to bring us together, the makes and keeps us human.
>> >> -- Daniel J. Boorstin, "The Seekers", 1998
>> >> --
>> >
>
>-
>This message was passed through [EMAIL PROTECTED], which
>is a sublist of [EMAIL PROTECTED] Not all messages are passed.
>Decisions on what to pass are made solely by Raffaele D'Albenzio.
Graham Klyne
[EMAIL PROTECTED]
rves no purpose other than to
satisfy the above syntax.
An alternative syntax might be:
[[[
parameter = attribute "=" importance *("," value)
]]]
in which case the above example might be:
[[[
Disposition-Notification-Options:
Alternative-not-available=required
assed.
>Decisions on what to pass are made solely by Raffaele D'Albenzio.
Graham Klyne
[EMAIL PROTECTED]
re prohibited. If you
>received this in error, please contact the sender and delete the material
>from any computer.
Graham Klyne
[EMAIL PROTECTED]
S" / "T" / "U" / "V"
in RFC 2938. (I won't claim this is the best possible arrangement, or in
any way an official preference; it just seemed to be an easy way at the
time, kind of like an extension of hexadecimal. Hand transcription was not
a significant requirement here.)
#g
Graham Klyne
[EMAIL PROTECTED]
/www.w3.org/2001/08/16-PP-FAQ) also states that RAND allows for
>licensing audits (RAND "may include reasonable, customary terms relating to
>operation or maintenance of the license relationship such as the following:
>audit (when relevant to fees), choice of law, and dispute resolutio
ss, asserts Rick Lane, director of
e-commerce
and Internet technology at the U.S. Chamber of Commerce.
http://www.infoworld.com/articles/hn/xml/01/02/02/010202hnicann.xml
Graham Klyne
([EMAIL PROTECTED])
other
participant in the group (I understand -- I haven't actually done it).
I think the idea of having an IRC service is great, preferably with someone
in the meeting taking notes into it. This way, those that can't fit in the
room can still have a chance of following the general dri
made solely by Harald Alvestrand.
----
Graham Klyne Content Technologies Ltd.
Strategic Research <http://www.mimesweeper.com>
<[EMAIL PROTECTED]>
Due to lack of physical space in the meeting room, man I request that a
pointer to the OPES mailing list details and meeting minutes be posted to
this list?
#g
Graham Klyne
([EMAIL PROTECTED])
vity of data and services is, I
think, satisfied by the IP layer. Part of my question was about the extent
to which this end-to-end-ness needs to be duplicated at higher layers.
Graham Klyne
([EMAIL PROTECTED])
Internet use.
#g
PS: I think it is without doubt that it is a Good Thing that we make
efforts to internationalize protocols; my comments/questions are an
attempt to explore how far this process can reasonable go.
Graham Klyne
([EMAIL PROTECTED])
alized telcos and
EU/government research bodies; see: <http://members.icann.org/nominees.html>.
#g
----
Graham Klyne
([EMAIL PROTECTED])
ybe other formats.
Both the CONNEG and CC/PP work have (rightly in my view) focused purely on
formats for expression of capabilities. Details of protocols for conveying
such information may reasonably vary between applications (HTTP, SIP,
e-mail, etc.).
#g
Graham Klyne
([EMAIL PROTECTED])
At 08:36 PM 8/30/00 -0400, Scott Bradner wrote:
> > An informational RFC certainly meets these requirements.
>
>I don't think we want to say that any info RFC qualifies
>
>so how do we say just what we want to say and no more?
Promote the info RFC to BCP?
#g
At 07:22 PM 7/4/00 -0600, Vernon Schryver wrote:
>If you are only using your cell phone screen for text messages, why
>do you need WAP?
You don't.
(My phone isn't a WAP phone, but it does do SMS.)
#g
--------
Graham Klyne
([EMAIL PROTECTED])
ile the results, then make publicly available.
>
>Please feel free to distribute this request wherever appropriate.
>
>
>Thank you.
>
>Mohsen BANAN
>
>-
>This message was passed through [EMAIL PROTECTED], which
>is a sublist of [EMAIL PROTECTED] Not all messages are passed.
>Decisions on what to pass are made solely by Harald Alvestrand.
Graham Klyne
([EMAIL PROTECTED])
ot; bandwidth
that voice cannot use. I sometimes think the advantages of messaging are
lost among those who are used to continuous network connections.
#g
Graham Klyne
([EMAIL PROTECTED])
ter (see
http://www.counterpane.com/) contains an essay making the point (among
others) that computer systems security is precisely about risk management,
which means, among other things, making decisions about acceptable levels
of risk.
#g
----
Graham Klyne
([EMAIL PROTECTED])
[EMAIL PROTECTED], [EMAIL PROTECTED]
> > http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
> >
> >
> >
>
>-
>This message was passed through [EMAIL PROTECTED], which
>is a sublist of [EMAIL PROTECTED] Not all messages are passed.
>Decisions on what to pass are made solely by Harald Alvestrand.
Graham Klyne
([EMAIL PROTECTED])
s has been mobile data. One
recurring idea there was the extent to which the problems of mobile data
and accessibility for persons with constrained abilities are, at a purely
technical level, facets of the same problem.)
#g
Graham Klyne
([EMAIL PROTECTED])
remy wrote:
> >Can you plase pleaes stop this Virus Thread.
>
>This thread _is_ the virus...
>
>-
>This message was passed through [EMAIL PROTECTED], which
>is a sublist of [EMAIL PROTECTED] Not all messages are passed.
>Decisions on what to pass are made solely by Harald Alvestrand.
Graham Klyne
([EMAIL PROTECTED])
et another mailing list, one dealing with
ways to control the spread of malicious content is one that I think would
be very worthwhile.
#g
(Who uses an 8-year old version of Microsoft Word, in part as a precaution
against macro viruses ;-)
Graham Klyne
([EMAIL PROTECTED])
ne has their own, of course, for
personalized access and prioritizing control conflicts...)
#g
Graham Klyne
([EMAIL PROTECTED])
intro
the plenary session in Washington DC last November.)
#g
Graham Klyne
([EMAIL PROTECTED])
Graham Klyne
([EMAIL PROTECTED])
the "gold rush" mentality to be the
first to slap a patent on an idea or technique that is coming to be
accepted art in the normal process of technology evolution.
#g
----
Graham Klyne
([EMAIL PROTECTED])
but, for me, the most valuable stuff happens between the sessions.
#g
--------
Graham Klyne
([EMAIL PROTECTED])
rection for a truly global facility, and that it aspires to do so for the
benefit of all the world's people, with equal status and consideration
allowed to any who can participate, from wherever they may originate.
#g
--
Graham Klyne
([EMAIL PROTECTED])
t; and Implementations of Internationalization (i18n) of Domain Names.
> The document(s) should also provide a technical evaluation of the
> proposals by the Working Group.
#g
Graham Klyne
([EMAIL PROTECTED])
http://www.patents.ibm.com/patlist?icnt=US&patent_number=5790790
>
>You would be hard pressed to come up with a more absurd patent...
So one would hope, but ... :-(
(Oh well, back to shuffling deck chairs.)
#g
Graham Klyne
([EMAIL PROTECTED])
multi-homing actually gives us the hope of solving.
>
>
>Only minimally, as long as a TCP connection is tied to an IP address...
>
>d/
>
>ps. Christian and I separately suggested changing this, to support IP
>mobility, a few years ago.
Would IPv6 anycast not be an altern
es, grow
indefinitely.
I don't claim this is a solution to all problems, just suggesting that
application protocol design has a part to play.
#g
Graham Klyne
([EMAIL PROTECTED])
79 matches
Mail list logo
