A Framework for the Usage of Internet Media Guides (IMGs)
RFC 4435

Note: This ballot was opened for revision 09 and is now closed.

(Jon Peterson; former steering group member) Yes

Yes ( for -)
No email
send info

(David Kessens; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Harald Alvestrand; former steering group member) No Objection

No Objection (2005-01-20 for -)
No email
send info
Reviewed by Spencer Dawkins, Gen-ART

Review copied to comment log; mostly wording comments.

(Margaret Cullen; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Scott Hollenbeck; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Ted Hardie; former steering group member) (was Discuss) Abstain

Abstain (2005-10-19)
No email
send info
I still believe that addressing the issue below would be useful, but I have moved to abstain
in order that something might get published.  Here's the original DISCUSS text:

In 5.2.2, the document says:

  We anticipate that the IMG QUERY-RESOLVE
  operation will be a trivial usage of HTTP, although other transport
  protocol options may be beneficial to consider too.


This seems contrary to what is said in 5.1.1, where the analysis
notes that ANNOUNCE and VERIFY won't work in an HTTP-only
environment, and so HTTP is not sufficient for a unicast deployment.
If the IMG system is going to use multiple protocols (e.g. HTTP for
unicast Query-Resolve, SIP Notify for announce), then there will
be a reasonable amount of complexity in determining what to do when the
different protocols give answers.  I'm also surprised, given that
Henning is one of the authors, that the document would believe
"layered onto HTTP" meant simple; I'd have thought XCAP would
have beaten that notion out of him.