Subject: Re: [Uri-review] Request for review of draft-yevstifeyev-view-source-uri-01

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 08 May 2011 07:50:36 +0300

Hello,

Following the advice of Pete Resnick I've composed the registration 
template for this inn a separate document, not Internet-Draft, in order 
not to waste time for production of RFC.  Please let me know whether you 
have any comments to it in order I could ship it to IANA.

The link is: 
https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B1y9iULaT86CMGU3YzEwZWQtMDdiMy00OThmLWI4ZmMtNDRhNTJmNjI1Mjcx&hl=en&authkey=CJaQjNsE

Mykyta Yevstifeyev

23.04.2011 12:29, Mykyta Yevstifeyev wrote:
> Hello,
>
> I'm writing to request the review of my 
> draft-yevstifeyev-view-source-uri-01, that can be found at
>
> http://tools.ietf.org/html/draft-yevstifeyev-view-source-uri-01
>
> This document specifies the 'view-source' URI scheme, that refers to 
> the source code of the resource identified by it.It has long been used 
> without any formal specification and mention at the IANA registry.  My 
> document removes this uncertainty and gives the scheme an official 
> formal definition and registers it in the Provisional category of IANA 
> registry.  All requirements of RFC 4395 for Provisional registrations 
> (http://tools.ietf.org/html/rfc4395#section-3) are suited in the 
> registration template.
>
> Whereas Section 5.2 of RFC 4395 outlines that the review period of 4 
> weeks is OK for permanent registrations, it says nothing about 
> Provisional ones.  I suppose 2 weeks should be fine.  After this 
> period I'll upload a new version of the document (if there are any 
> issues with it) and notify you.
>
> All the best,
> Mykyta Yevstifeyev

---

From: Graham Klyne <[email-masked]>
Date: Mon, 09 May 2011 07:48:59 +0100

As a provisional registration, I think it's broadly fine, but...

My main concern is that it reads more like a normative specification (including 
use of RFC 2119 conventions), and the document itself has the form of an 
Internet-Draft/proto-RFC.  Lacking a separate published document, the 
registration itself would contain *only* the template (section 2), and I think 
this should not be using RFC2119 language.

A secondary, related concern is that I wonder if the registration template goes 
beyond current implemented practice, which it is claimed that this submission is 
intended to document.  Specifically, the URI scheme semantics:  are there any 
implementations that actually return HTML?  (Personally, I think that rather 
defeats the object.)  And the language here is particularly prescriptive, not 
descriptive.

#g
--

Mykyta Yevstifeyev wrote:
> <https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B1y9iULaT86CMGU3YzEwZWQtMDdiMy00OThmLWI4ZmMtNDRhNTJmNjI1Mjcx&hl=en&authkey=CJaQjNsE>
> 
> Mykyta Yevstifeyev
> 
>> the source code of the resource identified by it. It has long been 
>> used without any formal specification and mention at the IANA 
>> registry.  My document removes this uncertainty and gives the scheme 
>> an official formal definition and registers it in the Provisional 
>> category of IANA registry.  All requirements of RFC 4395 for 
>> Provisional registrations

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 09 May 2011 16:08:09 +0300

09.05.2011 9:48, Graham Klyne wrote:
> My main concern is that it reads more like a normative specification 
> (including use of RFC 2119 conventions), and the document itself has 
> the form of an Internet-Draft/proto-RFC.  Lacking a separate published 
> document, the registration itself would contain *only* the template 
> (section 2), and I think this should not be using RFC2119 language.
Ok, then I'll submit a template only to IANA.  However I think we can 
publish  separate RFC (maybe Informational and as Independent 
Submission, but later) being the normative specification of the scheme 
(there is already such a draft - this template is an extract from that 
draft).
>
> A secondary, related concern is that I wonder if the registration 
> template goes beyond current implemented practice, which it is claimed 
> that this submission is intended to document.  Specifically, the URI 
> scheme semantics:  are there any implementations that actually return 
> HTML?  (Personally, I think that rather defeats the object.)  And the 
> language here is particularly prescriptive, not descriptive.
Yes, Mozilla Firefox does in this way (representing HTML).

As for the language style used, it represents the current implementation 
practice and is descriptive, in fact.

Mykyta Yevstifeyev
>> template for this inn a separate document, not Internet-Draft, in 
>> order not to waste time for production of RFC.  Please let me know 
>> whether you have any comments to it in order I could ship it to IANA.
>>
>> The link is:

---

From: Barry Leiba <[email-masked]>
Date: Mon, 9 May 2011 10:21:21 -0400

Assuming the template portion of draft-yevstifeyev-view-source-uri-01
hasn't changed, here are some comments on it.

I'll note first that I have a serious issue with the "semantics"
section, in saying that the result can be rendered as text/html.  See
that comment, in particular.  Apart from that, I find some of it hard
to follow because of the English, and I'm just trying to be helpful in
fixing those bits.

   o URI Scheme Name:  view-source

   o Status:  Provisional

I'll note here, not related to this document at all, but as a general
point, that I find "provisional" to be a VERY unfortunate choice in
the naming of this registry.  We haven't, for the most part, really
defined permanent and provisional registries, but, rather, "high rent"
and "low rent" registries.  This URI scheme, for example, is not
expected to go away or be upgraded (to "permanent") at some point,
which would fit the meaning of "provisional".

But never mind; that horse has long run away, and it doesn't affect
this document.  Sorry for the diversion.

   o URI Scheme Semantics:  The application resolving the 'view-source'
     URI SHALL return the source code of the resource, identified by
     <absolute-URI>.  Each application implementing the 'view-source'
     URI scheme is permitted to choose how the source code is displayed.
      However this specification recommends that it SHOULD be
     represented in the media type "text/plain" [RFC2046] or "text/html"
     [RFC2854] and the character encoding "UTF-8" [RFC3629].

This is VERY misleading; a renderer that actually retrieves, say,
"view-source:http://ietf.org", and renders it as text/html, would
display exactly the same thing as "http://ietf.org".

What this MEANS to convey is that the data returned by the
<absolute-URI> is meant to be displayed as is, without normal HTML (or
XML, or whatever) processing.  This needs to say that clearly, and it
doesn't.  I don't really have suggested text for this, because I think
it's hard to explain in text -- we all know what we want it to do, but
we have to document it for others.  But what's here absolutely will
not fly.

Moreover, I think talking about the media-type that should be used to
display it isn't really relevant, and only confuses the explanation.
Hm.  Maybe something like "Each application implementing the
'view-source' URI scheme is permitted to choose how the source code is
displayed, keeping in mind that it's meant to display the data as
retrieved, without normal rendering, layout, or other formatting."
The mention of character encoding is probably fine.

     Per RFC 4395, not all URI schemes are used to refer to a particular
     piece of information (a resource), but rather identify the endpoint
     for establishing connection (for instance, the 'telnet' URI scheme
     [RFC4248]) or performing other actions (such as sending an e-mail
     message [RFC5322] using the 'mailto' URI scheme [RFC6068]).
     Therefore if the 'view-source' URI refers to such URI (e. g.
     <view-source:tel:+1-201-555-0123> with a 'tel' URI [RFC3966] in the
     <absolute-URI> part), such URI SHALL be resolved to the resource of
     zero length, containing no data, with the media type "text/plain"
     [RFC2046] and the character encoding "UTF-8" [RFC3629].

Why not recommend that it be rendered simply as the raw URI
(<view-source:tel:+1-201-555-0123> renders as "tel:+1-201-555-0123")?
That seems more sensible, and can certainly be a way to encourage
implementations to switch to that method.

     This specification does not set any restrictions on how the
     applications shall resolve such URIs as
     <view-source:view-source:example://example.com>, i. e. with the
     "view-source:" prefixed more than once.  However it recommends that
     such URIs SHOULD be resolved to the resource of zero length,
     containing no data, with the media type "text/plain" [RFC2046] and
     the character encoding "UTF-8" [RFC3629]

Why not recommend that it be handled as a pass-through, so multiple
"view-source:" prefixes collapse into one?  That seems more sensible,
and can certainly be a way to encourage implementations to switch to
that method.

   o Encoding Considerations:  There are no other encoding
     considerations for 'view-source' URIs not discussed in RFC 3986
     [RFC3986]

"There are no encoding considerations for 'view-source' URIs other
than those discussed in RFC 3986."

   o Applications and Protocols that Use this URI Scheme Name:  The
     'view-source' URIs is generally used by web-browsers.  However this
     document does not place the limit on where else they can be used.

     See Wikipedia's entry on "View-source URI scheme"
     [WIKI-VIEW-SOURCE] for the up-to-date list of browser support
     information

It seems a bit dicey to use a Wikipedia reference, though I certainly
see why one wants to.  The problem is that anyone can alter/vandalize
the Wikipedia entry, and an implementor looking at that at the wrong
time might get the wrong idea.  But maybe this isn't really a problem.

   o Interoperability Considerations:  The 'view-source' URI may
     sometimes refer to the source code that is under certain legal
     provisions, according to which an individual or a company may not
     have granted the free access or other actions with regard to it.
     The users of such information should be careful regarding these
     matters

"The <absolute-URI> might sometimes refer to source code that is under
certain legal provisions, which might not grant free access, or which
might place other restrictions on the use of the source code.  The
users of such information should be careful regarding these matters."

   o Security Considerations:  Security considerations for 'view-source'
     URIs are discussed in Section 3 of this document

Since you're folding what's in the I-D into the template, here are the
security considerations:

   The 'view-source' URIs may sometimes reveal the information (source
   code) that is a governmental, trade or other type of secret and,
   therefore, disclose confidential information.  It can also sometimes
   refer to the source code that is under certain legal provisions,
   according to which an individual or a company may not have granted
   the free access or other actions with regard to it.  The users of
   such information should be careful with regard to these matters.

Grammar: where you say "the source code", make it "source code".
Content: The second part of this duplicates what's in the
Interoperability Considerations.  The first part seems strange: this
URI scheme doesn't allow anyone to access anything they can't
otherwise access.  So this URI scheme doesn't expose secrets that
aren't already exposed by the <absolute-URI> itself.  I think that
first sentence is entirely wrong.

--
Barry

---

From: Graham Klyne <[email-masked]>
Date: Tue, 10 May 2011 08:29:55 +0100

Mykyta,

FYI, I was just formally asked to review this for provisional registration, and 
gave the nod on the basis that in its present form it really is provisional (and 
some documentation of existing practice being better than none at all).  But I 
still have problems with the way normative language is used, and if the document 
doesn't make it through independent RFC submission, the registration should 
probably be dropped when the I-D expires.

If others feel the normative language is OK in an informational document like 
this, then I'm prepared to drop this objection.

For more detail, see my separate response to Barry's message.

#g
--

Mykyta Yevstifeyev wrote:
> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>

---

From: Graham Klyne <[email-masked]>
Date: Tue, 10 May 2011 08:23:54 +0100

> this document.  Sorry for the diversion.

(The choice of terminology may be sub-optimal - and I probably bear some 
indirect historical responsibility for this - but the intent was to convey a 
clear message that implementers should not be depending on the registration as a 
basis of long-term interoperability.  I suppose we kinda felt it may be the 
worst possible term except for all of the others we considered :) )

> retrieved, without normal rendering, layout, or other formatting."

+1 - I was uneasy with this on first pass, but only later did I realize my real 
problem with it.  Given that view-source: is handled locally as a rendering 
function, I'm not sure it really makes sense to describe its behaviour in terms 
of MIME content-types.

Also, as an editorial matter, I'd prefer to see the "scheme semantics" (at least 
in its current form) moved out of the template into the document body and 
referenced from the template.  This is because it contains RFC2119 normative 
language that I think is not really appropriate in the registration template 
(which, in principle if not often in practice, I feel should be publishable 
separately from from the scheme documentation, and as such not be subject to the 
document's terminological conventions).

This question of normative terminology goes further.  I personally don't think 
its appropriate to include normative terminology in an informational document 
whose purpose is to describe existing practice rather than to prescribe new 
practice.  As such, I think the abstract and introduction should also say 
"describes" rather than "specifies".

Maybe this is me being over-sensitive, but I feel the tone of this document is 
veering rather close to trying to introduce a new standard by the back door.  If 
  you really want to introduce this as a new, standard, recommended practice, 
then I think it should go through a full review process.  But this has already 
been discussed, and as I recall there's no sense of need in the IETF to push 
this as a standard.  So I would suggest that the language be toned down to be 
clearly descriptive rather than normative.

> time might get the wrong idea.  But maybe this isn't really a problem.

If it's descriptive (informative) rather than normative, I don't see this as a 
real problem.

#g
--

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 10 May 2011 17:38:58 +0300

10.05.2011 10:23, Graham Klyne wrote:
> (The choice of terminology may be sub-optimal - and I probably bear 
> some indirect historical responsibility for this - but the intent was 
> to convey a clear message that implementers should not be depending on 
> the registration as a basis of long-term interoperability.  I suppose 
> we kinda felt it may be the worst possible term except for all of the 
> others we considered :) )
Barry, IRI WG is currently working on 4395bis.  You may present this 
terminology issue to them.
> +1 - I was uneasy with this on first pass, but only later did I 
> realize my real problem with it.  Given that view-source: is handled 
> locally as a rendering function, I'm not sure it really makes sense to 
> describe its behaviour in terms of MIME content-types.
>
> Also, as an editorial matter, I'd prefer to see the "scheme semantics" 
> (at least in its current form) moved out of the template into the 
> document body and referenced from the template.  This is because it 
> contains RFC2119 normative language that I think is not really 
> appropriate in the registration template (which, in principle if not 
> often in practice, I feel should be publishable separately from from 
> the scheme documentation, and as such not be subject to the document's 
> terminological conventions).
>
> This question of normative terminology goes further.  I personally 
> don't think its appropriate to include normative terminology in an 
> informational document whose purpose is to describe existing practice 
> rather than to prescribe new practice.  As such, I think the abstract 
> and introduction should also say "describes" rather than "specifies".
>
> Maybe this is me being over-sensitive, but I feel the tone of this 
> document is veering rather close to trying to introduce a new standard 
> by the back door.  If  you really want to introduce this as a new, 
> standard, recommended practice, then I think it should go through a 
> full review process.  But this has already been discussed, and as I 
> recall there's no sense of need in the IETF to push this as a 
> standard.  So I would suggest that the language be toned down to be 
My initial intend was to publish this as IETF stream RFC.  I asked Pete 
to sponsor it, but received a refusal with a proposal to consider 
sending the template only.  Then I Applied to Independent Submissions 
Editor to consider this an Independent submission, but then asked to 
postpone the submission with the intent to resubmit it in 2-3 weeks.  
Then I asked IANA to resgiter the scheme with reference to the draft 
considering it to become an RFC soon.

I repeat I've asked IANA to register the scheme according to the draft, 
not separate template.  Currently I think it is OK to use normative 
language here.

As for HTML.  Mozilla is currently using HTML for representing source 
code in different colors.  Also, this is a recommendation only, not 
norm.  However, if there is a consensus, I can remove any regulations on 
some definite type of resource for resolving view-source URIs.
>> implementations to switch to that method.
Current implementations do in the way I described.  I see no sense in 
recommending them to change this behavior.
>> and can certainly be a way to encourage implementations to switch to
The same as above.
>> than those discussed in RFC 3986."
OK, I'll change.
> If it's descriptive (informative) rather than normative, I don't see 
> this as a real problem.
+1.
> #g
Not an absolute-URI but the view-source URI itself; absolute-URI refers 
to the result of handling the source code.
>> Grammar: where you say "the source code", make it "source code".
OK.
>> first sentence is entirely wrong.
See above for draft vs. template discussion.

As for your content comments, I'll think on some other text and notify 
you then.

Mykyta Yevstifeyev

---

From: Barry Leiba <[email-masked]>
Date: Tue, 10 May 2011 11:19:09 -0400

> As for HTML.  Mozilla is currently using HTML for representing source code
> in different colors.  Also, this is a recommendation only, not norm.
>  However, if there is a consensus, I can remove any regulations on some
> definite type of resource for resolving view-source URIs.

You're totally missing the point here.  It's not about what media-type
the browser uses to display it.  It's about making it clear that the
whole point here is *not* to do typical HTML rendering, but to display
the HTML (or whatever) raw.  Unless you make that clear, you haven't
written useful documentation of this.  And once you've done that,
there's no reason at all to talk about whether or not the browser
might use HTML for colours, highlighting, and whatever.

> Not an absolute-URI but the view-source URI itself; absolute-URI refers to
> the result of handling the source code.

No.  The view-source URI is a local thing.  The <absolute-URI> to
which it refers is the source of the source.  Oy, that's confusing;
I'll try again: The <absolute-URI> to which it refers is where the
source code is coming from.  So it's *that* to which you have to refer
here.  All the "view-source" part is doing is telling the local
software NOT to do the normal rendering, but to show the raw source
code.

In fact, it would be useful to point out, somewhere, that the
view-source scheme is not providing any information that isn't already
available, but is only a way to control the method by which that
information is displayed.  This is related to my comment on the

Barry

---

From: Pete Resnick <[email-masked]>
Date: Tue, 10 May 2011 16:36:41 -0500

On 5/10/11 9:38 AM, Mykyta Yevstifeyev wrote:
>> Also, as an editorial matter, I'd prefer to see the "scheme 
>> semantics" (at least in its current form) moved out of the template 
>> into the document body and referenced from the template.  This is 
>> because it contains RFC2119 normative language that I think is not 
>> really appropriate in the registration template (which, in principle 
>> if not often in practice, I feel should be publishable separately 
>> from from the scheme documentation, and as such not be subject to the 
>> document is veering rather close to trying to introduce a new 
>> standard by the back door.  If  you really want to introduce this as 
>> a new, standard, recommended practice, then I think it should go 
>> through a full review process.  But this has already been discussed, 
>> and as I recall there's no sense of need in the IETF to push this as 
>> a standard.  So I would suggest that the language be toned down to be 

Absolutely agreed. In fact, I would go even further: I don't think this 
should be a document at all, but simply a registration template. I don't 
see any need for the normative language. You are describing an existing 
practice, not defining protocol and not giving conformance requirements. 
Make this a template and do not put it in the form of a document. Send 
the template in email; no need for a Google doc.

> My initial intend was to publish this as IETF stream RFC.  I asked 
> Pete to sponsor it, but received a refusal with a proposal to consider 
> sending the template only.

Yes. I don't think it makes sense to submit this as Informational (even 
if you removed the normative language as people have mentioned on this 
list). The informational part of this is, "This URI scheme is being 
used, and here's a description of how it's being used." That, and the 
security considerations, can all fit in the template.

> Then I Applied to Independent Submissions Editor to consider this an 
> Independent submission, but then asked to postpone the submission with 
> the intent to resubmit it in 2-3 weeks.  Then I asked IANA to resgiter 
> the scheme with reference to the draft considering it to become an RFC 
> soon.
>
> I repeat I've asked IANA to register the scheme according to the 
> draft, not separate template.  Currently I think it is OK to use 
> normative language here.

It seems to me that you're trying to end-around IETF process and I'm not 
quite clear why. If you remove the normative language, you can send IANA 
the template and be done with it. If you include normative language, 
then I think you're writing something worthy of standards track and it 
should be submitted through normal IETF consensus processes, not through 
the ISE.

Why do you think the normative language is at all necessary? Why do you 
think a document is necessary?

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 11 May 2011 18:54:56 +0300

Hello all again,

I've reworded my template to avoid use of 2119 language and make it more 
descriptive.  Find it below:

>           The 'view-source' URI Scheme Registration Template
>
>  Submitter:  Mykyta Yevstifeyev <[email-masked]>
>
>  Version:  1
>
>  Date:  11 May, 2011
>
> ----------------------------------------------------------------------
>
> o URI Scheme Syntax:  The 'view-source' URI takes the form of the
> <view-source-uri> rule below, defined in ABNF [RFC5234]:
>
>   view-source-uri = "view-source:" absolute-URI
>
>   where the <absolute-URI> rule is defined in Appendix A of
>   RFC 3986 [RFC3986]
>
> o URI Scheme Semantics:  The 'view-source' URI is resolved the
>   source code of the resource, identified by <absolute-URI>.
>   Each application implementing the 'view-source' URI scheme
>   is permitted to choose how the source code is displayed.
>   The current practice is to represent the source code as a plain
>   text with the UTF-8 character encoding [RFC3629].
>
>   Current implementations resolve the 'view-source' URIs with URIs
>   that do not identify the resource but rather an endpoint for
>   establishing a connection, etc. (such as 'telnet' URIs [RFC4248])
>   in the <absolute-URI> via displaying a resource representing blank
>   page.  URIs with "view-source:" prefixed more than once are usually
>   resolved in the same way.
>
> o Encoding Considerations:  There are no encoding considerations for
>   'view-source' URIs other than those discussed in RFC 3986 [RFC3986]
>
>   'view-source' URIs is generally used by web-browsers.
>
>   See Wikipedia's entry on "View-source URI scheme" [WIKI-VIEW-SOURCE]
>   for the up-to-date list of browser support information
>
> o Interoperability Considerations:  The <absolute-URI> might sometimes
>   refer to source code that is under certain legal provisions, which
>   might not grant free access, or which might place other restrictions
>   on the use of the source code.  The users of such information should
>   be careful regarding these matters.
>
> o Security Considerations:  General security consideration for URIs
>   are discussed in RFC 3986 [RFC3986].  See also Interoperability
>   Considerations field of this template for some issues concerning
>   security
>
> o Contact:  Mykyta Yevstifeyev <[email-masked]>
>
> o Author/Change Controller:  Mykyta Yevstifeyev <[email-masked]>
>
> o References:
>
> [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
>               10646", STD 63, RFC 3629, November 2003.
>
> [RFC3986]     Berners-Lee, T., Fielding, R., and L. Masinter,
>               "Uniform Resource Identifier (URI): Generic Syntax", STD 66,
>               RFC 3986, January 2005.
>
> [RFC4248]     Hoffman, P., "The telnet URI Scheme", RFC 4248, October
>               2005.
>
> [RFC5234]     Crocker, D., Ed., and P. Overell, "Augmented BNF for
>               Syntax Specifications: ABNF", STD 68, RFC 5234, January
>               2008.
>
> [WIKI-VIEW-SOURCE]
>               Wikipedia Contributors, "View-source URI scheme,"
>               Wikipedia, The Free Encyclopedia, March 2011.
> <http://en.wikipedia.org/wiki/View-source_URI_scheme>
>
> -------------------------------------------------------------------------
>
> Acknowledgments
>
>   Valuable comments on Version 1 of this template were provided by
>   the following people: Barry Leiba

Now it has no standards-like certain regulations on media 
types/character encodings; URI scheme semantics was made more brief; 
removed some obscure regulations from Security Considerations; other 
editorial improvements made.  Please let me know if you have any 
comments on it in order I could submit it to IANA.

Mykyta Yevstifeyev

---

From: Graham Klyne <[email-masked]>
Date: Wed, 11 May 2011 18:41:28 +0100

That resolves the concerns I expressed.  Thanks.

#g
--

---

From: Barry Leiba <[email-masked]>
Date: Wed, 11 May 2011 14:11:19 -0400

Graham says...

Me too.  Only thing now is rewording this:

> URI Scheme Semantics:  The 'view-source' URI is resolved the

That doesn't parse in English.  I'm guessing this:

"The 'view-source' URI resolves to the source code of the resource
identified by <absolute-URI>."

Barry

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 12 May 2011 11:17:45 +0300

2011/5/11, Barry Leiba <[email-masked]>:
> Me too.
Ok, then I'll submit this template to IANA.
> Only thing now is rewording this:
>
I don't object to any of these texts; however current seems better to
me.  An application resolves an URI so an URI is resolved by it.

Mykyta Yevstifeyev

---

From: Barry Leiba <[email-masked]>
Date: Thu, 12 May 2011 08:07:26 -0400

> me.  An application resolves an URI so an URI is resolved by it.

Trust me, Mykyta: I don't know whether my sentence is exactly what you
want, but I can assure you that yours is not proper English, and is
not understandable.  It needs to be re-worded one way or another.

Barry

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 12 May 2011 19:59:35 +0300

12.05.2011 15:07, Barry Leiba wrote:
>>>> source code of the resource, identified by<absolute-URI>.
>>> identified by<absolute-URI>."
>>>
I give up :-)  So I've already submitted the template to IANA; I'll ask 
them to correct this sentence.

Mykyta Yevstifeyev