The YAM WG held a meeting at IETF78. This is Version 0.1 of the
minutes. Please email me any changes. I apologize for the long
delay in producing the minutes. The filename for audio feed is
ietf78-ch5-thur-noon.mp3. The YAM session starts around the 133
minute mark and cuts off before the end of the session.
Yet Another Mail Working Group Minutes
Meeting : IETF78, Thursday 29 July, 2010
Location: MECC, Maastricht, Athens, 16:10 to 16.10
Chairs : Tony Hansen <[email protected]>
Minutes : S. Moonesamy <[email protected]>
Version 0.1
AGENDA
A. Meeting Administrivia
Note well
Agenda bashing
B. Mime type registration issue
Alexey Melnikov
C. Redux of plenary, discussion of two-track and their affect on YAM's
work and charter
D. Any Other Business
Meeting Report
A. Meeting Administrivia
Tony Hansen chaired the the IETF78 YAM Working Group meeting in
Maastricht, Netherlands. S. Moonesamy was the scribe. Barry Leiba
was the Jabber scribe.
The Chair brought the Note Well to the attention of the meeting
participants and asked them to sign the blue sheets.
B. Mime type registration issue
Alexey Melnikov, Applications Area Director, asked for feedback about the
image/svg+sml MIME type registration. The definition of the MIME type
specifies two file types extensions.
http://www.w3.org/TR/SVG11/mimereg.html
The explanation as to why this was not two different mime types was
because one is used for the XML version and the other for the gzip version
of the same thing. The initial reaction of the Applications Area Director was
why it was not two different MIME types. it was two different transfer
encodings used in HTTP of the same thing, one is identify and the other is
gzip version.
Mark Nottingham commented on the two different kinds of encoding used in
HTTP where transfer encoding is hop by hop is invisible to the payload whereas
content encoding is a property of the content encoding itself. Mark mentioned
that HTTP does not have Content Transfer Encoding.
Chris Newman pointed out that HTTP Content-Encoding acts like a MIME
Content-Transfer-Encoding but it's an HTTP-only MIME feature. gzip is a
Content-Encoding in HTTP. There is no gzip Content-Transfer-Encoding
defined.
Pete Resnick commented on the decoded "thing" getting the .gz on it and
that is wrong, i.e. the filename having the compress type attached to it is
wrong. John Klensin agreed that it was wrong as there are some "things" that
pay attention to the content type, some "things" that pay attention to the file
extension and some "things" that pay attention to both. The result is that
it can cause confusion and lead to interoperability problems. It is also a
fundamental break with the core of the specification which specifically says
that content type is the content type and the filename is indicative of
something the receiver might find useful.
Chris Newman said that the filename for gzipped-SVG needs to be in a
different spec, not the spec for image/svg+xml. Use of the gzipped-SVG
file name with a different MIME type is fine but that MIME type needs
to describe all the bad gzip security considerations and that content type
can't be +xml.
According to John Klensin, drawing clues from filenames breaks the MIME
specs. Julian Reschke asked whether filename registrations are purely
advisory.
C. Redux of plenary, discussion of two-track and their affect on YAM's
work and charter
The Chair provided a quick update on what has happened since the last
meeting. Three pre-evaluation documents have been published. One of
them has gone through IESG review and they have very little to same
about it. The Chair summarized the Two-track discussion that happened
during the plenary the last night. With draft-housley-two-maturity-levels
there would have be two levels and a six month wait is no longer required
to move to Full Standard. As a side effect, all existing documents at
Draft Standard would be moved immediately to Internet Standard. Barry
Leiba exclaimed that the working group has been successful.
Alexey Melnikov comments that there could be a different interpretation
where all Full Standards are downgraded to Draft Standards. Randy Gellens
agreed with Alexey's interpretation. There was some discussion between
Randy and Barry about the documents being put on the top tier whatever the
semantics of the tiers are. Dave Crocker pointed out that the working group
is a test of the ability to move documents to the top tier and the goal was to
exercise the mechanisms. The Chair mentioned that if the documents the
working group has adopted are already at Full Standard, the working group
might consider doing updates to the documents. Pete Resnick proposed that
the working group could consider suspending its activities until it
knows whether
draft-housley-two-maturity-levels will go through. Barry responded that if the
working group believes that the working on the documents is important, then it
does not have any bearing on the other decisions.
According to Pete Resnick, the changes to RFC5322 are not extensive but quite
necessary. He stated that he would continue working on the document.
Barry was of the opinion that the IESG is not interested in dealing with more
pre-evaluation documents. Alexey Melnikov, Area Director, said that he needs
to ask the IESG about that. Dave said that "we have a clear
agressive tenacious
statement from the IESG that they do not want to do this stuff". In the face
of institutional resistance, there isn't any reason to continuing the
work as there
is other important work to do. John Klensin agreed with Dave.
Alfred Hones was less optimistic about the success of the Two-track
proposal. He was of the view that it would not be completed by the current
IESG and suggested that the working group continues the work. John Klensin
disagreed with Alfred and pointed out that some participants in the working
group have other work with a higher priority. Although he does not know
what the right answer is stop or it is pause but he is pretty sure that the
right answer now is not move forward.
Barry ask the Area Directory about the time schedule for processing Two-track
and Alexey replied that he has no idea. As a personal opinion,
Alexey would like
people to update documents to fix bugs.
There was a discussion about how the Two-track proposal was produced during
the IESG retreat and Alexey mentioned that there was a view that moving
documents to Full Standard was pointless.
Tony Hansen asked how much of a change is acceptable for a document at Full
Standard not to be recycled to Proposed Standard. John Klensin mentioned that
it is subject to the unpredictability of the IESG.
Alexey said the IESG finds the pre-evaluation documents too painful. Randy
proposed one approach which considers pre-evaluation as shepherd write-ups.
Jacob Palme stated that the working group's task is to do the technical work.
The task is whether we want to modify the document. There are two
alternatives, publicize a new revised document or publicize an errata
document. If there is an errata document, there is a risk that implementors
will not find it. It is much better to change the entire document so
that there
is a full document with all the changes.
Chris Newman asked whether there was any energy to continue. John Klensin
mentioned that sooner or later a revised version of RFC 5321 would appear.
The odds of doing it in the next few months is very low. Pete mentioned
that he could probably get RFC5322bis done. A participant commented that
RFC 5321 is just finished and there is already a new version in the works.
Barry took the comment as a vote about advancing documents as it creates
too much churn.
The Chair wanted to get a sense of the room between three choices:
(a) continue YAM
(b) pause YAM
(c) close YAM
Of the twenty-six people in the room, six people were in favor of
continuing, six person were in favor of pausing and nobody were in
favor of closing the working group. The Chair asked the questions
again. Seven people were in favor of continuing, nine people were in
favor of pausing. There was no consensus.
D. Any Other Business
There wasn't any other item for discussion.
The Chair ended the meeting.
Regards,
S. Moonesamy
YAM WG Secretary
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
