Subject: Re: Last Call: <draft-ietf-repute-query-http-09.txt> (A Reputation Query Protocol) to Proposed Standard

From: SM <[email-masked]>
Date: Thu, 15 Aug 2013 10:13:36 -0700

At 07:41 15-08-2013, The IESG wrote:
>The IESG has received a request from the Reputation Services WG (repute)
>to consider the following document:
>- 'A Reputation Query Protocol'
>   <draft-ietf-repute-query-http-09.txt> as Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2013-08-29. Exceptionally, comments may be

The draft-iet-repute-model reference is a down-ref.

   "A server receiving a query about an application it does not
    recognize or explicitly support support (e.g., by virtue of
    private agreements or experimental extensions) MUST return a
    404 error code."

There is a typo: "support support".

Are there other cases where a 404 is appropriate?  I am asking the 
question as there is a string of proposals built upon RFC 2616 which 
attempt to use HTTP status codes to communicate errors for the 
layered protocol.

In Section 3.2:

   "and SHOULD include an Expires field (see Section 14.21 of [HTTP])
    indicating a duration for which the template is to be considered
    valid by clients and not re-queried."

Why is this a RFC 2119 SHOULD?  There is a "SHOULD NOT" following 
that paragraph with a "don't query for a day if there isn't an 
Expires field".  Wouldn't it be easier to have "MUST include the 
Expires field"?

   "The template file might contain more than one template.  Such a file
    MUST have each template separated by a newline (ASCII 0x0D)
    character."

As this is line oriented it may be better to have CRLF.

In Section 3.3:

   "A server SHOULD include support for providing service over HTTP"

Is there a case where the service with work if the server does not 
support HTTP?

In Section 5:

   "The reputation service itself will use HTTP or other transport
    methods to issue queries and receive replies.  Those protocols have
    registered URI schemes and, as such, presumably have documented
    security considerations."

This is odd.  What other protocols are there to retrieve the URI template?

If I understood the draft, the Proposed Standard angle is:

   http://{service}/{application}/{subject}/{assertion}

with a "application/reputon+json" response.  Why should that be a 
Proposed Standard?

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 20 Aug 2013 23:53:04 -0700

> The draft-iet-repute-model reference is a down-ref.

I agree, the model document should be considered for PS instead.

> There is a typo: "support support".

Fixed.

> attempt to use HTTP status codes to communicate errors for the layered
> protocol.
>

I don't believe so.  The only cases we can think of are those where the
supported application does or does not exist, and the service being queried
does or does not have data about the subject.  Elsewhere we describe that
there's a specific mechanism to say in a valid reply that no data are
available, so that handles the second question.  You only get to the second
question if the answer to the first is "yes", which leaves the first answer
of "no" that needs handling specified.

> Why is this a RFC 2119 SHOULD?  There is a "SHOULD NOT" following that
> paragraph with a "don't query for a day if there isn't an Expires field".
>  Wouldn't it be easier to have "MUST include the Expires field"?
>

An operator that calculates reputation values on demand would conceivably
give a new value for every query.  If a client wants that up-to-the-moment
accuracy, then Expires is counterproductive.  On the other hand, an
operator that calculates reputation values daily could indicate this by
setting an Expires field of either a day (86400) or the total time between
"now" and the next calculation.

The latter case is likely more prevalent, but it doesn't seem like saying
"MUST" and requiring a value of 0 for the former case is strictly the right
solution.

> As this is line oriented it may be better to have CRLF.

Why is that?

> Is there a case where the service with work if the server does not support
> HTTP?
>

A client could support HTTP for the template retrieval but only HTTPS for
the service itself, for all the usual privacy and security reasons.

> This is odd.  What other protocols are there to retrieve the URI template?

Any URI scheme is supported.  Only HTTP/HTTPS are currently implemented at
the moment.

>   http://{service}/{application}**/{subject}/{assertion}
>
> with a "application/reputon+json" response.  Why should that be a Proposed
> Standard?
>
>
That's not "the" angle, it's one possible template.

Does it not qualify as a Proposed Standard?  If not, why not?  Will it fail
to interoperate?

-MSK

---

From: SM <[email-masked]>
Date: Wed, 21 Aug 2013 00:43:44 -0700

At 23:53 20-08-2013, Murray S. Kucherawy wrote:
>I don't believe so.  The only cases we can think of are those where 
>the supported application does or does not exist, and the service 
>being queried does or does not have data about the 
>subject.  Elsewhere we describe that there's a specific mechanism to 
>say in a valid reply that no data are available, so that handles the 
>second question.  You only get to the second question if the answer 
>to the first is "yes", which leaves the first answer of "no" that 
>needs handling specified.

Ok.

>An operator that calculates reputation values on demand would 
>conceivably give a new value for every query.  If a client wants 
>that up-to-the-moment accuracy, then Expires is 
>counterproductive.  On the other hand, an operator that calculates 
>reputation values daily could indicate this by setting an Expires 
>field of either a day (86400) or the total time between "now" and 
>the next calculation.
>
>The latter case is likely more prevalent, but it doesn't seem like 
>saying "MUST" and requiring a value of 0 for the former case is 
>strictly the right solution.

I see what you mean.  The server-specified expiration (see RFC 2616) 
uses other headers as well.

>Why is that?

The media type is "text/plain".

>A client could support HTTP for the template retrieval but only 
>HTTPS for the service itself, for all the usual privacy and security reasons.

Ok.

>Any URI scheme is supported.  Only HTTP/HTTPS are currently 
>implemented at the moment.

Ok.

>Does it not qualify as a Proposed Standard?  If not, why not?  Will 
>it fail to interoperate?

The quick answer is that I am not sure.  I'll defer to you.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 21 Aug 2013 01:14:44 -0700

> The media type is "text/plain".
Ah.  I realize that CRLF is standard line termination for SMTP; is it
automatically the expected line termination for all line-oriented
protocols?  I don't know about others.

-MSK

---

From: SM <[email-masked]>
Date: Thu, 29 Aug 2013 08:57:09 -0700

Hi Murray,
At 01:14 21-08-2013, Murray S. Kucherawy wrote:
>Ah.  I realize that CRLF is standard line termination for SMTP; is 
>it automatically the expected line termination for all line-oriented 

I would have to write a long answer to that question. :-)  I haven't 
had time to test what the draft specifies.  Thanks for addressing the comments.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 29 Aug 2013 11:36:59 -0700

On Thu, Aug 29, 2013 at 8:57 AM, SM <[email-masked]> wrote:

> I would have to write a long answer to that question. :-)  I haven't had
> time to test what the draft specifies.  Thanks for addressing the comments.
>
>
>
We can go with CRLF, since it's been pointed out to me that most text-based
protocols have historically used that.  Who am I to change history?  :-)

-MSK

---

From: Bob Braden <[email-masked]>
Date: Fri, 30 Aug 2013 09:56:22 -0700

CR LF was first adopted for the Telnet NVT (Network Virtual Terminal). I 
think it was Jon
Postel's choice, and no one disagreed. Then when FTP was defined, it 
seemed most economical
to use the same. In fact, doesn't the FTP spec explicitly say that the 
conventions on the control
connection should be those of Telnet? Later, when Jon defined SMTP, I am 
sure that
Jon would not have dreamed of using different end-of-line conventions in 
different protocols.

I would hope that you would not dream of it, either.

Bob Braden

>
> We can go with CRLF, since it's been pointed out to me that most 
> text-based protocols have historically used that.  Who am I to change 
> history?  :-)
>
> -MSK
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 30 Aug 2013 14:53:02 -0400

--On Friday, August 30, 2013 09:56 -0700 Bob Braden
<[email-masked]> wrote:

> CR LF was first adopted for the Telnet NVT (Network Virtual
> Terminal). I think it was Jon
> Postel's choice, and no one disagreed.

A tad more complicated, IIR.  It turns out that, with some
systems interpreting LF as "same position next line" and some as
"first position, next line", some interpreting CR as "same
position, this line" and some as "first position next line", CR
LF was the only safe universal choice.  At least one of those
four interpretations was a clear violation of the early versions
of the ASCII standard but the relevant vendor didn't care or was
too ignorant to notice.  That particular bit of analysis was
known pre-ARPANET' I wouldn't be surprised to find it on some
earlier Teletype documentation.  

I have no idea who make the decision for Telnet and friends, but
I wouldn't be at all surprised if it were Jon.  The decision
was, however, pretty constrained.

Similarly, it was an important design constraint for FTP and
later for SMTP, WHIS, FINGer, and a bunch of other things that
they (the control connection for the form) be able to run over
Telnet connections (on a different port).  I don't know whether
that was cause or effect wrt  the CRLF choices for those
protocols, but it probably figured in.  I've suspected whether
that was part of what drove the port mode in preference to some
fancy service-selection handshaking at the beginning of the
connection but I have no idea how that set of decisions were
made. 

> Then when FTP was
> defined, it seemed most economical
> to use the same. In fact, doesn't the FTP spec explicitly say
> that the conventions on the control
> connection should be those of Telnet? 

Yep.  RFC 959, Page 34 (snicker) and RFC 1123 Section 4.1.2.10.
There were even some discussions about the interactions between
Telnet option negotiation and FTP (Section 4.1.2.12 of RFC 1123
was, I think, intended to definitively settle those).

> Later, when Jon defined
> SMTP, I am sure that
> Jon would not have dreamed of using different end-of-line
> conventions in different protocols.
> 

Indeed.

   john

---

From: Hector Santos <[email-masked]>
Date: Fri, 30 Aug 2013 15:22:10 -0400

John,

I don't think it would of been fun designing and testing a text-based 
hosting protocol manually with your terminal/telecommunication/telnet 
client "New Line Mode" (add LF to CR) option disabled or server text 
responses only issue CR or LF.

It would of been very hard or confusing to do this stuff visually. :)

Most, if not all of our text based protocols borrow the same 
ASCII/ANSI/VT100/TELNET framework and there are even considerations 
for different terminators in the area of timeouts and also learning 
via the initial handshakes.

--
HLS