Subject: PaceUriOrItsSuccessor

From: Mark Pilgrim <[email-masked]>
Date: Wed, 7 Jul 2004 20:32:32 -0400

http://intertwingly.net/wiki/pie/PaceUriOrItsSuccessor

== Abstract ==

[MarkPilgrim] Make all references to RFC 2396 into "RFC 2396 or its
successor" so that when RFC 2396bis is done, Atom can inherit it
without revving the spec.

== Status ==

Open

== Rationale ==

RFC 2396bis adds internationalization support to URIs.  It will become
the new standard for URIs very shortly after its release (it is
already the de facto standard in modern browsers).  Atom should plan
for its arrival by referencing "RFC 2396 or its successor" to define
URIs.

== Proposal ==

In section 3.2.2, change "The content of atom:url in a Person
construct MUST be a  URI [RFC2396]." to "The content of atom:url in a
Person construct MUST be a  URI [RFC2396 or its successor]."

In section 3.4.3, change "Link constructs MUST have a href attribute,
whose value MUST be a URI [RFC2396]." to "Link constructs MUST have a
href attribute, whose value MUST be a URI [RFC2396 or its successor]."

In section 4.8, change "The content of this element, when present,
MUST be a URI." to "The content of this element, when present, MUST be
a URI [RFC2396 or its successor]."

In section 4.9, change "The atom:generator element MAY have a "url" 
attribute whose value MUST be a URI" to "The atom:generator element
MAY have a "url"  attribute whose value MUST be a URI [RFC 2396 or its
successor]"

== Impacts ==

Unknown (FIXME)

== Notes ==

----

CategoryProposals

-- 
Cheers,
-Mark

---

From: Tim Bray <[email-masked]>
Date: Wed, 07 Jul 2004 17:49:54 -0700

On Jul 7, 2004, at 5:32 PM, Mark Pilgrim wrote:

+1, but the rationale could be strengthened by pointing out that 
2396bis has *many* improvements; and we only need to change the 
referent of [2396] in the References section, right?  No need for 
changes in multiple places in the text. -Tim

---

From: Mark Pilgrim <[email-masked]>
Date: Wed, 7 Jul 2004 21:35:37 -0400

On Wed, 07 Jul 2004 17:49:54 -0700, Tim Bray <[email-masked]> wrote:
> 2396bis has *many* improvements;

Perhaps someone more experienced could explain what they are, besides i18n.

>  and we only need to change the

OK, if that's how these things work.

-- 
Cheers,
-Mark

---

From: Tim Bray <[email-masked]>
Date: Wed, 07 Jul 2004 19:44:22 -0700

> Perhaps someone more experienced could explain what they are, besides 

Well, the BNF actually has been tested heavily and can be used to 
generate parsers.  Plus it's got a coherent discussion of how to 
compare URIs.  Plus there's less handwaving about when/how to escape.  
Plus the discussion of what a resource is is less mystical. -Tim

---

From: Martin Duerst <[email-masked]>
Date: Thu, 08 Jul 2004 15:23:44 +0900

Hello Mark,

At 20:32 04/07/07 -0400, Mark Pilgrim wrote:

>RFC 2396bis adds internationalization support to URIs.

I'm somewhat surprised by this statement. I have changed it
to "RFC 2396bis slightly improves internationalization support for URIs."
2396bis is somewhat clearer than 2396 that using UTF-8 for encoding
character into octets is a good thing. It also contains a new section
explaining encoding issues in much more detail. If you want real
internationalization, you need IRIs.

I also added some of the points listed by Tim, except for his
last one, "Plus the discussion of what a resource is is less mystical.",
because the exact definition of 'resource' is still under discussion,
and the result may be in the eye of the beholder (not that it matters
in any way for implementations).

>It will become
>the new standard for URIs very shortly after its release

I don't understand "very shortly after it's release".
How shortly? One week? One month? I just removed  that
phrase, but please feel free to put it back if you can
explain it.

Is the intent of this Pace just to settle between 2396 and 2396bis,
or does it also take a position on whether to use IRIs or not?
If yes, that would just be implicit; I think it should be explicit.

Regards,    Martin.

>(it is

---

From: Martin Duerst <[email-masked]>
Date: Thu, 08 Jul 2004 15:26:26 +0900

>OK, if that's how these things work.

Well, having [2396] in the text, but this then being something different
in the reference section isn't really nice to the reader.

The way to do it that I have been told by a friendly Area Director is
to use something like [RFC XXXX], with instructions to the RFC editor
to fix things up when they know the number. That's also, as far as
I understand, the way to do references between specs that will move
to RFC together.

Regards,    Martin.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 08 Jul 2004 12:21:35 +0200

> without revving the spec.

+1. I agree with Tim that the rationale probably should say more about why  
2396bis is better than 2396, but I'm not one of those who know the details  
of either of the RFC's, unfortunately.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Mark Pilgrim <[email-masked]>
Date: Thu, 8 Jul 2004 08:37:17 -0400

> If yes, that would just be implicit; I think it should be explicit.

The Pace was written yesterday after I got on-list feedback that all
seemed to be converging on the idea of supporting 2396bis to the
exclusion of IRIs.  Now we appear to be diverging from that consensus,
so perhaps the Pace was premature.

-- 
Cheers,
-Mark

---

From: Sam Ruby <[email-masked]>
Date: Thu, 08 Jul 2004 09:02:26 -0400

> so perhaps the Pace was premature.

Suggestion on how to proceed: perhaps Martin or somebody else could 
write up a PaceIri which would contain the precise wording that should 
be included in the Atom spec in anticipation of a future completed IRI 
specification.

This would help in the identification of the specific differences which 
could then be explored.

- Sam Ruby

---

From: Tim Bray <[email-masked]>
Date: Thu, 08 Jul 2004 09:22:25 -0700

> be included in the Atom spec in anticipation of a future completed IRI 

Yes, please. -Tim