Subject: Re: Review of Content-Encoding: value token [exi]

From: "John Schneider" <[email-masked]>
Date: Sun, 23 Aug 2009 21:52:20 -0700

Dear HTTPbis,
 
Thank you for your careful review and consideration of the W3C EXI working
group's proposal for a new HTTP content coding token. In reviewing this
thread, I see there have been some initial questions and concerns regarding
the proposal and that some of these may have already been addressed through
the course of discussion. While evaluating various options for EXI content
coding, the W3C EXI working group has had similar discussions both
internally and with W3C Technical Architecture Group (TAG) members. As part
of our evaluation, we considered other alternatives, such as the use of a
specific application/exi media type, a parameterized media-type and media
types of the form svg+exi; however, the EXI content coding solution turned
out to be the lesser of several evils that best satisfied our requirements
and use cases. 
 
While there seems to be a general preference that content codings be
octet-preserving, we noted that the current definition provides the
flexibility to support content codings that are not strictly
octet-preserving. We also noted there the IANA content coding registry
already contains a precedent for this [1]. In particular, the pack200
content coding is not byte preserving.
 
In speaking with Mark Nottingham last week, I understand HTTPbis will be
re-instating the registry for HTTP content coding value tokens and reviewing
requests for new content codings. The W3C EXI working group would like to
submit a request to register the value token "exi" as a new content coding.
They have asked me to work with you to answer questions about this request
and elaborate as needed regarding our use cases and rationale. 
 
Would it be possible to add this request to you current list of work items?
 
    Respectfully,
 
    John
 
[1] http://www.iana.org/assignments/http-parameters
 
Editor, W3C EXI specification
 <mailto:[email-masked]> [email-masked]
 <http://www.agiledelta.com> http://www.agiledelta.com

Re: Review of Content-Encoding: value token

*	This message: [ Message body
<http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0779.html#start
779>  ] [ Respond
<mailto:[email-masked]?Subject=Re%3A%20Review%20of%20Content-Encoding%3
A%20value%20token&In-Reply-To=%253C1245887149.9223.192.camel%40localhost.loc
aldomain%253E&References=%253C1245887149.9223.192.camel%40localhost.localdom
ain%253E>  ] [ More
<http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0779.html#optio
ns3> options ] 

*	Related messages: [ Next
<http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0780.html>
message ] [ Previous
<http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0778.html>
message ] 

From: Henrik Nordstrom <[email-masked]
<mailto:[email-masked]?Subject=Re%3A%20Review%20of%20Content-Enc
oding%3A%20value%20token&In-Reply-To=%253C1245887149.9223.192.camel%40localh
ost.localdomain%253E&References=%253C1245887149.9223.192.camel%40localhost.l
ocaldomain%253E> > 
Date: Thu, 25 Jun 2009 01:45:49 +0200
To: David Morris <[email-masked]
<mailto:[email-masked]?Subject=Re%3A%20Review%20of%20Content-Encoding%3A%20va
lue%20token&In-Reply-To=%253C1245887149.9223.192.camel%40localhost.localdoma
in%253E&References=%253C1245887149.9223.192.camel%40localhost.localdomain%25
3E> > 
Cc: [email-masked]
<mailto:[email-masked]?Subject=Re%3A%20Review%20of%20Content-Encoding%3
A%20value%20token&In-Reply-To=%253C1245887149.9223.192.camel%40localhost.loc
aldomain%253E&References=%253C1245887149.9223.192.camel%40localhost.localdom
ain%253E>  
Message-Id: <[email-masked]> 

tor 2009-01-22 klockan 22:40 -0800 skrev David Morris:

> Exact reconstruction is always safest. But it seems to me that a new 

> encoding for an html (or xml) document which stripped trailing blanks and 

> tabs might satisfy the above constraints. Since ETag creation is the 

> responsiblity of the origin server, I don't think the transformation I

> describe would matter. The ETag would need to change if the pre-encoding 

> content changed.

Note: Content-Encoding changes REQUIRES ETag to change as well, even for

weak etags. Two repesentations of the same URI with different

Content-Encoding MUST NOT share the same ETag. ETag selection is AFTER

content-encoding, not before.

HTTP as such does not really care what kinds of transforms

Content-Encoding applies. The genereal expectation is that it's a

lossless transform, but this is not a requirement and do not need to be

a requirement.

Regards

Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 24 Aug 2009 11:41:15 +0200

sön 2009-08-23 klockan 21:52 -0700 skrev John Schneider:

> In speaking with Mark Nottingham last week, I understand HTTPbis will
> be re-instating the registry for HTTP content coding value tokens and
> reviewing requests for new content codings. The W3C EXI working group
> would like to submit a request to register the value token "exi" as a
> new content coding. They have asked me to work with you to answer
> questions about this request and elaborate as needed regarding our use
> cases and rationale. 

I am not aware of any planned changes in the content encoding registry
procedure. Mark, did you mix this up with the upgrade registry?

But you are imho welcome to actively include HTTPbis for preleminary
review of your specification before submission to IANA even if the
specification as such is outside the scope of HTTPbis.

Regards
Henrik

---

From: "John Schneider" <[email-masked]>
Date: Mon, 24 Aug 2009 12:06:25 -0700

Henrik,

Thank you for your quick response to my message. It is quite possible that
this is my mistake and I misunderstood Mark. If it is more appropriate for
us to follow the current IANA process for registration, we would be very
happy to do that. Of course, we are also very interested in any further
comments from HTTPbis on the topic even it does not end up your action list.

I really appreciate your thoughts and inputs on this topic. 

	All the best!,

	John

> -----Original Message-----
> From: Henrik Nordstrom [mailto:[email-masked]] 
> Sent: Monday, August 24, 2009 2:41 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Review of Content-Encoding: value token [exi]
> 
> I am not aware of any planned changes in the content encoding 
> registry procedure. Mark, did you mix this up with the 
> upgrade registry?
> 
> But you are imho welcome to actively include HTTPbis for 
> preleminary review of your specification before submission to 
> IANA even if the specification as such is outside the scope 
> of HTTPbis.
> 
> Regards
> Henrik
>

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 24 Aug 2009 23:26:02 +0200

> comments from HTTPbis on the topic even it does not end up your action list.

For registration you need to follow the defined IANA process.

It's an extension, and extensions to HTTP is not in scope for HTTPbis at
the moment. Our task is to get RFC2616 + parts of other closely related
standards track documents cleaned up and in good shape, and explicitly
forbidden to add extensions unless deemed absolutely required to correct
errors or serious shortcomings in the earlier specifications.

Regards
Henrik

---

From: "John Schneider" <[email-masked]>
Date: Mon, 24 Aug 2009 14:55:10 -0700

Henrik,

Thank you again for the quick response and clear guidance. This makes a lot
of sense. I will let the EXI working group know and follow the defined IANA
process for registration. 

	Best wishes,

	John

> Sent: Monday, August 24, 2009 2:26 PM
> Subject: RE: Review of Content-Encoding: value token [exi]
> 
> > Thank you for your quick response to my message. It is 
> quite possible 
> > that this is my mistake and I misunderstood Mark. If it is more 
> > appropriate for us to follow the current IANA process for 
> > registration, we would be very happy to do that. Of course, we are 
> > also very interested in any further comments from HTTPbis 
> on the topic even it does not end up your action list.
> 
> It's an extension, and extensions to HTTP is not in scope for 
> HTTPbis at the moment. Our task is to get RFC2616 + parts of 
> other closely related standards track documents cleaned up 
> and in good shape, and explicitly forbidden to add extensions 
> unless deemed absolutely required to correct errors or 
> serious shortcomings in the earlier specifications.
> 
> Regards
> Henrik
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 25 Aug 2009 16:08:23 +1000

We are; see
   http://trac.tools.ietf.org/wg/httpbis/trac/ticket/188

--
Mark Nottingham     http://www.mnot.net/

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 25 Aug 2009 12:03:45 +0200

>    http://trac.tools.ietf.org/wg/httpbis/trac/ticket/188

Good good. Well defined rules is seldom a bad thing. Even if there has
only been one single new registration in the years this registry have
been active..

Regards
Henrik

---

From: "John Schneider" <[email-masked]>
Date: Tue, 25 Aug 2009 16:12:15 -0700

Mark,

Thanks for the pointer. This makes it clear there is an open action to
change the IANA registration procedures for content codings. I noticed there
was no date associated with the associated milestone #08. Do you have an
idea when this milestone will be completed and the new procedures enacted by
IANA?

Given the timing of our request, it seems it might be a bit more efficient
for us to follow the current process rather than waiting for the new one to
be instantiated. Is that correct?

	Thanks,

	John

> From: Mark Nottingham [mailto:[email-masked]] 
> Sent: Monday, August 24, 2009 11:08 PM
> To: Henrik Nordstrom
> Cc: [email-masked]; [email-masked]
> >> questions about this request and elaborate as needed regarding our 
> >> use cases and rationale.
> >
> preleminary

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 26 Aug 2009 10:56:51 +1000

> idea when this milestone will be completed and the new procedures  

We don't have a definite date for -08, but I suspect it will be in the  
next month or two, at the most.

Even then, the new requirements won't take effect until we finish our  
work, so the current process is indeed what you want to follow, if  
you're looking at doing this soon.

That said, it would be good if what you do is done with an eye towards  
the new regime, to reduce the amount of problems we see down the road.  
In particular, it looks like the content-coding and transfer-coding  
registry will be one and the same, so it would help if you could  
design your registration with that in mind.

Cheers,

---

From: "John Schneider" <[email-masked]>
Date: Tue, 25 Aug 2009 19:30:52 -0700

Mark,

Thank you for the information. I'm impressed with the responsiveness of this
group given the number of issues you are tackling. Much appreciated!

We are wanting to complete the registration very soon, so we will follow
your suggestion of using the current process. We will also try to make sure
what we are doing fits with the new process you are developing. I will raise
the idea of merging the content-coding and transfer-coding registries with
the EXI group.

Please let me know if you have any additional guidance or suggestions for
us. I really appreciate your help!

	All the best,

	John 

> Sent: Tuesday, August 25, 2009 5:57 PM
> Cc: 'Henrik Nordstrom'; [email-masked]
> > change the IANA registration procedures for content 
> codings. I noticed 
> > there was no date associated with the associated milestone 
> #08. Do you 
> > have an idea when this milestone will be completed and the new 
> > procedures enacted by IANA?
> 
> We don't have a definite date for -08, but I suspect it will 
> be in the next month or two, at the most.
> 
> Even then, the new requirements won't take effect until we 
> finish our work, so the current process is indeed what you 
> want to follow, if you're looking at doing this soon.
> 
> That said, it would be good if what you do is done with an 
> eye towards the new regime, to reduce the amount of problems 
> we see down the road.  
> In particular, it looks like the content-coding and 
> transfer-coding registry will be one and the same, so it 
> would help if you could design your registration with that in mind.
> 
> Cheers,
> 
> 
> >
> > Given the timing of our request, it seems it might be a bit more 
> > efficient for us to follow the current process rather than 
> waiting for 
> > the new one to be instantiated. Is that correct?
> >
> > 	Thanks,
> >
> > 	John
> >
> >
> >

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 26 Aug 2009 09:28:19 +0200

> design your registration with that in mind.

They can not be entirely the same

transfer-encoding must by definition be lossless or it will fail HTTP
operations, while content-encoding don't.

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 26 Aug 2009 09:41:33 +0200

> be instantiated. Is that correct?

Until the new process is in place you have to follow the old process.
But the requirements for you to match the new process is only to

a) Have a stable written specification to refer to in the registration.
Preferably an RFC or W3C specification, but does not need to be.

b) Positive review from suitable experts. I.e. suitable members of this
group until an expert for the registry has been appointed by IESG.

Both is something I would strongly recommend.

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 26 Aug 2009 19:36:10 +1000

Good point; that didn't come up in Stockholm.

Roy, Julian?

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 26 Aug 2009 09:14:48 -0700

>> operations, while content-encoding don't.

Being in the same registry just means they share the same namespace,
not that they can all be used equally.  chunked is not a content- 
encoding
but it is still a way of encoding content, and we certainly don't  
want to
allow someone to register a different coding with the name "chunked"
for use as a content-encoding.

....Roy

---

From: "John Schneider" <[email-masked]>
Date: Wed, 26 Aug 2009 12:45:56 -0700

Roy,

Thanks for this clarification. Putting content-coding and transfer-coding
value tokens in the same namespace as a way to ensure the tokens have the
same meaning when used in different contexts makes a lot of sense. I'm glad
to hear it doesn't mean that any transfer-coding can be used as a
content-coding or vice-versa. 

I'm assuming when the registries are merged there will still be some way to
identify which tokens are valid for which contexts, right? (e.g., so it is
clear that "chunked" is not a valid content-coding). 

	Thanks,

	John

> From: Roy T. Fielding [mailto:[email-masked]] 
> Sent: Wednesday, August 26, 2009 9:15 AM
> To: Mark Nottingham
> Cc: Henrik Nordstrom; John Schneider; HTTP Working Group; 
> Julian F. F. Reschke
> >>> That said, it would be good if what you do is done with an eye 
> >>> towards the new regime, to reduce the amount of problems 
> we see down 
> >>> the road.
> transfer-coding 
> Being in the same registry just means they share the same 
> namespace, not that they can all be used equally.  chunked is 
> not a content- encoding but it is still a way of encoding 
> content, and we certainly don't want to allow someone to 
> register a different coding with the name "chunked"

---

From: "John Schneider" <[email-masked]>
Date: Wed, 26 Aug 2009 12:52:38 -0700

Henrik,

Thanks for asking this question. I was a little bit confused about the
implications of merging the content-coding and transfer-coding registries,
but your question and Roy's response have helped to clarify the intent of
this action.

	Best wishes,

	John 

> Sent: Wednesday, August 26, 2009 12:28 AM
> To: Mark Nottingham
> eye towards 
> transfer-encoding must by definition be lossless or it will 
> fail HTTP operations, while content-encoding don't.
> 
> Regards
> Henrik
>