Robert Sayre wrote:
On 5/16/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
Too terse - I don't understand why you're asking this. But if you really
think that we allow everything we don't ban, we should say that
somewhere in the spec.
hmm. I could write that Pace if you want, but maybe it would be mo
On 5/16/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
>
> Too terse - I don't understand why you're asking this. But if you really
> think that we allow everything we don't ban, we should say that
> somewhere in the spec.
hmm. I could write that Pace if you want, but maybe it would be more
product
Robert Sayre wrote:
On 5/16/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
Only, and this is not a joke, if you agree to add the text "What this
specification doesn't ban, it allows". Let's leave no room for doubt as
to the spirit of interpretation.
"Future versions of this specification could add ne
On 5/16/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
>
> Only, and this is not a joke, if you agree to add the text "What this
> specification doesn't ban, it allows". Let's leave no room for doubt as
> to the spirit of interpretation.
"Future versions of this specification could add new elements
Robert Sayre wrote:
On 5/16/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
The spec allows anyone to add stuff to the Atom namespace, so the IETF
will have to read everyone's documents before they add something to
the Atom namespace.
The spec does no such thing; that's a psychotic interpretation at be
On 5/16/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
> >
> > The spec allows anyone to add stuff to the Atom namespace, so the IETF
> > will have to read everyone's documents before they add something to
> > the Atom namespace.
>
> The spec does no such thing; that's a psychotic interpretation at
Robert Sayre wrote:
On 5/16/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
Robert Sayre wrote:
On 5/16/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
I can think of a couple things. One would be collisions (which Sam
mentioned).
I don't understand- maybe I'm looking at the wrong post?
http://www.imc.org
On 5/16/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
> Robert Sayre wrote:
> > On 5/16/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
> >
> >
> >>>I can think of a couple things. One would be collisions (which Sam
> >>>mentioned).
> >>
> >>I don't understand- maybe I'm looking at the wrong post?
> >>
Robert Sayre wrote:
On 5/16/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
I can think of a couple things. One would be collisions (which Sam
mentioned).
I don't understand- maybe I'm looking at the wrong post?
http://www.imc.org/atom-syntax/mail-archive/msg15236.html
Sam is saying that the IETF can
On May 16, 2005, at 12:30 PM, Sam Ruby wrote:
...
My trip...
My trip to the beach
http://example.org";>
Does the same principle apply to attributes?
If a validator can't catch typos, what's left?
It would be perfectly OK and expected for a validator to emit an
"unrecognized element" diagnos
On 5/16/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
> > I can think of a couple things. One would be collisions (which Sam
> > mentioned).
>
> I don't understand- maybe I'm looking at the wrong post?
>
> http://www.imc.org/atom-syntax/mail-archive/msg15236.html
Sam is saying that the IETF can'
Robert Sayre wrote:
On 5/16/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
Robert Sayre wrote:
On 5/16/05, Tim Bray <[EMAIL PROTECTED]> wrote:
My problem is that putting text in the format spec saying "Nobody but
the IETF can extend the namespace" feels empty and useless, are we
going to send Marshal
Robert Sayre wrote:
On 5/16/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
Robert Sayre wrote:
On 5/16/05, Tim Bray <[EMAIL PROTECTED]> wrote:
My problem is that putting text in the format spec saying "Nobody but
the IETF can extend the namespace" feels empty and useless, are we
going to send Marshall
On 5/16/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
> Robert Sayre wrote:
> > On 5/16/05, Tim Bray <[EMAIL PROTECTED]> wrote:
> >
> >>
> >>My problem is that putting text in the format spec saying "Nobody but
> >>the IETF can extend the namespace" feels empty and useless, are we
> >>going to send
Tim Bray wrote:
On May 16, 2005, at 10:44 AM, Robert Sayre wrote:
I am not looking for a repeat of that discussion. Atom 1.0 Processors
cannot distinguish between markup added later on by the IETF and
markup added by a third party, so the processing rules must remain as
they are. That doesn't mean
Robert Sayre wrote:
On 5/16/05, Tim Bray <[EMAIL PROTECTED]> wrote:
My problem is that putting text in the format spec saying "Nobody but
the IETF can extend the namespace" feels empty and useless, are we
going to send Marshall Rose over to beat up anyone who tries?
It will happen and we won't b
On 5/16/05, Tim Bray <[EMAIL PROTECTED]> wrote:
> On May 16, 2005, at 10:44 AM, Robert Sayre wrote:
>
> > I am not looking for a repeat of that discussion. Atom 1.0 Processors
> > cannot distinguish between markup added later on by the IETF and
> > markup added by a third party, so the processing
On May 16, 2005, at 10:44 AM, Robert Sayre wrote:
I am not looking for a repeat of that discussion. Atom 1.0 Processors
cannot distinguish between markup added later on by the IETF and
markup added by a third party, so the processing rules must remain as
they are. That doesn't mean we should allow
On 16 May 2005, at 5:59 pm, Tim Bray wrote:
i)
Don't you think the Feed Validator should flag my example as invalid?
No.
ii)
I actually thought that what we meant was what the spec said, and
that this was the (very reasonable) outcome of our discussion on
MustUnderstand. That means that if th
> On 5/16/05, Tim Bray <[EMAIL PROTECTED]> wrote:
>> Don't you think the Feed Validator should flag my example as invalid?
> No. I actually thought that what we meant was what the spec said, and
> that this was the (very reasonable) outcome of our discussion on
> MustUnderstand.
I don't think
On Monday, May 16, 2005, at 10:59 AM, Tim Bray wrote:
On May 16, 2005, at 6:27 AM, Robert Sayre wrote:
On 5/16/05, Tim Bray <[EMAIL PROTECTED]> wrote:
The benefit the Web derived from HTML's
implicit-but-universally-implemented MustIgnore rule; it introduced
enough slack into the system that peopl
On May 16, 2005, at 6:27 AM, Robert Sayre wrote:
On 5/16/05, Tim Bray <[EMAIL PROTECTED]> wrote:
The benefit the Web derived from HTML's
implicit-but-universally-implemented MustIgnore rule; it introduced
enough slack into the system that people could experiment without
breaking things.
Don't you
On 5/16/05, Tim Bray <[EMAIL PROTECTED]> wrote:
>
> The benefit the Web derived from HTML's
> implicit-but-universally-implemented MustIgnore rule; it introduced
> enough slack into the system that people could experiment without
> breaking things.
Don't you think the Feed Validator should flag
Tim Bray wrote:
On May 15, 2005, at 9:43 PM, Robert Sayre wrote:
Legal? Which part of the spec rules it out?
No part. Per
http://www.atompub.org/2005/04/18/draft-ietf-atompub-format
-08.html#rfc.section.6.2 it's unknown foreign markup, with clear rules
for how to handle it, right?
Yes, there a
On May 15, 2005, at 9:43 PM, Robert Sayre wrote:
Legal? Which part of the spec rules it out?
No part. Per
http://www.atompub.org/2005/04/18/draft-ietf-atompub-format
-08.html#rfc.section.6.2 it's unknown foreign markup, with clear rules
for how to handle it, right?
Yes, there are clear parsing
On May 10, 2005, at 9:14 PM, Robert Sayre wrote:
...
...
Legal? Which part of the spec rules it out?
No part. Per
http://www.atompub.org/2005/04/18/draft-ietf-atompub-format
-08.html#rfc.section.6.2 it's unknown foreign markup, with clear rules
for how to handle it, right? -Tim
On 5/15/05, Tim Bray <[EMAIL PROTECTED]> wrote:
> On May 10, 2005, at 9:14 PM, Robert Sayre wrote:
>
> >
> >...
> >
> >...
> >
> >
> > Legal? Which part of the spec rules it out?
>
> No part. Per
> http://www.atompub.org/2005/04/18/draft-ietf-atompub-format
> -08.html#rfc.section.
At 7:44 PM +0900 5/11/05, Martin Duerst wrote:
Many thanks for the citations below, this is extremely clear.
Going back to the original question/pace that you gave a -1,
would that change if in the text "IETF Consensus" was
replaced with "IESG Approval"?
Yup.
--Paul Hoffman, Director
--Internet Mai
Hello Paul,
Many thanks for the citations below, this is extremely clear.
Going back to the original question/pace that you gave a -1,
would that change if in the text "IETF Consensus" was
replaced with "IESG Approval"?
Regards, Martin.
At 10:56 05/05/11, Paul Hoffman wrote:
>
>At 4:15 PM +0900
On May 11, 2005, at 21:54, Antone Roundy wrote:
* HTML has no concept of namespaces, so when people invent a new tag,
they don't give it a unique prefix. XML has namespaces, so when
inventing new elements, common sense and past experience suggest
putting them in a namespace under the control of
On Wednesday, May 11, 2005, at 12:11 PM, Paul Hoffman wrote:
...
...
Legal? Which part of the spec rules it out? Maybe I've read it too
many times and I'm missing something. Common sense would seem to
outlaw it, but that's not good enough.
Hearing from as many people who feel that they
At 12:14 AM -0400 5/11/05, Robert Sayre wrote:
On 5/9/05, Robert Sayre <[EMAIL PROTECTED]> wrote:
I am fine with that. I am concerned that the current draft fails to
differentiate between "foreign markup" and "markup that requires IESG
approval".
I am going to try this again, because it's import
On 5/9/05, Robert Sayre <[EMAIL PROTECTED]> wrote:
> I am fine with that. I am concerned that the current draft fails to
> differentiate between "foreign markup" and "markup that requires IESG
> approval".
I am going to try this again, because it's important.
...
...
Legal? Which
At 4:15 PM +0900 5/10/05, Martin Duerst wrote:
What's the difference between "IETF consensus" (for which you gave a -1)
and "it's up to the IESG" (which seems what you think we should let happen)?
From RFC 2434:
IESG Approval - New assignments must be approved by the IESG, but
ther
Hello Paul,
What's the difference between "IETF consensus" (for which you gave a -1)
and "it's up to the IESG" (which seems what you think we should let happen)?
In my view, "IETF consensus" is another way of saying the IESG has the
last word. If there is a better way to express this in the spec, t
On 5/9/05, Paul Hoffman <[EMAIL PROTECTED]> wrote:
> >Fair enough. But can just anyone add stuff to the Atom namespace?
>
> If the IESG lets them, yes.
>
> We gotta trust the IESG after the WG shuts down. Fortunately, they
> have earned that trust over time.
I am fine with that. I am concerned
At 7:22 PM -0700 5/9/05, Tim Bray wrote:
On May 9, 2005, at 6:52 PM, Robert Sayre wrote:
I think we should be clearer that new elements in the Atom namespace
and unprefixed attributes with parent elements in the Atom namespace
can only be added by IETF consensus. Thoughts?
I wonder if there's some
On 5/9/05, Tim Bray <[EMAIL PROTECTED]> wrote:
> I wonder if there's some standard IETF practice when you define a
> language as regards future change control?
>
> Generally -1. This spec defines what Atom 1.0 is, why try to
> micro-manage the future?
Fair enough. But can just anyone add stu
On May 9, 2005, at 6:52 PM, Robert Sayre wrote:
I think we should be clearer that new elements in the Atom namespace
and unprefixed attributes with parent elements in the Atom namespace
can only be added by IETF consensus. Thoughts?
I wonder if there's some standard IETF practice when you define a
39 matches
Mail list logo
