Re: IETF IPv6 platform configuration

[Iljitsch van Beijnum]

On 15-jun-2006, at 1:51, Mark Andrews wrote:




*   Only HTTP, SMTP, FTP, and DNS traffic are permitted through an IPv6
Native firewall (pings, traceroutes etc. are dropped)



Why?  Shouldn't we be prompting good firewall practices?



Droping ICMP was a knee jerk reaction to ICMP echo to
directed broadcast addresses.  Modern routers can be
configured to drop directed broadcast packets.


And all of this doesn't even apply to IPv6, it doesn't even support  
broadcasts in general or anything resembling directed broadcast. ICMP  
replies are also supposed to be rate limited in IPv6.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[John C Klensin]

Two observations on this...

--On Wednesday, June 14, 2006 22:16 -0400 John L 
<[EMAIL PROTECTED]> wrote:



The key question is whether there exists a format which is
likely to be sufficiently stable that we won't have to
revisit this decision in another 35 years. All the proposed
formats - including PDF, XML, etc. - are moving targets at
this time.


That's why I suggested GIF.  Like ASCII, GIF has its
shortcomings, but its definition hasn't changed in 16 years
and I've never seen GIF software that doesn't interoperate.


But one of the important criteria for an acceptable alternate 
form, one which came up in the earlier discussion on this list, 
is that the format be searchable.   With PDF, page-image forms 
may not permit that but, as far as I know, searching inside GIFs 
is impossible except perhaps via fancy AI tools and heuristics.


More generally and to reinforce a point that I think Bob Braden 
made, I believe there was general consensus on this IETF list 
when the earlier discussion occurred that PDF, if it was to be 
used, be narrowly profiled so as to permit only those variations 
that appeared to be stable and meet various other criteria, 
notably ease of searching and extraction by text copying 
operations.  It seems to me that this draft, by omitting 
specifics about versions and features of PDF to be permitted 
and, if it isn't obvious, how the submission or editing process 
automatically verifies that those rules were followed, is not 
responsive to that consensus.  Arguably, on that basis, it 
should never have been Last Called.


 john


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[John C Klensin]

Two observations on this...

--On Wednesday, June 14, 2006 22:16 -0400 John L 
<[EMAIL PROTECTED]> wrote:



The key question is whether there exists a format which is
likely to be sufficiently stable that we won't have to
revisit this decision in another 35 years. All the proposed
formats - including PDF, XML, etc. - are moving targets at
this time.


That's why I suggested GIF.  Like ASCII, GIF has its
shortcomings, but its definition hasn't changed in 16 years
and I've never seen GIF software that doesn't interoperate.


But one of the important criteria for an acceptable alternate 
form, one which came up in the earlier discussion on this list, 
is that the format be searchable.   With PDF, page-image forms 
may not permit that but, as far as I know, searching inside GIFs 
is impossible except perhaps via fancy AI tools and heuristics.


More generally and to reinforce a point that I think Bob Braden 
made, I believe there was general consensus on this IETF list 
when the earlier discussion occurred that PDF, if it was to be 
used, be narrowly profiled so as to permit only those variations 
that appeared to be stable and meet various other criteria, 
notably ease of searching and extraction by text copying 
operations.  It seems to me that this draft, by omitting 
specifics about versions and features of PDF to be permitted 
and, if it isn't obvious, how the submission or editing process 
automatically verifies that those rules were followed, is not 
responsive to that consensus.  Arguably, on that basis, it 
should never have been Last Called.


 john


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Stephane Bortzmeyer]

On Wed, Jun 14, 2006 at 10:56:03AM -0400,
 The IESG <[EMAIL PROTECTED]> wrote 
 a message of 18 lines which said:

> - 'Proposed Experiment: Normative Format in Addition to ASCII Text '
> as an Experimental RFC

This draft is a bad answer to a very real and important problem. I
agree with many of the nagtive remarks done on the IETF mailing list.

But I want to add one: authorizing an *output* format without the
corresponding *input* format (the "source") would be a very dangerous
step away from open formats. Because it would mean a great difficulty,
should we need to modify the RFC for a future version. Even a simple
bug fix would be difficult.

IMHO, IETF should always publish the "source" of its documents (the
current RFC process is far from perfect in that respect).

BTW, the draft completely fails to mention that there are text formats
which are better than ordinary raw ASCII and able to be automatically
translated to a nice rendering (typical candidates are LaTeX for
equations and Graphviz for state machines).

In short: no.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12

[Julian Reschke]

I noticed that the ID tracker now has a comment from the authors (see 
), 
which I'd like to comment over here...:



Author's response to Last Call comments on ETags

1) Best common practice in WebDAV

Currently very few, if any at all, WebDAV servers change the content of 
resource data during a PUT request. Most WebDAV servers do return an ETag on 
PUT. Thus clients have come to rely on the presence of the ETag to effectively 
mean that the resource data was stored unchanged and that the ETag can be used 
in subsequent GET requests etc. This justifies our statement that servers 
SHOULD return an ETag in a response when the data has not changed.


I have my doubts that this statement is based on actual testing. In 
particular it seems to me that making claims about "most" servers isn't 
useful here; servers that do rewrite content do exist, but they are 
certainly outnumbered *installation-wise* by IIS and Apache/moddav/fs 
which implement WebDAV as a "dumb" store (in that they don't support 
special semantics on specific content types). But that doesn't mean that 
being incompatible with that class of servers (being fully compliant to 
RFC2616 and RFC2518) is acceptable.


That being said, I just tested:

- Microsoft IIS 5.1 (as shipping with XPSP2): No ETag returned upon PUT

- Apache/moddav 2.0.55 (WinXPSP2): No ETag returned upon PUT

- Xythos WFS (on www.sharemation.com): ETag returned

- SAP Netweaver KM: ETag returned although content may be rewritten

It seems to me that this shows that the statement above is misleading.


Now we have CalDAV servers where the resource data MAY be changed. Therefore to 
be compatible with existing client behavior a server MUST NOT send the ETag in 
a PUT response when the data changes, otherwise clients will misinterpret it. 
This justifies our 'MUST NOT' statement.


It would be helpful if you could provide an example of a *shipping* 
client that breaks if an ETag is returned upon PUT although content was 
rewritten.



2) Restricted behavior

The ETag behavior we are talking about is restricted solely to calendar object 
resources being stored in calendar collections - i.e. it is very specific to 
CalDAV. This is not 'redefining' HTTP behavior by rather extending it for this 
one specific application need.


But it's still an HTTP and WebDAV resource. A CalDAV server that also 
happens to be a generic WebDAV server may need to make this a special 
case then. And this may be hard to do should there be another 
HTTP/WebDAV related specification making an incompatible requirement.


As a matter of fact, in February the IESG has decided to solve that very 
problem in a separate activity (see draft-whitehead-http-etag-00), 
independently of WebDAV and CalDAV. And, indeed, RFC2518bis (the 
revision of WebDAV) delegates resolution of the question to that very 
spec, instead of coming up with it's own. This is what CalDAV should 
also be doing.



3) Future conflicts

One of Julian's arguments is that our requirement will "risk making CalDAV 
incompatible with other specs extending HTTP (or HTTP itself, for that matter)". 
Since we have been careful to require only behavior that already exists in deployed 
WebDAV servers, CalDAV adds no further incompatibility. If future work to better define 
the meaning of ETag on PUT ever happens, it will need to take into account the deployed 
base, and the subset of CalDAV servers will simply happen to be a consistently behaving 
subset. We believe that our requirements improve the interoperability of CalDAV, without 
making the future/potential incompatibility problem any worse than it already is.


See notes above. The behavior required by CalDAV is *not* what current 
servers do. At least not the majority.



4) Need/usefulness

In addition to the authors' evaluation of the usefulness of this feature for 
keeping an offline calendar correct, there have been other requests for 
predictable behavior w.r.t. PUT and ETags and calendar resources. This was one 
of the first feature requests from client implementors, including Dan Mosedale 
and Grant Baillie.


I totally agree that clients may be interested in finding out whether 
content was rewritten. The solution to this is to either put more energy 
into draft-whitehead-http-etag-00, or to have a CalDAV-specific solution 
 that by design wouldn't interfere with what we define in other specs 
later, as outlined in 
. 
 I'd really like to here why the solution suggested back then isn't 
sufficient for CalDAV.



Best regards, Julian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12

[Peter Dambier]

Julian Reschke wrote:
I noticed that the ID tracker now has a comment from the authors (see 
), 
which I'd like to comment over here...:



Author's response to Last Call comments on ETags

1) Best common practice in WebDAV

Currently very few, if any at all, WebDAV servers change the content 
of resource data during a PUT request. Most WebDAV servers do return 
an ETag on PUT. Thus clients have come to rely on the presence of the 
ETag to effectively mean that the resource data was stored unchanged 
and that the ETag can be used in subsequent GET requests etc. This 
justifies our statement that servers SHOULD return an ETag in a 
response when the data has not changed.




I am one user of webdavs://mediacenter.gmx.net/

I dont know how many subscribers they serve but they are one of the biggest
ISPs in germany. They belong to United Internet, 1und1, GMX and Schlund.

I dont know what they use but I guess Appache and Linux.

They do change content.

I am running Konqueror on Linux and I can both move and copy documents using
drag and drop. I can delete or rename using the mouse and I can edit and
write back using the browsers builtin editor.

I cannot see ETag flag from my userinterface. But my browser shows me
the before and after. So normally I can see if anything has changed.



I have my doubts that this statement is based on actual testing. In 
particular it seems to me that making claims about "most" servers isn't 
useful here; servers that do rewrite content do exist, but they are 
certainly outnumbered *installation-wise* by IIS and Apache/moddav/fs 
which implement WebDAV as a "dumb" store (in that they don't support 
special semantics on specific content types). But that doesn't mean that 
being incompatible with that class of servers (being fully compliant to 
RFC2616 and RFC2518) is acceptable.


That being said, I just tested:

- Microsoft IIS 5.1 (as shipping with XPSP2): No ETag returned upon PUT

- Apache/moddav 2.0.55 (WinXPSP2): No ETag returned upon PUT

- Xythos WFS (on www.sharemation.com): ETag returned

- SAP Netweaver KM: ETag returned although content may be rewritten

It seems to me that this shows that the statement above is misleading.

Now we have CalDAV servers where the resource data MAY be changed. 
Therefore to be compatible with existing client behavior a server MUST 
NOT send the ETag in a PUT response when the data changes, otherwise 
clients will misinterpret it. This justifies our 'MUST NOT' statement.



It would be helpful if you could provide an example of a *shipping* 
client that breaks if an ETag is returned upon PUT although content was 
rewritten.



2) Restricted behavior

The ETag behavior we are talking about is restricted solely to 
calendar object resources being stored in calendar collections - i.e. 
it is very specific to CalDAV. This is not 'redefining' HTTP behavior 
by rather extending it for this one specific application need.



But it's still an HTTP and WebDAV resource. A CalDAV server that also 
happens to be a generic WebDAV server may need to make this a special 
case then. And this may be hard to do should there be another 
HTTP/WebDAV related specification making an incompatible requirement.


As a matter of fact, in February the IESG has decided to solve that very 
problem in a separate activity (see draft-whitehead-http-etag-00), 
independently of WebDAV and CalDAV. And, indeed, RFC2518bis (the 
revision of WebDAV) delegates resolution of the question to that very 
spec, instead of coming up with it's own. This is what CalDAV should 
also be doing.



3) Future conflicts

One of Julian's arguments is that our requirement will "risk making 
CalDAV incompatible with other specs extending HTTP (or HTTP itself, 
for that matter)". Since we have been careful to require only behavior 
that already exists in deployed WebDAV servers, CalDAV adds no further 
incompatibility. If future work to better define the meaning of ETag 
on PUT ever happens, it will need to take into account the deployed 
base, and the subset of CalDAV servers will simply happen to be a 
consistently behaving subset. We believe that our requirements improve 
the interoperability of CalDAV, without making the future/potential 
incompatibility problem any worse than it already is.



See notes above. The behavior required by CalDAV is *not* what current 
servers do. At least not the majority.



4) Need/usefulness

In addition to the authors' evaluation of the usefulness of this 
feature for keeping an offline calendar correct, there have been other 
requests for predictable behavior w.r.t. PUT and ETags and calendar 
resources. This was one of the first feature requests from client 
implementors, including Dan Mosedale and Grant Baillie.



I totally agree that clients may be interested in finding out whether 
content was rewritten. The solution to this is to either put more energy 
into dra

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Brian E Carpenter]

Bob,

First, I must request that the Internet Draft be retracted in its 
present form.  Section 4
contains a direct quote from one of my messages.  However, the quoted 
sentence was taken
brazenly out of context; its sense is quite the opposite of the sense of 
my original
message. This is intolerable.  That kind of behavior may get you elected 
in the US ;-)

but it does not belong in the IETF.


Please take that up directly with the author. We don't 'retract' I-Ds
but we certainly update them.
...


How DID it get last called, by the way?  If I write up a arbitrary 
process experiment,

will the IESG automatically last call it?  Yummy.


No. It requires an AD (Bill Fenner in this case) who is willing to
shepherd the draft. The IESG as a whole doesn't normally review
drafts until after the Last Call has ended - that's why we have
Last Calls.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[John R Levine]

> But one of the important criteria for an acceptable alternate
> form, one which came up in the earlier discussion on this list,
> is that the format be searchable.

In case it wasn't clear, my quite informal suggestion was that one might
attach a few GIF illusttrations to an ASCII document, sort of like a paper
book that has a few color plates glued in the back.  I agree it would be
nuts to put text into GIF.

> More generally and to reinforce a point that I think Bob Braden
> made, I believe there was general consensus on this IETF list
> when the earlier discussion occurred that PDF, if it was to be
> used, be narrowly profiled so as to permit only those variations
> that appeared to be stable and meet various other criteria,
> notably ease of searching and extraction by text copying
> operations.  It seems to me that this draft, by omitting
> specifics about versions and features of PDF to be permitted
> and, if it isn't obvious, how the submission or editing process
> automatically verifies that those rules were followed, is not
> responsive to that consensus.  Arguably, on that basis, it
> should never have been Last Called.

Entirely agree.

Regards,
John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for 
Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Ash, Gerald R \(Jerry\), ALABS]

> As the author notes, there was 
> indeed a replay 
> of the usual
> discussion about RFC formats in winter 2006.  The author 
> says, "... the 
> quite thoughtful,
> extended, and detailed discussion ... resulted in no change". 
>  There is a 
> reason it did
> not result in change... there were cogent arguments against 
> all proposals 
> that were
> made. 

Cogent arguments against?  Very few people came out and said that we
need nothing beyond ASCII art.  OTOH, many supported the need for
something better than archaic ASCII art/equations, given that almost all
of us recognize the limitations of ASCII art/equations, generate/use
complex graphics every day (in many formats), and very few of us
generate/use stick figures beyond IETF.

> So, when it has no good ideas, the IETF randomly picks 
> one of the bad 
> ones?
> That is apparently happening here.
> 
> How DID it get last called, by the way?  If I write up a 
> arbitrary process 
> experiment,
> will the IESG automatically last call it?  Yummy.

It is quite reasonable to last call this draft at this point.  It has
been reviewed for ~6 months.  This version posted to the list for
comments more than 3 weeks ago, plenty of time for more comments, but no
comments were posted to the list on this version.  

In addition, you/RFC Editor were asked to comment on this version
(before it was submitted), starting on May 5, but you did not comment.
There was an exchange with the AD during this period regarding his
concerns RE RFC Editor buy-in, but you still did not comment.  We could
have incorporated your comments into the LC version had we known them.
 
> The experiment picks on  two working groups and specifies 
> that for one year review
> it will
> treat the results of these working groups differently from all other 
> working group
> output. 

Only 2 drafts are involved, and both WGs have agreed.  Both of these
drafts are good examples of where .pdf is preferable to ASCII art.

> How will a future implementor know which version is 
> normative?  At 
> present,
> there is a simple rule... it is always the ASCII version.  If 
> this exercise 
> goes
> ahead, some PDF files (which ones?) will be normative, and some ASCII
> files won't.  

I'm sure with all the brain power at hand we can solve that daunting
riddle with another simple rule.

> the I-D has some misleading 
> examples of
> bad ASCII art.  You cannot honestly prove that ASCII art is unusable
> by abusing it.  I spent a few minutes cleaning up the terrible example
> in the I-D (Sorry, I am in Washington and don't have ready access to
> it; I will forward it when I get back.)

Yes please send us the competing ASCII diagrams.  We can provide you
with even more complex artwork/diagrams to convert to ASCII art -- this
will allow you to further prove your point.
 
> As Joel mentions, this experiment will have a negative impact on
> RFC Editor throughput.  Shouldn't the IAB and perhaps the IAD
> have some part in this?

.pdf is allowed now for drafts and RFCs.  There are procedures in place
for .pdf output.  In fact, the proposed experiment uses exactly the same
procedures followed now wrt RFC Editor processing of .pdf output
documents.  As stated in the draft:

  "These documents will be progressed through WG review, IESG review,
   and RFC Editor review and approval.

   The method to progress the PDF format version is as specified in
   [RFC2223bis]:

   When the .pdf version is submitted with the .txt version, the RFC
   Editor will first edit the .txt version.  The final form of the .txt
   version (or, when feasible, the diffs) will be returned to the
   author.  The author must then update the .pdf files to match, as
   closely as possible, the content and format of the ASCII .txt file.
   When the RFC Editor agrees that the .pdf version is acceptable, it is
   published simultaneously with the .txt version."

Since these same procedures are specified in [RFC2223bis]
http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt,
authored by the RFC Editor, it is reasonable to assume they are OK for
our experiment.  It is also hard to see how these procedures will lead
to more work for the RFC Editor given they are used now.

In addition, tools can be developed to assist the authors and RFC editor
if necessary.  It is straightforward to specify required .pdf
versions/formats if that is essential, as some have suggested (although
there is no such requirement now on .pdf drafts and RFCs AFAIK).
 
> For all the reasons that Joel said, plus the reasons I have given, I
> request that the IESG reject this last call.  At the very least, the
> base document needs more work, and the implications need
> more mature thought.  And it seems to there is a badly broken
> process lurking here.
> 
> I am somewhat astonished that the IESG chose to last call
> 'this document.

It's quite legitimate to last call this (6 months of discussion, several
weeks to comment on this version, etc.).  I'm rather asto

RE: Last Call: 'Proposed Experiment: Normative Format in Additionto ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Yaakov Stein]

 
> The document does not specify a particular variety of PDF. There are
many.

This comment has been made many times, and answered equally many.
One of the objects of the experiment os to determine the details of the
PDF to be used.
PDF/A has been suggested.

> The document does not specify the permitted embedded data formats. 
> PDF allows raster and vector images, JavaScript, form validation,
fonts, and much more.

Once again, this has been discussed to death on this list.


> PDF and some possible embedded data formats are patent encumbered.
> There are IPR disclosures available.

Read Adobe's RFC 3667 disclosure. They grant a royalty-free license
to anyone who wants to write software to manipulate PDFs,
as long as they are compliant to the specification.
Sounds sufficient to my (IPR trained) eyes.

> The document incorrectly states that RFC 1119 is available in
"PDF/PostScript", when it is only available in PostScript.

Go to the RFC editor page and serach for 1119.
You will get the following screen:

 Choose a file format
  Text   rfc1119.txt
  PDF   rfc1119.pdf
  PS rfc1119.ps

The filenames all have simple links to files, nothing is generated
on-the-fly.

I agree that clicking on the txt version gives an incorrect message that
the file is only available in ps.

> The authors state that "commercial" software does support ASCII well.
> Their stated favorite editor, Microsoft Word, does not and will not
support PDF:

As one of the authors I hereby state that Word is not my favorite editor
(if it is an editor at all).  However, the clear intent was that IF the
IETF
does not want to use a commercially available tool, then the next
possibility
is to use a well-defined format.

> The process outlined in this document is completely inappropriate for
an archival document series, for the reasons outlined above. 
> Those were just the glaringly obvious concerns. There are probably
more.

What seems to be glaringly obvious is that the same reasons are brought
up time and time again,
as if for the first time.  I assume that the strategy is to bore the
authors of this draft into submission
(or in this case into retraction of a submission).

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Proposed Experiment: Normative Format in Additionto ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Yaakov Stein]

 

> This draft is a bad answer to a very real and important problem. 

We are willing to entertain constructive comments as to a good answer.

> But I want to add one: authorizing an *output* format without the
corresponding *input* format (the "source") 
> would be a very dangerous step away from open formats. 

We were forced into specifying ONLY an output format by comments on THIS
LIST.
We originally tried specifying OpenDocument, various commercial
word-processors, etc.

> BTW, the draft completely fails to mention that there are text formats
which are better than ordinary raw ASCII 
> and able to be automatically translated to a nice rendering (typical
candidates are LaTeX for equations and Graphviz for state machines).

I personally an a TeX-adict. If the IETF would adopt TeX input as
normative
then we could accomplish all that we want - great looking equations,
decent graphics, etc.
And we could easily generate PDF.

Of course, this would eliminate the need for XML notation and tools 
as there are TeX packages that are much simpler to use than XML2RFC.
So I guess there is even less chance of getting that idea off the
runway.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Joel M. Halpern]

As I said in my comments, there is a big difference in the situations.
Currently, if the RFC Editor misses something in the PDF applied 
corrections, that is unfortunate but not fundamentally significant, 
in that the text file is normative, not the PDF.
With your proposed change, the PDF would be normative, not the 
text.  As such, the degree of care and review required for the PDF 
document is much higher.


Similarly, the issue of version change and feature set is not central 
when one is dealing with informative PDF.  But becomes critical if 
the PDF is normative.  (It is extremely undesirable for a normative 
document to be inaccessible.)  As such, your persistent comparisons 
with the current state are at best misleading.


As an example of the necessity of profiling the PDF, at the very 
least we would want searchable PDF.  (Some PDFs with text are 
searchable, some are not.)


Yours,
Joel M. Halpern

At 09:44 AM 6/15/2006, Ash, Gerald R \(Jerry\), ALABS wrote:

> As Joel mentions, this experiment will have a negative impact on
> RFC Editor throughput.  Shouldn't the IAB and perhaps the IAD
> have some part in this?

.pdf is allowed now for drafts and RFCs.  There are procedures in place
for .pdf output.  In fact, the proposed experiment uses exactly the same
procedures followed now wrt RFC Editor processing of .pdf output
documents.  As stated in the draft:



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Thomas Narten]

> It is quite reasonable to last call this draft at this point.  It has
> been reviewed for ~6 months.  This version posted to the list for
> comments more than 3 weeks ago, plenty of time for more comments, but no
> comments were posted to the list on this version.

Maybe reviewer fatigue?

One thing missing from this discussion (that I think would have been
helpful) is running all the previous comments through an issue
tracker, so folk could go review the history, and most important of
all, those who raised issue can go see if they believe their issues
have been dealt with appropriately. One of the most frustrating and
demoralizing aspects of IETF participation is spending time doing a
careful review, and then feeling like your comments have been blown
off. Trackers make it much harder for that to happen, which in my
experience is a very good thing for all involved.

Thomas

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Bill Fenner]

>There is a reason it did not result in change... there were cogent
>arguments against all proposals that were made.

I thought that some of the arguments were just arguments against
change, and some of the arguments did argue for a change in the
experiment but not that the experiment was bad per se.

>How DID it get last called, by the way?

I evaluated the document, the discussion, the feedback from the
stakeholders, and decided that a Last Call would be a good
forcing function to make sure we have a real discussion about it.
I think the idea has promise.

>How will a future implementor know which version is normative?

Presumably, the documents will include a note, something like "This
document is part of an experiment described in RFC; unlike all other
RFCs, the PDF version of this document is normative".  Thanks for pointing
out that the experiment description forgot to mention that.

>As Joel mentions, this experiment will have a negative impact on
>RFC Editor throughput.

I didn't quite buy Joel's argument.  If the author can generate ASCII
from his source that matches the RFC-Editor's edited ASCII, and then
generates the PDF from the same source, where does the extra verification
come in?

>...and the implications need more mature thought.

If all we get when discussing on the ietf list is knee-jerk reactions,
where is this more mature thought going to come from?

  Bill

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Proposed Experiment: Normative Format in Additionto ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[nathaniel Borenstein]

Although I, too, am tired of seeing this discussion arise again every few
years, it occurs to me that there is one new possibility that exists now,
but did not exist in previous incarnations of this discussion:  Open
Document Format.

I expect that ODF is still too young and immature for use in archival
standards documents today.  But it is worth pointing out that IF (a big
if) ODF succeeds in becoming a widely-used standard, it will have nearly
all of the right properties for a long term IETF archival format.

I know this stirs up yet another batch of hornets, but it might really be
the right solution in the long term.  -- Nathaniel


>> The document does not specify a particular variety of PDF. There are
> many.
>
> This comment has been made many times, and answered equally many.
> One of the objects of the experiment os to determine the details of the
> PDF to be used.
> PDF/A has been suggested.
>
>> The document does not specify the permitted embedded data formats.
>> PDF allows raster and vector images, JavaScript, form validation,
> fonts, and much more.
>
> Once again, this has been discussed to death on this list.
>
>
>> PDF and some possible embedded data formats are patent encumbered.
>> There are IPR disclosures available.
>
> Read Adobe's RFC 3667 disclosure. They grant a royalty-free license
> to anyone who wants to write software to manipulate PDFs,
> as long as they are compliant to the specification.
> Sounds sufficient to my (IPR trained) eyes.
>
>> The document incorrectly states that RFC 1119 is available in
> "PDF/PostScript", when it is only available in PostScript.
>
> Go to the RFC editor page and serach for 1119.
> You will get the following screen:
>
>  Choose a file format
>   Text   rfc1119.txt
>   PDF   rfc1119.pdf
>   PS rfc1119.ps
>
> The filenames all have simple links to files, nothing is generated
> on-the-fly.
>
> I agree that clicking on the txt version gives an incorrect message that
> the file is only available in ps.
>
>> The authors state that "commercial" software does support ASCII well.
>> Their stated favorite editor, Microsoft Word, does not and will not
> support PDF:
>
> As one of the authors I hereby state that Word is not my favorite editor
> (if it is an editor at all).  However, the clear intent was that IF the
> IETF
> does not want to use a commercially available tool, then the next
> possibility
> is to use a well-defined format.
>
>> The process outlined in this document is completely inappropriate for
> an archival document series, for the reasons outlined above.
>> Those were just the glaringly obvious concerns. There are probably
> more.
>
> What seems to be glaringly obvious is that the same reasons are brought
> up time and time again,
> as if for the first time.  I assume that the strategy is to bore the
> authors of this draft into submission
> (or in this case into retraction of a submission).
>
> Y(J)S
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Gray, Eric]

Thomas,

This is a different discussion, however, you are
right on target with that discussion - at least for IDs
in general.  Wouldn't this be subject to a DoS attack,
if applied to individual ID submissions?

--
Eric

--> -Original Message-
--> From: Thomas Narten [mailto:[EMAIL PROTECTED] 
--> Sent: Thursday, June 15, 2006 11:12 AM
--> To: Ash, Gerald R (Jerry), ALABS
--> Cc: Bob Braden; ietf@ietf.org
--> Subject: Re: Last Call: 'Proposed Experiment: Normative 
--> Format in Addition to ASCII Text' to Experimental RFC 
--> (draft-ash-alt-formats) 
--> 
--> > It is quite reasonable to last call this draft at this 
--> point.  It has
--> > been reviewed for ~6 months.  This version posted to the list for
--> > comments more than 3 weeks ago, plenty of time for more 
--> comments, but no
--> > comments were posted to the list on this version.
--> 
--> Maybe reviewer fatigue?
--> 
--> One thing missing from this discussion (that I think would have been
--> helpful) is running all the previous comments through an issue
--> tracker, so folk could go review the history, and most important of
--> all, those who raised issue can go see if they believe their issues
--> have been dealt with appropriately. One of the most frustrating and
--> demoralizing aspects of IETF participation is spending time doing a
--> careful review, and then feeling like your comments have been blown
--> off. Trackers make it much harder for that to happen, which in my
--> experience is a very good thing for all involved.
--> 
--> Thomas
--> 
--> ___
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF IPv6 platform configuration

[Joe Touch]

Iljitsch van Beijnum wrote:
> On 15-jun-2006, at 1:51, Mark Andrews wrote:
> 
>>
>>> *Only HTTP, SMTP, FTP, and DNS traffic are permitted through an IPv6
>>> Native firewall (pings, traceroutes etc. are dropped)
> 
>> Why?  Shouldn't we be prompting good firewall practices?
> 
>> Droping ICMP was a knee jerk reaction to ICMP echo to
>> directed broadcast addresses.  Modern routers can be
>> configured to drop directed broadcast packets.
> 
> And all of this doesn't even apply to IPv6, it doesn't even support
> broadcasts in general or anything resembling directed broadcast. ICMP
> replies are also supposed to be rate limited in IPv6.

IPv4 too. There are other reasons to drop them at firewalls (net
mapping, protecting other protocols), but I agree we ought to be an
example of the best the Internet can provide, not the most paranoid.

Joe



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Joe Touch]

Stephane Bortzmeyer wrote:
...
> IMHO, IETF should always publish the "source" of its documents (the
> current RFC process is far from perfect in that respect).

Which source (XML2RFC is only one; some use troff, and others use Word,
among others)? Why would inter-source conversion be more useful than
cut-and-paste?

Joe



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Additionto ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Robert Sayre]

On 6/15/06, Yaakov Stein <[EMAIL PROTECTED]> wrote:


What seems to be glaringly obvious is that the same reasons are brought
up time and time again,
as if for the first time.  I assume that the strategy is to bore the
authors of this draft into submission
(or in this case into retraction of a submission).



I moved this up to the top. Other responses follow. The text above is
pretty intellectually dishonest coming from someone who ignored the
opinion of a large number of commenters and went ahead with
essentially the same text they had before. The draft is a joke.


> The document does not specify a particular variety of PDF. There are
many.

This comment has been made many times, and answered equally many.
One of the objects of the experiment os to determine the details of the
PDF to be used.
PDF/A has been suggested.


Then I don't think you've put much effort into this proposal. Be more specific.



> The document does not specify the permitted embedded data formats.
> PDF allows raster and vector images, JavaScript, form validation,
fonts, and much more.

Once again, this has been discussed to death on this list.



Yes, and there was no satisfactory resolution, so why should the
"experiment" go forward.


> PDF and some possible embedded data formats are patent encumbered.
> There are IPR disclosures available.

Read Adobe's RFC 3667 disclosure. They grant a royalty-free license
to anyone who wants to write software to manipulate PDFs,
as long as they are compliant to the specification.
Sounds sufficient to my (IPR trained) eyes.



Your IPR-trained opinion doesn't mean much to me when Adobe is
threatening to sue people (even if it is MS).


> The document incorrectly states that RFC 1119 is available in
"PDF/PostScript", when it is only available in PostScript.

I agree that clicking on the txt version gives an incorrect message that
the file is only available in ps.


Fair enough.

--

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Proposed Experiment: Normative Format in AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Hallam-Baker, Phillip]

 > > > PDF and some possible embedded data formats are patent encumbered.
> > > There are IPR disclosures available.
> >
> > Read Adobe's RFC 3667 disclosure. They grant a royalty-free 
> license to 
> > anyone who wants to write software to manipulate PDFs, as 
> long as they 
> > are compliant to the specification.
> > Sounds sufficient to my (IPR trained) eyes.
> >
> 
> Your IPR-trained opinion doesn't mean much to me when Adobe 
> is threatening to sue people (even if it is MS).

In point of fact the above license is exactly the form of license that Sun 
attempted to sue Microsoft over.

Regardless of what you believe the merits of that suit to be, the ability for 
one party to unilaterally determine the future of a specification and exclude 
other changes under threat of law is certainly not what I consider to be an 
open standard.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Proposed Experiment: Normative Format in AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Hallam-Baker, Phillip]

I am having difficulty following this discussion.

I agree with the requirements analysis in draft-ash-alt-formats, it's the 
conclusion I have a hard time following.

The idea of using PDF as a normative form appears broken to me from every 
perspective except producing a document that looks professional.

  * The format is proprietary, only Adobe can change it
  * The format is patent encumbered
  * The format is dedicated to presentation on paper
  * Tools to support the format do not support semantic markup

There is an obvious alternative, make use of XHTML, an open standard that is 
expressly designed to be non-proprietary and is so widely used that there is 
zero probability that the ability to read the documents will ever be lost for 
as long as it is possible to read the media on which they are stored.

To repeat: THERE IS ZERO PROBAILITY THAT MANKIND WILL LOSE THE ABILITY TO READ 
HTML

There are billions upon billions of documents marked up in HTML. We managed to 
decipher the rosetta stone we can decipher HTML. The notion that this will ever 
change is silly. If we loose the ability to read XHTML we will have lost the 
ability to read the bits on the hard drive as well.


The one problem that XHTML does present is that support for compound documents 
with embedded images are not well handled. This is easily solved through the 
use of MHTML, MIME encapsulation of HTML documents and attachments. Again the 
format is widely implemented and easy to reverse engineer.

The problem people have with moving to XHTML is not that it is a moving target. 
It is the idea of change itself.

A standards based, future proof, non proprietary solution to this problem is to 
adopt:

  * Use of MHTML as the archive packaging.
  * Use of XHTML 1.0 as the document encoding.
  * Use of a standard IETF defined style sheet.
  * Use of PNG encoding for all images.

These restrictions may all be enforced using easily constructed verification 
tools. The W3C already has these and would be more than happy to provide them 
to the IETF. 

Writing 100% compatible HTML is a bit of a pain but nowhere near as much of a 
pain as dealing with RFC TXT format which is designed with the built in 
assumption of north american paper sizes amongst others.


There is already one standards body that has adopted the HTML approach. The 
IETF is not a standards body for document formats, why not rely on one that is?


Meanwhile regardless of which spec the IETF deems to be normative the engineers 
will continue to code from the version of the specification that is easiest to 
read. 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Additionto ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Randy Presuhn]

Hi -

> From: "Thomas Narten" <[EMAIL PROTECTED]>
> To: "Ash, Gerald R (Jerry), ALABS" <[EMAIL PROTECTED]>
> Cc: "Bob Braden" <[EMAIL PROTECTED]>; 
> Sent: Thursday, June 15, 2006 8:12 AM
> Subject: Re: Last Call: 'Proposed Experiment: Normative Format in Additionto 
> ASCII Text' to Experimental RFC
(draft-ash-alt-formats)
...
> One thing missing from this discussion (that I think would have been
> helpful) is running all the previous comments through an issue
> tracker, so folk could go review the history, and most important of
> all, those who raised issue can go see if they believe their issues
> have been dealt with appropriately. One of the most frustrating and
> demoralizing aspects of IETF participation is spending time doing a
> careful review, and then feeling like your comments have been blown
> off. Trackers make it much harder for that to happen, which in my
> experience is a very good thing for all involved.
...

Since there appears to be some disagreement about whether comments
received were adequately addressed by the draft now under last call,
and whether the manner in which they were addressed represents a
consensus view, perhaps we should consider the possibility that the
question of whether and how to conduct this experiment could be given to
a WG (IRTF, rather than IETF, I'd think), in order to ensure that the
experiment's general parameters meet with community approval.

Randy



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Ned Freed]

> That's why I suggested GIF.  Like ASCII, GIF has its
> shortcomings, but its definition hasn't changed in 16 years
> and I've never seen GIF software that doesn't interoperate.



But one of the important criteria for an acceptable alternate
form, one which came up in the earlier discussion on this list,
is that the format be searchable.   With PDF, page-image forms
may not permit that but, as far as I know, searching inside GIFs
is impossible except perhaps via fancy AI tools and heuristics.


Complete agreement here. GIF may win on stability, but loses badly in several
other ways. In addition to not being searchable, I really don't relish having
to create a revision to a long document starting with only pictures of the text
the document contains.


More generally and to reinforce a point that I think Bob Braden
made, I believe there was general consensus on this IETF list
when the earlier discussion occurred that PDF, if it was to be
used, be narrowly profiled so as to permit only those variations
that appeared to be stable and meet various other criteria,
notably ease of searching and extraction by text copying
operations.


Bingo. And this is the problem with the experiment as it is presently
formulated: It tests nothing of significance. It's completely obvious that we
can create PDF RFCs. It is equally obvious that block diagrams and equations
done in ASCII are inferior in appearance to those done using more powerful
formatting tools. All of these things get a 10 on the "duh" scale.

A genuinely useful process experiment in this space would have to:

(0) Nail down format requirements. Perhaps the requirements are the same
   as for ASCII documents, but I doubt it.
(1) Carefully examine the subsetting and profiling issue and decide what
   does or does not need to be done.
(2) If subsetting is needed tools need to be identified that conform to
   those subsetting guidelines. Additionally, we almost certainly need a
   validation tool that checks to see if the guidelines are being followed.
(3) Given how popular xml2rfc is I think it makes sense to at least look at
   how it would best be used to produce PDF documents containing equations and
   block diagrams.
(4) The criteria for assessing the experiemnt need to address our need for
   long term accessibility.

Now, it may or may not be appropriate for the document defining the experiment
to specify all of this stuff. But if the document doesn't specify these things
it at least has to specify the processes that are going to be used to create
these specifications.

I will also point out that the current draft talks about there being
a "phase 2" experiment involving XML or OpenOffice as input formats. The
vagueness of this part of the proposal is very disturbing - additional
details either need to be given or this material needs to be removed.

Yet another problem with the current proposal is the security considerations
section, which basically says there aren't any. Given that this document
proposes using PDF in its full and unrestricted glory it should be obvious why
this isn't true.


It seems to me that this draft, by omitting
specifics about versions and features of PDF to be permitted
and, if it isn't obvious, how the submission or editing process
automatically verifies that those rules were followed, is not
responsive to that consensus.  Arguably, on that basis, it
should never have been Last Called.


I can sort of justify last calling it in order to force people to review it. I
certainly hadn't read it all that carefully before. But now that I have read
it, my position is that we urgently need a process experiment in this space,
but this is absolutely not the right one to run.

Ned

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Julian Reschke]

Hallam-Baker, Phillip schrieb:

...
A standards based, future proof, non proprietary solution to this problem is to 
adopt:

  * Use of MHTML as the archive packaging.
  * Use of XHTML 1.0 as the document encoding.
  * Use of a standard IETF defined style sheet.
  * Use of PNG encoding for all images.

These restrictions may all be enforced using easily constructed verification tools. The W3C already has these and would be more than happy to provide them to the IETF. 
...


Absolutely!

Best regards,

Julian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Proposed Experiment: Normative Format in AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Lyndon Nerenberg]

 * Use of MHTML as the archive packaging.
 * Use of XHTML 1.0 as the document encoding.
 * Use of a standard IETF defined style sheet.
 * Use of PNG encoding for all images.


I'm in agreement with the first three, but I disagree with using PNG for 
graphics.  PNG is a device output format that doesn't mesh with the other 
three, which are media-neutral input formats.


Output media properties change (rapidly) over time.  PNG doesn't 
accommodate changing output device resolution nicely.  Do you generate 
graphics for 72DPI? 100? 300?  None of these will scale (literally or 
figuratively) to the 1600DPI (and beyond) devices we can expect in the 
foreseeable future.  In this case I think SVG is a better alternative.  It 
has the attributes of PNG (open standard, unencumbered IPR) and the added 
benefit of media independence.


--lyndon

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Joel M. Halpern]

I would also observe that there is significant evidence that there is 
not a real problem here.


It seems to me that if there was a real problem with the graphics, 
that folks would be publishing RFCs with PS or PDF forms, even if 
those were not normative.
For the thousand RFCs starting with RFC 3000, there are  4 PS and 4 
PDF documents.  In total, assuming that those are for different 
documents, that is still less than 1% if those RFCs published in that 
time period.


I know some folks are vocal that there is a problem.
But, the evidence suggests otherwise.

In contrast, the evidence suggested for judging the experiment is 
going to be very limited, very subjective, and heavily influenced by 
the fact that the target are folks who are presumably particularly 
interested in a positive outcome.


This experiment is a bad idea.
I am sorry that this is not "constructive" input.  But sometimes the 
right answer is "no."
We already have provision for people to publish pretty pictures when 
they think that is helpful.
If lots of folks do that, and if we conclude that those PDFs are more 
useful than the text documents, then we would have something to discuss.


Sure, I hate producing ASCII art.  But then, I hate producing 
document art in any form.  The problem is not ASCII.  It is finding a 
good, clean, understandable, way to express ones ideas.


Yours,
Joel M. Halpern




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Henning Schulzrinne]

One of the persistent problem today is that "bis" drafts are harder to 
write than they should be. Rather than being able to work from the final 
source, there are often only almost-final, pre-RFC-editor versions in 
XML (or Word), where one then has to make sure that no late-stage 
changes are being missed. It can be done, but its tedious. (Even access 
to the pre-final versions relies on individuals keeping old files 
around.) Having a more organized and documented source management 
mechanism in place would help.


Joe Touch wrote:


Stephane Bortzmeyer wrote:
...

IMHO, IETF should always publish the "source" of its documents (the
current RFC process is far from perfect in that respect).


Which source (XML2RFC is only one; some use troff, and others use Word,
among others)? Why would inter-source conversion be more useful than
cut-and-paste?

Joe





___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Bill Fenner]

>(3) Given how popular xml2rfc is I think it makes sense to at least look at
>how it would best be used to produce PDF documents containing equations and
>block diagrams.

I did this the N-2nd (or maybe 3rd) time we had
this discussion and have refined it since.  See, e.g.,
http://electricrain.com/fenner/tmp/draft-my-document-01.pdf .
That's svg for the picture (also supported are gif, png, jpg,
etc.) and latex for the equation.  It's obviously just a proof
of concept implementation.

The editor screen when working on this document is something
like http://electricrain.com/fenner/tmp/svg_eqn_editing.png .
There's no WYSIWYG editing of the svn or latex, but you get
to see what they look like.

This is a $220 XML editor, but its job is mostly to string
together other pieces of software so although it's not free
software in this implementation, I don't think that means that
the same thing can't be implemented with free software (e.g.,
it uses Batik to render the svg, and if Apache FOP improved
some perhaps it could render the FOP to PDF instead of the
for-pay (or free-to-download-personal-edition) RenderX)

  Bill

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Hallam-Baker, Phillip]

The problem here is that the requirement to produce ASCII means that many of 
the advantages of the pdf format are lost.

Any diagrams must be replicated as ASCII art. Any formulas have to be 
replicated in TXT format.

The result is that producing a good PDF version adds hugely to the already 
complex process of complying with the TXT requirements.

> -Original Message-
> From: Joel M. Halpern [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, June 15, 2006 1:53 PM
> To: ietf@ietf.org
> Subject: Re: Last Call: 'Proposed Experiment: Normative 
> Format in Addition to ASCII Text' to Experimental RFC 
> (draft-ash-alt-formats)
> 
> I would also observe that there is significant evidence that 
> there is not a real problem here.
> 
> It seems to me that if there was a real problem with the 
> graphics, that folks would be publishing RFCs with PS or PDF 
> forms, even if those were not normative.
> For the thousand RFCs starting with RFC 3000, there are  4 PS 
> and 4 PDF documents.  In total, assuming that those are for 
> different documents, that is still less than 1% if those RFCs 
> published in that time period.
> 
> I know some folks are vocal that there is a problem.
> But, the evidence suggests otherwise.
> 
> In contrast, the evidence suggested for judging the 
> experiment is going to be very limited, very subjective, and 
> heavily influenced by the fact that the target are folks who 
> are presumably particularly interested in a positive outcome.
> 
> This experiment is a bad idea.
> I am sorry that this is not "constructive" input.  But 
> sometimes the right answer is "no."
> We already have provision for people to publish pretty 
> pictures when they think that is helpful.
> If lots of folks do that, and if we conclude that those PDFs 
> are more useful than the text documents, then we would have 
> something to discuss.
> 
> Sure, I hate producing ASCII art.  But then, I hate producing 
> document art in any form.  The problem is not ASCII.  It is 
> finding a good, clean, understandable, way to express ones ideas.
> 
> Yours,
> Joel M. Halpern
> 
> 
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Ted Faber]

On Thu, Jun 15, 2006 at 11:49:38AM -0600, Lyndon Nerenberg wrote:
> > * Use of MHTML as the archive packaging.
> > * Use of XHTML 1.0 as the document encoding.
> > * Use of a standard IETF defined style sheet.
> > * Use of PNG encoding for all images.
> 
> I'm in agreement with the first three, but I disagree with using PNG for 
> graphics.  PNG is a device output format that doesn't mesh with the other 
> three, which are media-neutral input formats.

He almost certainly misspelled SVG, another W3C standard for images
that's for all intents and purposes an XML-based, non-raster imagage
format with embedded text.

-- 
Ted Faber
http://www.isi.edu/~faber   PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG


pgpiDlQ31VHDh.pgp
Description: PGP signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Henrik Levkowetz]

Hi,

on 2006-06-15 19:30 Julian Reschke said the following:
> Hallam-Baker, Phillip schrieb:
>> ...
>> A standards based, future proof, non proprietary solution to this problem
> is to adopt:
>> 
>>   * Use of MHTML as the archive packaging.
>>   * Use of XHTML 1.0 as the document encoding.
>>   * Use of a standard IETF defined style sheet.
>>   * Use of PNG encoding for all images.
>> 
>> These restrictions may all be enforced using easily constructed verification
>> tools. The W3C already has these and would be more than happy to provide them
>> to the IETF. 
>> ...
> 
> Absolutely!

This sounds really good to me - it looks like a *much* more viable way
forward than any variation of PDF, today.

Regards,

Henrik

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Henrik Levkowetz]

Hi,

on 2006-06-15 19:52 Joel M. Halpern said the following:
> I would also observe that there is significant evidence that there is 
> not a real problem here.
> 
> It seems to me that if there was a real problem with the graphics, 
> that folks would be publishing RFCs with PS or PDF forms, even if 
> those were not normative.
> For the thousand RFCs starting with RFC 3000, there are  4 PS and 4 
> PDF documents.  In total, assuming that those are for different 
> documents, that is still less than 1% if those RFCs published in that 
> time period.
> 
> I know some folks are vocal that there is a problem.
> But, the evidence suggests otherwise.

Oh, *good* point.

> In contrast, the evidence suggested for judging the experiment is 
> going to be very limited, very subjective, and heavily influenced by 
> the fact that the target are folks who are presumably particularly 
> interested in a positive outcome.
> 
> This experiment is a bad idea.
> I am sorry that this is not "constructive" input.  But sometimes the 
> right answer is "no."
> We already have provision for people to publish pretty pictures when 
> they think that is helpful.
> If lots of folks do that, and if we conclude that those PDFs are more 
> useful than the text documents, then we would have something to discuss.

Agreed.  Thinking some more about this, the lack of inter-document
links seem to be a complaint that I hear much more often than the
lack of good graphics support.


Regards,

Henrik

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Julian Reschke]

Henrik Levkowetz schrieb:

...
Agreed.  Thinking some more about this, the lack of inter-document
links seem to be a complaint that I hear much more often than the
lack of good graphics support.

> ...

I was just thinking about how I'm using RFCs day to day. Answer: usually 
I don't use the ASCII versions at all. Instead, I try to obtain XML 
(RFC2629) versions of them, produce HTML, and use that instead 
(collected at: ).


Why?

- Readability
- Navigation
- Ability to reference a particular section or paragraph with a URL

...and so on.




Best regards, Julian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Henrik Levkowetz]

Hi Julian,

on 2006-06-15 21:42 Julian Reschke said the following:
> Henrik Levkowetz schrieb:
>> ...
>> Agreed.  Thinking some more about this, the lack of inter-document
>> links seem to be a complaint that I hear much more often than the
>> lack of good graphics support.
>  > ...
> 
> I was just thinking about how I'm using RFCs day to day. Answer: usually 
> I don't use the ASCII versions at all. Instead, I try to obtain XML 
> (RFC2629) versions of them, produce HTML, and use that instead 
> (collected at: ).
> 
> Why?
> 
> - Readability
> - Navigation
> - Ability to reference a particular section or paragraph with a URL
> 
> ...and so on.

Agreed.  And this is of course also the reason why I went to the effort
of writing and setting up the htmlization mechanism on tools.ietf.org:

Accessing, for any RFC or draft, its name under http://tools.ietf.org/html/
will give you a htmlized version, with at least rudimentary links and
section anchors.  Example: http://tools.ietf.org/html/rfc4510#section-1

And http://tools.ietf.org/rfc/index gives you a htmlized index pointing
to htmlized versions of the RFCs.

It's not as good as having the standard format provide links natively,
though.  I wish it was totally unnecessary.


Regards,

Henrik

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Hallam-Baker, Phillip]

This effect may well be the result of the difficulty of getting the draft 
through the process.

It is painful enough dealling with the editing process without having the 
additional complication of having two documents. 




> -Original Message-
> From: Henrik Levkowetz [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, June 15, 2006 3:29 PM
> To: Joel M. Halpern
> Cc: ietf@ietf.org
> Subject: Re: Last Call: 'Proposed Experiment: Normative 
> Format in Addition to ASCII Text' to Experimental RFC 
> (draft-ash-alt-formats)
> 
> Hi,
> 
> on 2006-06-15 19:52 Joel M. Halpern said the following:
> > I would also observe that there is significant evidence 
> that there is 
> > not a real problem here.
> > 
> > It seems to me that if there was a real problem with the graphics, 
> > that folks would be publishing RFCs with PS or PDF forms, even if 
> > those were not normative.
> > For the thousand RFCs starting with RFC 3000, there are  4 PS and 4 
> > PDF documents.  In total, assuming that those are for different 
> > documents, that is still less than 1% if those RFCs 
> published in that 
> > time period.
> > 
> > I know some folks are vocal that there is a problem.
> > But, the evidence suggests otherwise.
> 
> Oh, *good* point.
> 
> > In contrast, the evidence suggested for judging the experiment is 
> > going to be very limited, very subjective, and heavily 
> influenced by 
> > the fact that the target are folks who are presumably particularly 
> > interested in a positive outcome.
> > 
> > This experiment is a bad idea.
> > I am sorry that this is not "constructive" input.  But 
> sometimes the 
> > right answer is "no."
> > We already have provision for people to publish pretty 
> pictures when 
> > they think that is helpful.
> > If lots of folks do that, and if we conclude that those 
> PDFs are more 
> > useful than the text documents, then we would have 
> something to discuss.
> 
> Agreed.  Thinking some more about this, the lack of 
> inter-document links seem to be a complaint that I hear much 
> more often than the lack of good graphics support.
> 
> 
> Regards,
> 
>   Henrik
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Julian Reschke]

Henrik Levkowetz schrieb:

...
Agreed.  And this is of course also the reason why I went to the effort
of writing and setting up the htmlization mechanism on tools.ietf.org:

Accessing, for any RFC or draft, its name under http://tools.ietf.org/html/
will give you a htmlized version, with at least rudimentary links and
section anchors.  Example: http://tools.ietf.org/html/rfc4510#section-1
...


Oops. I wasn't aware of the anchors for sections. You may want to make 
them hrefs as well so people notice. That is, instead of...:


1

make it

1

Good stuff!

Best regards, Julian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: New mailing list for discussion of KEYPROV symmetric keyprovisioning proposal

[Hallam-Baker, Phillip]

People have pointed out to me that this notice did not have 
the instructions on how to subscribe.
 
Registration is via the Web form:
http://www.safehaus.org/mailman/listinfo/ietf-keyprov 

  
  
  From: Hallam-Baker, Phillip 
  [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 8:22 
  PMTo: ietf@ietf.orgSubject: New mailing list for 
  discussion of KEYPROV symmetric keyprovisioning proposal
  
  
  
  This message is being sent to the IETF mailing list 
  in accordance with recent requests to notify IETF members of proposals to form 
  working groups etc in this forum. 
   
   
  The OATH 
  consortium and RSA recently submitted proposals relating to the provisioning 
  of symmetric keys.
   
  While the 
  immediate focus of these proposals is OTP tokens any technology developed 
  is likely to have widespread application within the standards community. In 
  particular we note that the IETF now requires proposals involving the use of 
  cryptographic material to provide a means of managing and provisioning the 
  keying material.
   
  To this end 
  we have set up a mailing list to discuss the proposed formation of an IETF WG 
  in response to the security ADs request that we establish it prior to 
  consideration of our request for a BOF.
   
  The strawman charter has been 
  discussed at some length within OATH already, possibly more than is desirable 
  for a pre-pre-standards activity.
   
   
  The proposed name 
  is KEYPROV
   
  The mailing list 
  is ietf-keyprov@safehaus.org
   
  The name ietf-keyprov has been chosen to impress upon 
  the members the fact that the mailing list is for the purpose of discussions 
  that are intended to form an IETF working group that will operate under NOTE 
  WELL and result in a spec consistent with the IPR requirements set out in the 
  draft charter.
   
   
  The draft 
  charter is:
   
  
  
  Provisioning of Symmetric Keys (KEYPROV)
   
  Background
  One Time Password (OTP) tokens provide a convenient and secure means of 
  user authentication. Combined with a PIN an OTP token provides a robust two 
  factor authentication solution.
  Recent developments in Internet crime, in particular credential theft 
  (phishing) makes the widespread use of and thus development of open standards 
  for OTP tokens and other symmetric key cryptographic systems highly desirable. 
  
  This requires a standards based key provisioning infrastructure 
  analogous to the mechanisms provided in public key infrastructures. In 
  particular the ability to provision symmetric keys and associated attributes 
  dynamically to already issued devices such as cell phones and USB drives is 
  highly desirable. The working group will develop the necessary protocols and 
  data formats required to support provisioning and management of symmetric key 
  authentication tokens, both proprietary and standards based.
  Intellectual Property
  It is the intention of the working group to create an open standard 
  unencumbered by proprietary intellectual property claims. Essential claims 
  required to implement the specification should be available for license 
  according to Reasonable, Non-Discriminatory and Royalty Free terms 
  (RAND-Z).
  Scope and Deliverables
  The scope of the working group shall be to define protocols and data 
  formats necessary for provisioning of symmetric cryptographic keys and 
  associated attributes.
  The working group will produce the following deliverables:
  
Portable Symmetric Key Container 
Dynamic Symmetric Key Provisioning 
Protocol
  Milestones
  ·    
  2006 July 
  Charter WG
  ·    
  2006 November   
  WG last call on Portable Symmetric Key Container
  ·    
  2006 December   
  WG last call on Dynamic Symmetric Key Provisioning Protocol
  ·    
  2007 January    
  IETF Last call on PROPOSED status
  ·    
  2007 April    
  Complete Interoperability testing
  ·    
  2007 July 
  WG last call on promotion to DRAFT
  ·    
  2007 September   
  IETF last call on DRAFT status
  ·    
  2007 December   
  WG closes.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf